mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
work complete, done is better than perfect
This commit is contained in:
parent
e5aaa6a78d
commit
4f742073ff
@ -1,11 +1,11 @@
|
||||
各种 NoSQL 的比较 TODO: 中英文之间需要半角空格
|
||||
各种 NoSQL 的比较
|
||||
================
|
||||
|
||||
即使关系型数据库依然是非常有用的工具,它们持续几十年的垄断地位就要走到头了。现在已经存在无数能撼动关系型数据库地位的 NoSQL,当然,这些 NoSQL 还无法完全取代它们。(也就是说,关系型数据库还是处理关系型事务的最佳方式。)
|
||||
|
||||
NoSQL 与 NoSQL 之间的区别,要远大于 SQL 与 SQL 之间的区别。所以软件架构师必须要在项目一开始就选好一款合适的 NoSQL。
|
||||
|
||||
考虑到这种情况,本文为大家介绍以下几种 NoSQL 之间的区别:[Cassandra][], [Mongodb][], [CouchDB][], [Redis][], [Riak][], [Couchbase (ex-Membase)][], [Hypertable][], [ElasticSearch][], [Accumulo][], [VoltDB][], [Kyoto Tycoon][], [Scalaris][], [Neo4j][]和[HBase][]:
|
||||
考虑到这种情况,本文为大家介绍以下几种 NoSQL 之间的区别:[Cassandra][], [Mongodb][], [CouchDB][], [Redis][], [Riak][], [Couchbase (ex-Membase)][], [Hypertable][], [ElasticSearch][], [Accumulo][], [VoltDB][], [Kyoto Tycoon][], [Scalaris][], [Neo4j][]和[HBase][]:
|
||||
|
||||
##最流行的 NoSQL
|
||||
|
||||
@ -13,7 +13,7 @@ NoSQL 与 NoSQL 之间的区别,要远大于 SQL 与 SQL 之间的区别。所
|
||||
|
||||
**开发语言:** C++
|
||||
|
||||
**主要特性:** 保留 SQL 中一些用户友好的特性(查询、索引等)。
|
||||
**主要特性:** 保留 SQL 中一些用户友好的特性(查询、索引等)
|
||||
|
||||
**许可证:** AGPL (发起者: Apache)
|
||||
|
||||
@ -33,344 +33,345 @@ NoSQL 与 NoSQL 之间的区别,要远大于 SQL 与 SQL 之间的区别。所
|
||||
- 支持对数据建立索引
|
||||
- 数据中心意识
|
||||
|
||||
**应用场景:**动态查询;需要定义索引而不是 map/reduce 功能;提高大数据库性能;想使用 CouchDB 但数据的 IO 吞吐量太大,CouchDB 无法满足要求。MongoDB 可以满足你的需求。
|
||||
**应用场景:** 动态查询;需要定义索引而不是 map/reduce 功能;提高大数据库性能;想使用 CouchDB 但数据的 IO 吞吐量太大,CouchDB 无法满足要求。MongoDB 可以满足你的需求
|
||||
|
||||
**使用案例:**想布署 MySQL 或 PostgreSQL,但它们存在的预定义处理语句和预定义变量让你望而却步。这个时候,MongoDB 是你可以考虑的选项。
|
||||
**使用案例:** 想布署 MySQL 或 PostgreSQL,但它们存在的预定义处理语句和预定义变量让你望而却步。这个时候,MongoDB 是你可以考虑的选项
|
||||
|
||||
###Riak 1.2版
|
||||
|
||||
**开发语言:** Erlang、C、以及一些 JavaScript
|
||||
|
||||
**主要特性:**容错机制(当一份数据失效,服务会自动切换到备份数据,保证服务一直在线 —— 译者注)
|
||||
**主要特性:** 容错机制(当一份数据失效,服务会自动切换到备份数据,保证服务一直在线 —— 译者注)
|
||||
|
||||
**许可证:** Apache
|
||||
|
||||
**数据传输、存储的格式:** HTTP/REST 架构,自定义二进制格式
|
||||
|
||||
- 可存储 BLOB(binary large object,二进制大对象,比如一张图片、一个声音文件 —— 译者注)。
|
||||
- 可在分部式存储和备份存储之间作协调。
|
||||
- 为了保证可验证性和安全性,Riak 在 JS 和 Erlaing 中提供提交前(pre-commit)和提交后(post-commit)钩子(hook)函数(你可以在提交数据前执行一个 hook,或者在提交数据后执行一个 hook —— 译者注)。
|
||||
- JS 和 Erlang 提供映射和简化(map/reduce)编程模型。
|
||||
- 使用 links 和 link walking 图形化数据库(link 用于描述对象之间的关系,link walking 是一个用于查询对象关系的进程 —— 译者注)。
|
||||
- 次要标记(secondaty indeces,开发者在写数据时可用多个名称来标记一个对象 —— 译者注),一次只能用一个。
|
||||
- 支持大数据对象(Luwak)(Luwak 是 Riak 中的一个服务层,为大数据量对象提供简单的、面向文档的抽象,弥补了 Riak 的 Key/Value 存储格式在处理大数据对象方面的不足 —— 译者注)。
|
||||
- 提供“开源”和“企业”两个版本。
|
||||
- 提供“全文搜索”(可能就是允许用户在不提供 table/volume 等信息,对一个表进行文本字段的搜索,瞎猜的,望指正 —— 译者注)。
|
||||
- 正在将存储后端从“Bitcask”迁移到 Google 的“LevelDB”上。
|
||||
- 企业版本提供多点备份(各点地位平等,非主从架构)和SNMP监控功能。
|
||||
- 可存储 BLOB(binary large object,二进制大对象,比如一张图片、一个声音文件 —— 译者注)
|
||||
- 可在分部式存储和备份存储之间作协调
|
||||
- 为了保证可验证性和安全性,Riak 在 JS 和 Erlaing 中提供提交前(pre-commit)和提交后(post-commit)钩子(hook)函数(你可以在提交数据前执行一个 hook,或者在提交数据后执行一个 hook —— 译者注)
|
||||
- JS 和 Erlang 提供映射和简化(map/reduce)编程模型
|
||||
- 使用 links 和 link walking 图形化数据库(link 用于描述对象之间的关系,link walking 是一个用于查询对象关系的进程 —— 译者注)
|
||||
- 次要标记(secondaty indeces,开发者在写数据时可用多个名称来标记一个对象 —— 译者注),一次只能用一个
|
||||
- 支持大数据对象(Luwak)(Luwak 是 Riak 中的一个服务层,为大数据量对象提供简单的、面向文档的抽象,弥补了 Riak 的 Key/Value 存储格式在处理大数据对象方面的不足 —— 译者注)
|
||||
- 提供“开源”和“企业”两个版本
|
||||
- 提供“全文搜索”(可能就是允许用户在不提供 table/volume 等信息,对一个表进行文本字段的搜索,瞎猜的,望指正 —— 译者注)
|
||||
- 正在将存储后端从“Bitcask”迁移到 Google 的“LevelDB”上
|
||||
- 企业版本提供多点备份(各点地位平等,非主从架构)和SNMP监控功能
|
||||
|
||||
**应用场景:**假如你想要类似 Dynamo 的数据库,但不想要它的庞大和复杂;假如你需要良好的单点可扩展性、可用性和容错能力,但不想为多点备份买单。 Riak 能满足你的需求。
|
||||
**应用场景:** 假如你想要类似 Dynamo 的数据库,但不想要它的庞大和复杂;假如你需要良好的单点可扩展性、可用性和容错能力,但不想为多点备份买单。 Riak 能满足你的需求
|
||||
|
||||
**使用案例:**销售点数据收集;工厂控制系统;必须实时在线的系统;需要易于升级的网站服务器。
|
||||
**使用案例:** 销售点数据收集;工厂控制系统;必须实时在线的系统;需要易于升级的网站服务器
|
||||
|
||||
###CouchDB 1.2版
|
||||
|
||||
**开发语言:** Erlang
|
||||
|
||||
**主要特性:**数据一致性;易于使用
|
||||
**主要特性:** 数据一致性;易于使用
|
||||
|
||||
**许可证:** Apache
|
||||
|
||||
**数据传输格式:** HTTP/REST
|
||||
|
||||
- 双向复制(一种同步技术,每个备份点都有一份它们自己的拷贝,允许用户在存储点断线的情况下修改数据,当存储节点重新上线时,CouchDB 会对所有节点同步这些修改 —— 译者注)。
|
||||
- 支持持续同步或者点对点同步。
|
||||
- 支持冲突检测。
|
||||
- 支持主主互备(多个数据库时时同步数据,起到备份和分摊用户并行访问量的作用 —— 译者注)。
|
||||
- 多版本并发控制(MVCC),写操作时不需要阻塞读操作(或者说不需要锁住数据库)。
|
||||
- 向下兼容。
|
||||
- 可靠的 crash-only 设计(所谓 crash-only,就是程序出错时,只需重启下程序,丢弃内存的所有数据,不需要执行复杂的数据恢复操作 —— 译者注)。
|
||||
- 需要实时压缩数据。
|
||||
- 视图(文档是 CouchDB 的核心概念,CouchDB 中的视图声明了如何从文档中提取数据,以及如何对提取出来的数据进行处理 —— 译者注):内嵌映射和简化(map/reduce)编程模型。
|
||||
- 格式化的views字段:lists(包含把视图运行结果转换成非 JSON 格式的方法)和 shows(包含把文档转换成非 JSON 格式的方法)(在 CouchDB 中,一个 Web 应用是与一个设计文档相对应的。在设计文档中可以包含一些特殊的字段,views 字段包含永久的视图定义 —— 译者注)。
|
||||
- 可能会提供服务器端文档验证的功能。
|
||||
- 可能提供身份认证功能。
|
||||
- 通过 _changes 函数实时更新数据。
|
||||
- 链接处理(attachment:couchDB 的每份文档都可以有一个 attachment,就像一份 email 有它的网址 —— 译者注)。
|
||||
- 有个 CouchApps(第三方JS的应用)。
|
||||
- 双向复制(一种同步技术,每个备份点都有一份它们自己的拷贝,允许用户在存储点断线的情况下修改数据,当存储节点重新上线时,CouchDB 会对所有节点同步这些修改 —— 译者注)
|
||||
- 支持持续同步或者点对点同步
|
||||
- 支持冲突检测
|
||||
- 支持主主互备(多个数据库时时同步数据,起到备份和分摊用户并行访问量的作用 —— 译者注)
|
||||
- 多版本并发控制(MVCC),写操作时不需要阻塞读操作(或者说不需要锁住数据库)
|
||||
- 向下兼容
|
||||
- 可靠的 crash-only 设计(所谓 crash-only,就是程序出错时,只需重启下程序,丢弃内存的所有数据,不需要执行复杂的数据恢复操作 —— 译者注)
|
||||
- 需要实时压缩数据
|
||||
- 视图(文档是 CouchDB 的核心概念,CouchDB 中的视图声明了如何从文档中提取数据,以及如何对提取出来的数据进行处理 —— 译者注):内嵌映射和简化(map/reduce)编程模型
|
||||
- 格式化的views字段:lists(包含把视图运行结果转换成非 JSON 格式的方法)和 shows(包含把文档转换成非 JSON 格式的方法)(在 CouchDB 中,一个 Web 应用是与一个设计文档相对应的。在设计文档中可以包含一些特殊的字段,views 字段包含永久的视图定义 —— 译者注)
|
||||
- 可能会提供服务器端文档验证的功能
|
||||
- 可能提供身份认证功能
|
||||
- 通过 _changes 函数实时更新数据
|
||||
- 链接处理(attachment:couchDB 的每份文档都可以有一个 attachment,就像一份 email 有它的网址 —— 译者注)
|
||||
- 有个 CouchApps(第三方JS的应用)
|
||||
|
||||
**应用场景:**用于随机数据量多、需要预定义查询的地方;用于版本控制比较重要的地方。
|
||||
**应用场景:** 用于随机数据量多、需要预定义查询的地方;用于版本控制比较重要的地方
|
||||
|
||||
**使用案例:**可用于客户关系管理(CRM),内容管理系统(CMS);可用于主主互备甚至多机互备。
|
||||
**使用案例:** 可用于客户关系管理(CRM),内容管理系统(CMS);可用于主主互备甚至多机互备
|
||||
|
||||
###Redis 2.4版
|
||||
|
||||
**开发语言:** C/C++
|
||||
|
||||
**主要特性:**快到掉渣
|
||||
**主要特性:** 快到掉渣
|
||||
|
||||
**许可证:** BSD
|
||||
|
||||
**数据传输方式:** 类似 Telnet
|
||||
|
||||
- Redis 是一个内存数据库(in-memory database,简称 IMDB,将数据放在内存进行读写,这才是“快到掉渣”的真正原因 —— 译者注),磁盘只是提供数据持久化(即将内存的数据写到磁盘)的功能(这类数据库被称为“disk backed”数据库)。
|
||||
- 当前不支持将磁盘作为 swap 分区,虚拟内存(VM)和 Diskstore 方式都没加到此版本(Redis 的数据持久化共有4种方式:定时快照、基于语句追加、虚拟内存、diskstore。其中 VM 方式由于性能不好以及不稳定的问题,已经被作者放弃,而 diskstore 方式还在实验阶段 —— 译者注)。
|
||||
- Redis 是一个内存数据库(in-memory database,简称 IMDB,将数据放在内存进行读写,这才是“快到掉渣”的真正原因 —— 译者注),磁盘只是提供数据持久化(即将内存的数据写到磁盘)的功能(这类数据库被称为“disk backed”数据库)
|
||||
- 当前不支持将磁盘作为 swap 分区,虚拟内存(VM)和 Diskstore 方式都没加到此版本(Redis 的数据持久化共有4种方式:定时快照、基于语句追加、虚拟内存、diskstore。其中 VM 方式由于性能不好以及不稳定的问题,已经被作者放弃,而 diskstore 方式还在实验阶段 —— 译者注)
|
||||
- 主从备份
|
||||
- 存储结构为简单的 key/value 或 hash 表。
|
||||
- 但是操作比较复杂,比如:ZREVRANGEBYSCORE。
|
||||
- 支持 INCR(INCR key 就是将key中存储的数值加一 —— 译者注)命令(对限速和统计有帮助)。
|
||||
- 支持sets数据类型(以及 union/diff/inter)。
|
||||
- 支持 lists (以及 queue/blocking pop)。
|
||||
- 支持 hash sets (多级对象)。
|
||||
- 支持 sorted sets(高效率的表,在范围查找方面有优势)。
|
||||
- 支持事务处理。
|
||||
- 存储结构为简单的 key/value 或 hash 表
|
||||
- 但是操作比较复杂,比如:ZREVRANGEBYSCORE
|
||||
- 支持 INCR(INCR key 就是将key中存储的数值加一 —— 译者注)命令(对限速和统计有帮助)
|
||||
- 支持sets数据类型(以及 union/diff/inter)
|
||||
- 支持 lists (以及 queue/blocking pop)
|
||||
- 支持 hash sets (多级对象)
|
||||
- 支持 sorted sets(高效率的表,在范围查找方面有优势)
|
||||
- 支持事务处理
|
||||
- 缓存中的数据可被标记为过期
|
||||
- Pub/Sub 操作能让用户发送信息。
|
||||
- Pub/Sub 操作能让用户发送信息
|
||||
|
||||
**应用场景:**适合布署快速多变的小规模数据(可以完全运行在存在中)。
|
||||
**应用场景:** 适合布署快速多变的小规模数据(可以完全运行在存在中)
|
||||
|
||||
**使用案例:**股价系统、分析系统、实时数据收集系统、实时通信系统、以及取代 memcached。
|
||||
**使用案例:** 股价系统、分析系统、实时数据收集系统、实时通信系统、以及取代 memcached
|
||||
|
||||
##Clones of Google's Bigtable
|
||||
##Google Bigtable 的衍生品
|
||||
|
||||
###HBase (V0.92.0)
|
||||
###HBase 0.92.0 版
|
||||
|
||||
**Written in:** Java
|
||||
**开发语言:** Java
|
||||
|
||||
**Main point:** Billions of rows X millions of columns
|
||||
**主要特性:** 支持几十亿行*几百万列的大表
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** HTTP/REST (also Thrift)
|
||||
**数据传输方式:** HTTP/REST (也支持 Thrift 开发框架)
|
||||
|
||||
- Modeled after Google's BigTable
|
||||
- Uses Hadoop's HDFS as storage
|
||||
- Map/reduce with Hadoop
|
||||
- Query predicate push down via server side scan and get filters
|
||||
- Optimizations for real time queries
|
||||
- A high performance Thrift gateway
|
||||
- HTTP supports XML, Protobuf, and binary
|
||||
- Jruby-based (JIRB) shell
|
||||
- Rolling restart for configuration changes and minor upgrades
|
||||
- Random access performance is like MySQL
|
||||
- A cluster consists of several different types of nodes
|
||||
- 仿造 Google 的 BigTable
|
||||
- 使用 Hadoop 的 HDFS 文件系统作为存储
|
||||
- 使用 Hadoop 的映射和简化(map/reduce)编程模型
|
||||
- 查询条件被推送到服务器端,由服务器端执行扫描和过滤
|
||||
- 对实时查询进行优化
|
||||
- 高性能的 Thrift gateway(访问 HBase 的接口之一,特点是利用 Thrift 序列化支持多种语言,可用于异构系统在线访问 HBase 表数据 —— 译者注)
|
||||
- 使用 HTTP 通信协议,支持 XML、Protobuf 以及一些二进制文档结构
|
||||
- 支持基于 Jruby(JIRB)的shell
|
||||
- 当配置信息有更改时,支持 rolling restart(轮流重启数据节点)
|
||||
- 随机读写性能与 MySQL 一样
|
||||
- 一个集群可由不同类型的结点组成
|
||||
|
||||
**Best used:** Hadoop is probably still the best way to run Map/Reduce jobs on huge datasets. Best if you use the Hadoop/HDFS stack already.
|
||||
**应用场景:** Hadoop 可能是在大数据上跑 Map/Reduce 业务的最佳选择;如果你已经搭建了 Hadoop/HDFS 架构,HBase 也是你最佳的选择。
|
||||
|
||||
**For example:** Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.
|
||||
**使用案例:** 搜索引擎;日志分析系统;扫描大型二维非关系型数据表。
|
||||
|
||||
###Cassandra (1.2)
|
||||
###Cassandra 1.2版
|
||||
|
||||
**Written in:** Java
|
||||
**开发语言:** Java
|
||||
|
||||
**Main point:** Best of BigTable and Dynamo
|
||||
**主要特性:** BigTable 和 Dynamo的完美结合(Cassandra 以 Amazon 专有的完全分布式的 Dynamo 为基础,结合了Google BigTable基于 Column Family 的数据模型 —— 译者注)
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** Thrift & custom binary CQL3
|
||||
**数据传输和存储方式:** Thrift 和自定义二进制 CQL3(即 Cassandra 查询语言第3版 —— 译者注)
|
||||
|
||||
- Tunable trade-offs for distribution and replication (N, R, W)
|
||||
- Querying by column, range of keys (Requires indices on anything that you want to search on)
|
||||
- BigTable-like features: columns, column families
|
||||
- Can be used as a distributed hash-table, with an "SQL-like" language, CQL (but no JOIN!)
|
||||
- Data can have expiration (set on INSERT)
|
||||
- Writes can be much faster than reads (when reads are disk-bound)
|
||||
- Map/reduce possible with Apache Hadoop
|
||||
- All nodes are similar, as opposed to Hadoop/HBase
|
||||
- Very good and reliable cross-datacenter replication
|
||||
- 可以灵活调整对数据的分布式或备份式存储(通过设置N,R,W之间的关系)(NRW是数据库布署模型中的概念,N是存储网络中复制数据的节点数,R是网络中读数据的节点数,W是网络中写数据的节点数。一个环境中N值是固定的,设置不同的WR值组合能在数据可用性和数据一致性之间取得不同的平衡,可参考 CAP 定理 —— 译者注)
|
||||
- 按列查询,按keys值排序后存储(需要包含你想要搜索的任何信息)(Cassandra 的数据模型借鉴自 BigTable 的列式存储,列式存储可以理解成这样,将行ID、列簇号,列号以及时间戳一起,组成一个Key,然后将Value按Key的顺序进行存储 —— 译者注)
|
||||
- 类似 BigTable 的特性:列、列簇
|
||||
- 支持分布式 hash 表,使用“类 SQL” 语言 —— CQL(但没有 SQL 中的 JOIN 语句)
|
||||
- 可以为数据设置一个过期时间(使用 INSERT 指令)
|
||||
- 写性能远高于读性能(读性能的瓶颈是磁盘 IO)
|
||||
- 可使用 Hadoop 的映射和简化(map/reduce)编程模型
|
||||
- 所有节点都相似,这点与 Hadop/HBase 架构不同
|
||||
- 可靠的跨数据中心备份解决方案
|
||||
|
||||
**Best used:** When you write more than you read (logging). If every component of the system must be in Java. ("No one gets fired for choosing Apache's stuff.")
|
||||
**应用场景:** 写操作多于读操作的环境(比如日志系统);如果系统全部由 JAVA 组成(“没人会因为使用了 Apache 许可下的产品而被炒鱿鱼”(此句貌似是网上有人针对“Apache considered harmful”一文所作的回应 —— 译者注))
|
||||
|
||||
**For example:** Banking, financial industry (though not necessarily for financial transactions, but these industries are much bigger than that.) Writes are faster than reads, so one natural niche is data analysis.
|
||||
**使用案例:** 银行、金融机构;写性能强于读性能,所以 Cassandra 天生就是用来作数据分析的。
|
||||
|
||||
###Hypertable (0.9.6.5)
|
||||
###Hypertable 0.9.6.5版
|
||||
|
||||
**Written in:** C++
|
||||
**开发语言:** C++
|
||||
|
||||
**Main point:** A faster, smaller HBase
|
||||
**主要特性:** HBase 的精简版,但比 HBase 更快
|
||||
|
||||
**License:** GPL 2.0
|
||||
**许可证:** GPL 2.0
|
||||
|
||||
**Protocol:** Thrift, C++ library, or HQL shell
|
||||
**数据传输和存储的方式:** Thrift,C++库,或者 HQL shell
|
||||
|
||||
- Implements Google's BigTable design
|
||||
- Run on Hadoop's HDFS
|
||||
- Uses its own, "SQL-like" language, HQL
|
||||
- Can search by key, by cell, or for values in column families.
|
||||
- Search can be limited to key/column ranges.
|
||||
- Sponsored by Baidu
|
||||
- Retains the last N historical values
|
||||
- Tables are in namespaces
|
||||
- Map/reduce with Hadoop
|
||||
- 采用与 Google BigTable 相似的设计
|
||||
- 运行在 Hadoop HDFS 之上
|
||||
- 使用自己的“类 SQL”语言 —— HQL
|
||||
- 可以根据 key 值、单元(cell)进行查找,可以在列簇上查找
|
||||
- 查询数据可以指定 key 或者列的范围
|
||||
- 由百度公司赞助(百度早在2009年就成为这个项目的赞助商了 —— 好吧译者表示有点大惊小怪了:P)
|
||||
- 能保留一个值的 N 个历史版本
|
||||
- 表在命名空间内定义
|
||||
- 使用 Hadoop 的 Map/reduce 模型
|
||||
|
||||
**Best used:** If you need a better HBase.
|
||||
**应用场景:** 假如你需要一个更好的HBase,就用Hypertable吧。
|
||||
|
||||
**For example:** Same as HBase, since it's basically a replacement: Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.
|
||||
**使用案例:** 与HBase一样,就是搜索引擎被换了下;分析日志数据的系统;适用于浏览大规模二维非关系型数据表。
|
||||
|
||||
###Accumulo (1.4)
|
||||
###Accumulo 1.4版
|
||||
|
||||
**Written in:** Java and C++
|
||||
**开发语言:** Java 和 C++
|
||||
|
||||
**Main point:** A BigTable with Cell-level security
|
||||
**主要特性:** 一个有着单元级安全的 BigTable
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** Thrift
|
||||
**数据传输和存储的方式:** Thrift
|
||||
|
||||
- Another BigTable clone, also runs of top of Hadoop
|
||||
- Cell-level security
|
||||
- Bigger rows than memory are allowed
|
||||
- Keeps a memory map outside Java, in C++ STL
|
||||
- Map/reduce using Hadoop's facitlities (ZooKeeper & co)
|
||||
- Some server-side programming
|
||||
- 另一个 BigTable 的复制品,也是跑在 Hadoop 的上层
|
||||
- 单元级安全保证
|
||||
- 允许使用比内存容量更大的数据列
|
||||
- 通过 C++ 的 STL 可保持数据从 JAVA 环境的内存映射出来
|
||||
- 使用 Hadoop 的 Map/reduce 模型
|
||||
- 支持在服务器端编程
|
||||
|
||||
**Best used:** If you need a different HBase.
|
||||
**应用场景:** HBase的替代品
|
||||
|
||||
**For example:** Same as HBase, since it's basically a replacement: Search engines. Analysing log data. Any place where scanning huge, two-dimensional join-less tables are a requirement.
|
||||
**使用案例:** 与HBase一样,就是搜索引擎被换了下;分析日志数据的系统;适用于浏览大规模二维非关系型数据表。
|
||||
|
||||
##Special-purpose
|
||||
##特殊用途
|
||||
|
||||
###Neo4j (V1.5M02)
|
||||
###Neo4j V1.5M02 版
|
||||
|
||||
**Written in:** Java
|
||||
**开发语言:** Java
|
||||
|
||||
**Main point:** Graph database - connected data
|
||||
**主要特性:** 图形化数据库
|
||||
|
||||
**License:** GPL, some features AGPL/commercial
|
||||
**许可证:** GPL,AGPL(商业用途)
|
||||
|
||||
**Protocol:** HTTP/REST (or embedding in Java)
|
||||
**数据传输和存储的方式:** HTTP/REST(或内嵌在 Java 中)
|
||||
|
||||
- Standalone, or embeddable into Java applications
|
||||
- Full ACID conformity (including durable data)
|
||||
- Both nodes and relationships can have metadata
|
||||
- Integrated pattern-matching-based query language ("Cypher")
|
||||
- Also the "Gremlin" graph traversal language can be used
|
||||
- Indexing of nodes and relationships
|
||||
- Nice self-contained web admin
|
||||
- Advanced path-finding with multiple algorithms
|
||||
- Indexing of keys and relationships
|
||||
- Optimized for reads
|
||||
- Has transactions (in the Java API)
|
||||
- Scriptable in Groovy
|
||||
- Online backup, advanced monitoring and High Availability is AGPL/commercial licensed
|
||||
- 可独立存在,或内嵌在 JAVA 的应用中
|
||||
- 完全的 ACID 保证(包括正在处理的数据)
|
||||
- 节点和节点的关系都可以拥有原数据
|
||||
- 集成基于“模式匹配”的查询语言(Cypher)
|
||||
- 支持“Gremlin”图形转化语言
|
||||
- 可对节点与节点关系进行索引
|
||||
- 良好的自包含网页管理技术
|
||||
- 多个算法实现高级文件查找功能
|
||||
- 可对 key 与 key 的关系进行索引
|
||||
- 优化读性能
|
||||
- 在 JAVA API 中实现事务处理
|
||||
- 可运行脚本 Groovy 脚本
|
||||
- 在商用版本中提供在线备份,高级监控和高可用性功能
|
||||
|
||||
**Best used:** For graph-style, rich or complex, interconnected data. Neo4j is quite different from the others in this sense.
|
||||
**应用场景:** 适用于用图形显示复杂的交互型数据。
|
||||
|
||||
**For example:** For searching routes in social relations, public transport links, road maps, or network topologies.
|
||||
**使用案例:** 搜寻社交关系网、公共传输链、公路路线图、或网络拓扑结构
|
||||
|
||||
###ElasticSearch (0.20.1)
|
||||
###ElasticSearch 0.20.1 版
|
||||
|
||||
**Written in:** Java
|
||||
**开发语言:** Java
|
||||
|
||||
**Main point:** Advanced Search
|
||||
**主要特性:** 高级搜索
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** JSON over HTTP (Plugins: Thrift, memcached)
|
||||
**数据传输和存储的方式:** 通过 HTTP 使用 JSON 进行数据索引(插件:Thrift, memcached)
|
||||
|
||||
- Stores JSON documents
|
||||
- Has versioning
|
||||
- Parent and children documents
|
||||
- Documents can time out
|
||||
- Very versatile and sophisticated querying, scriptable
|
||||
- Write consistency: one, quorum or all
|
||||
- Sorting by score (!)
|
||||
- Geo distance sorting
|
||||
- Fuzzy searches (approximate date, etc) (!)
|
||||
- Asynchronous replication
|
||||
- Atomic, scripted updates (good for counters, etc)
|
||||
- Can maintain automatic "stats groups" (good for debugging)
|
||||
- Still depends very much on only one developer (kimchy).
|
||||
- 以 JSON 形式保存数据
|
||||
- 提供版本升级功能
|
||||
- 有父文档和子文档功能
|
||||
- 文档有过期时间
|
||||
- 提供复杂多样的查询指令,可使用脚本
|
||||
- 支持写操作一致性的三个级别:ONE、QUORUM、ALL
|
||||
- 支持通过分数排序
|
||||
- 支持通过地理位置排序
|
||||
- 支持模糊查询(通过近似数据查询等方式实现)
|
||||
- 支持异步复制
|
||||
- 自动升级,也可通过设置脚本升级
|
||||
- 可以维持自动的“统计组”(对调试很有帮助)
|
||||
- 只有一个开发者(kimchy)
|
||||
|
||||
**Best used:** When you have objects with (flexible) fields, and you need "advanced search" functionality.
|
||||
**应用场景:** 当你有可伸缩性很强的项目并且想拥有“高级搜索”功能。
|
||||
|
||||
**For example:** A dating service that handles age difference, geographic location, tastes and dislikes, etc. Or a leaderboard system that depends on many variables.
|
||||
**使用案例:** 可布署一个约会服务,提供不同年龄、不同地理位置、不同品味的客户的交友需求。或者可以布署一个基于多项参数的排行榜。
|
||||
|
||||
##The "long tail"
|
||||
##其他
|
||||
|
||||
(Not widely known, but definitely worthy ones)
|
||||
(不怎么有名,但值得在这里介绍一下)
|
||||
|
||||
###Couchbase (ex-Membase) (2.0)
|
||||
###Couchbase (ex-Membase) 2.0 版
|
||||
|
||||
**Written in:** Erlang & C
|
||||
**开发语言:** Erlang 和 C
|
||||
|
||||
**Main point:** Memcache compatible, but with persistence and clustering
|
||||
**主要特性:** 兼容 Memcache,但数据是持久化的,并且支持集群
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** memcached + extensions
|
||||
**数据传输和存储的方式:** 缓存和扩展(memcached + extensions)
|
||||
|
||||
- Very fast (200k+/sec) access of data by key
|
||||
- Persistence to disk
|
||||
- All nodes are identical (master-master replication)
|
||||
- Provides memcached-style in-memory caching buckets, too
|
||||
- Write de-duplication to reduce IO
|
||||
- Friendly cluster-management web GUI
|
||||
- Connection proxy for connection pooling and multiplexing (Moxi)
|
||||
- Incremental map/reduce
|
||||
- Cross-datacenter replication
|
||||
- 通过 key 访问数据非常快(20万以上IOPS)
|
||||
- 数据保存在磁盘(不像 Memcache 保存在内存中 —— 译者注)
|
||||
- 在主主互备中,所有节点数据是一致的
|
||||
- 提供类似 Memcache 将数据保存在内存的功能
|
||||
- 支持重复数据删除功能
|
||||
- 友好的集群管理 Web 界面
|
||||
- 支持池和多丛结构的代理(利用 Moxi 项目)
|
||||
- 支持 Map/reduce 模式
|
||||
- 支持跨数据中心备份
|
||||
|
||||
**Best used:** Any application where low-latency data access, high concurrency support and high availability is a requirement.
|
||||
**应用场景:** 适用于低延迟数据访问系统,高并发和高可用系统。
|
||||
|
||||
**For example:** Low-latency use-cases like ad targeting or highly-concurrent web apps like online gaming (e.g. Zynga).
|
||||
**使用案例:** 低延迟可用于广告定投;高并发可用于在线游戏(如星佳公司)。
|
||||
|
||||
###VoltDB (2.8.4.1)
|
||||
###VoltDB 2.8.4.1版
|
||||
|
||||
**Written in:** Java
|
||||
**开发语言:** Java
|
||||
|
||||
**Main point:** Fast transactions and rapidly changing data
|
||||
**主要特性:** 快速的事务处理和数据变更
|
||||
|
||||
**License:** GPL 3
|
||||
**许可证:** GPL 3
|
||||
|
||||
**Protocol:** Proprietary
|
||||
**数据传输和存储的方式:** 专有方式
|
||||
|
||||
- In-memory relational database.
|
||||
- Can export data into Hadoop
|
||||
- Supports ANSI SQL
|
||||
- Stored procedures in Java
|
||||
- Cross-datacenter replication
|
||||
- 运行在内存的关系型数据库
|
||||
- 可以将数据导入到 Hadoop
|
||||
- 支持 ANSI SQL
|
||||
- 在 JAVA 环境中保存操作过程
|
||||
- 支持跨数据中心备份
|
||||
|
||||
**Best used:** Where you need to act fast on massive amounts of incoming data.
|
||||
**应用场景:** 适用于在大量传入数据中保证快速反应能力的场合。
|
||||
|
||||
**For example:** Point-of-sales data analysis. Factory control systems.
|
||||
**使用案例:** 销售点数据分析系统;工厂控制系统。
|
||||
|
||||
###Scalaris (0.5)
|
||||
###Scalaris 0.5版
|
||||
|
||||
**Written in:** Erlang
|
||||
**开发语言:** Erlang
|
||||
|
||||
**Main point:** Distributed P2P key-value store
|
||||
**主要特性:** 分布式 P2P 键值存储
|
||||
|
||||
**License:** Apache
|
||||
**许可证:** Apache
|
||||
|
||||
**Protocol:** Proprietary & JSON-RPC
|
||||
**数据传输和存储的方式:** 自有方式和 基于JSON的远程过程调用协议
|
||||
|
||||
- In-memory (disk when using Tokyo Cabinet as a backend)
|
||||
- Uses YAWS as a web server
|
||||
- 数据保存在内存中(使用 Tokyo Cabinet 作为后台时,数据可以持久化到磁盘中)
|
||||
- 使用 YAWS 作为 Web 服务器
|
||||
- Has transactions (an adapted Paxos commit)
|
||||
- Consistent, distributed write operations
|
||||
- From CAP, values Consistency over Availability (in case of network partitioning, only the bigger partition - works)
|
||||
- 支持事务处理(基于 Paxos 提交)(Paxos 是一种基于消息传递模型的一致性算法 —— 译者注)
|
||||
- 支持分布式数据的一致性写操作
|
||||
- 根据 CAP 定理,数据一致性要求高于数据可用性(前提是在一个比较大的网络分区环境下工作)(CAP 定理:数据一致性consistency、数据可用性availability、分隔容忍partition tolerance是分布式计算系统的三个属性,一个分布式计算系统不可能同时满足全部三项)
|
||||
|
||||
**Best used:** If you like Erlang and wanted to use Mnesia or DETS or ETS, but you need something that is accessible from more languages (and scales much better than ETS or DETS).
|
||||
**应用场景:** 如果你喜欢 Erlang 并且想要使用 Mnesia 或 DETS 或 ETS,但你需要一个能使用多种语言(并且可扩展性强于 ETS 和 DETS)的技术,那就选它吧。
|
||||
|
||||
**For example:** In an Erlang-based system when you want to give access to the DB to Python, Ruby or Java programmers.
|
||||
**使用案例:** 使用基于 Erlang 的系统,但是想通过 Python、Ruby 或 JAVA 访问数据库
|
||||
|
||||
###Kyoto Tycoon (0.9.56)
|
||||
###Kyoto Tycoon 0.9.56版
|
||||
|
||||
**Written in:** C++
|
||||
**开发语言:** C++
|
||||
|
||||
**Main point:** A lightweight network DBM
|
||||
**主要特性:** 轻量级网络数据库管理系统
|
||||
|
||||
**License:** GPL
|
||||
**许可证:** GPL
|
||||
|
||||
**Protocol:** HTTP (TSV-RPC or REST)
|
||||
**数据传输和存储的方式:** HTTP (TSV-RPC or REST)
|
||||
|
||||
- Based on Kyoto Cabinet, Tokyo Cabinet's successor
|
||||
- Multitudes of storage backends: Hash, Tree, Dir, etc (everything from Kyoto Cabinet)
|
||||
- Kyoto Cabinet can do 1M+ insert/select operations per sec (but Tycoon does less because of overhead)
|
||||
- Lua on the server side
|
||||
- Language bindings for C, Java, Python, Ruby, Perl, Lua, etc
|
||||
- Uses the "visitor" pattern
|
||||
- Hot backup, asynchronous replication
|
||||
- background snapshot of in-memory databases
|
||||
- Auto expiration (can be used as a cache server)
|
||||
- 基于 Kyoto Cabinet, 是 Tokyo Cabinet 的成功案例
|
||||
- 支持多种存储后端:Hash,树、目录等等(所有概念都是从 Kyoto Cabinet 那里来的)
|
||||
- Kyoto Cabinet 可以达到每秒100万次插入/查询操作(但是 Tycoon 由于瓶颈问题,性能比 Cabinet 要差点)
|
||||
- 服务器端支持 Lua 脚本语言
|
||||
- 支持 C、JAVA、Python、Ruby、Perl、Lua 等语言
|
||||
- 使用访问者模式开发(visitor patten:让开发者能在不修改类层次结构的前提下,定义该类层次结构的操作 —— 不明白就算了,译者也不明白)
|
||||
- 支持热备、异步备份
|
||||
- 支持内存数据库在后端执行快照
|
||||
- 自动过期处理(可用来布署一个缓存服务器)
|
||||
|
||||
**Best used:** When you want to choose the backend storage algorithm engine very precisely. When speed is of the essence.
|
||||
**应用场景:** 当你想要一个很精准的后端存储算法引擎,并且速度是刚需的时候,玩玩 Kyoto Tycoon 吧。
|
||||
|
||||
**For example:** Caching server. Stock prices. Analytics. Real-time data collection. Real-time communication. And wherever you used memcached before.
|
||||
**使用案例:** 缓存服务器;股价查询系统;数据分析系统;实时数据控制系统;实时交互系统;memcached的替代品。
|
||||
|
||||
Of course, all these systems have much more features than what's listed here. I only wanted to list the key points that I base my decisions on. Also, development of all are very fast, so things are bound to change.
|
||||
当然,上述系统的特点肯定不止列出来这么点。我只是列出了我认为很关键的信息。另外科技发展迅猛,技术改变得非常快。
|
||||
|
||||
P.s.: And no, there's no date on this review. There are version numbers, since I update the databases one by one, not at the same time. And believe me, the basic properties of databases don't change that much.
|
||||
附:现在下定论比较孰优孰劣还为时过早。上述数据库的版本号以及特性我会一个一个慢慢更新。相信我,这些数据库的特性不会变得很快。
|
||||
|
||||
---
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user