4228 条评论分享收藏感谢收起赞同 15022 条评论分享收藏感谢收起本文为阅读书籍 第7章: The End of Disk? SSD and In-Memory Databases的笔记。
比尔.盖茨在1981年曾说过：
640K of memory should be enough for anybody.
在2001年，他意识到之前的说法是错误的：
I’ve said some stupid things and some wrong things, but not that.
从第一个数据库诞生以来，数据库专家就一直努力尽量避免磁盘I/O，因为磁盘比内存，CPU慢好几个数量级。
在CPU，内存和磁盘的密度遵循摩尔定律飞速发展时，由于磁盘的机械特性，磁盘速度的进展却远远滞后。
SSD的产生使磁盘的性能带来了飞跃，最近几年价格下降使得其成为了提升数据库性能的主流技术。与此同时，内存容量的增加以及价格的下降也使得内存技术成为加速数据库性能的另一选择，一些小的数据库可以完全放置于内存中，通过内存集群也可以容纳更大的数据库。在对性能要求严苛的环境下，内存比SSD更具吸引力。
磁盘发展于上世纪50年代，尽管磁盘密度不断提升，但磁盘的核心架构却基本未变，还是机械臂移动磁头到盘片的磁道上读取数据而已。
机械磁盘之后，又有了固态硬盘(SSD)，SSD没有移动部件，I/O延迟低。目前，大部分的SSD都是用NAND flash实现的。
SSD对于读的性能实现了较大的提升，例如，机械磁盘的随机读需要4毫秒，而高端SSD只需要25微秒，快了150倍。
但SSD并不能适用所有的工作负载，对于修改操作，SSD就表现一般了。
SSD将信息存于cell中，对于SLC，每一个cell存一个bit信息，对于MLC，每一个cell通常存两个bit，或3个bit信息。cell组织成4k的page，256 page又组织成block。
Read operations, and initial write operations, require only a single-page IO. However, changing the contents of a page requires an erase and overwrite of a complete block.
这就是SSD的软肋了，SSD对于写的性能远低于读，比物理磁盘也许也快不了多少。
flash SSD is significantly slower when performing writes than when performing reads.
由于SSD有一定的擦写寿命，为了避免erase操作的开销，厂商使用了’wear leveling’的技术，通过均匀的分布写来延长磁盘寿命。解释如下，详见。
Wear-leveling is a technique that spreads the memory use evenly to different physical pages so that the entire NAND Flash devices is used evenly to maximize the life span of the device and the system.
SSD会替代磁盘吗? 目前应不会，虽然SSD的成本在降，磁盘的成本也同时在降。SSD的单位I/O能力强，磁盘具更好单位成本优势。比较合理的结果是内存，SSD和磁盘的结合。
SSD适合于随机写，物理磁盘适合于顺序写，在SSD上运行数据库性能未必会提升。例如当交易提交时，会写redo log，这就是顺序写。因此对于写密集的数据库是不适合SSD的。
内存数据库
SSD对于数据库架构的改变是渐进式的，随着内存价格的下降和容量的增加，将整个数据库置于内存中则带来革命性的架构变化。 （参见）
对于中小型的数据库，已经可以完全置于内存中，更大容量的数据库则可以通过内存集群技术来利用内存的性能。
传统的数据库利用内存作为缓存来提升性能，但一些操作如commit和checkpoint还是会访问物理磁盘，因此内存数据库需要架构上的改变，即不使用cache和新的持久化模式。
内存数据通常使用以下的技术来保证数据不丢失：
1. 数据复制
2. 将整个数据库映像写盘(snapshot或checkpoint)
3. 将事务写入事务日志或journal
TimesTen是发展较早的关系型内存数据库，成立于1995年，2005年被Oracle收购。
TimesTen早期遵循ANSI-SQL标准，被收购后，又扩展了PL/SQL。
TimesTen数据库的整个数据库都置于内存中，通过checkpoint和事务日志技术保证数据不丢失。
和Oracle不同，缺省模式下，写是异步的，这可能会造成数据丢失，因此ACID中的Durability并不能保证。虽然也可以指定同步模式，但这样会影响性能。
TimesTen的架构如下图:
和TimesTen的关系型内存数据库不同，Redis (Remote Dictionary Server)采用的是key-value内存存储。
Redis产生于2009，之后VMware和Pivotal对其进行了资助。
Redis的查询只支持主键作为key，不支持二级查询。value方面通常是string集合, 如list, hash map等。
虽然Redis的设计是将整个数据库置于内存中，但也可以结合磁盘来容纳更大的数据库。 此功能TimesTen不具备。
it is possible for Redis to operate on datasets larger than available memory by using its virtual memory feature. When this is enabled, Redis will “swap out” older key values to a disk file. Should the keys be needed they will be brought back into memory. This option obviously involves a significant performance overhead, since some key lookups will result in disk IO.
Redis持久化的策略和TimesTen类似，也是使用snapshot和Journal（redis的术语称为Append Only File 或AOF）。Redis也支持异步的数据复制，但也不能完全保证数据不丢失。
Redis的AOF可以配置为每一个操作后都写，这类似于TimesTen的Durable Commit，对性能有影响。
Redis的架构如下图：
Redis is popular among developers as a simple, high-performance key-value store that performs well without expensive hardware. It lacks the sophistication of some other nonrelational systems such as MongoDB, but it works well on systems where the data will fit into main memory or as a caching layer in front of a disk-based database.
SAP在2010年推出了HANA，主要用于BI，但也可用于OLTP。
HANA也是关系型数据库，数据表可以选择列式或行式存储，两者只能选一，通常OLTP选用行式，而BI选用列式。后面会提到Oracle 12c中的In-memory对于一个表同时支持行式和列式。
行式数据确保在内存中，列式数据缺省从磁盘中加载。而对于Oracle In-memory，行式数据使用以前的缓存技术，列式数据和HANA类似。
HANA的持久化策略和TimesTen，Redis类似，也是定期将内存写入Savepoint文件中，之后与数据文件合并。
事务一致性通过事务日志保证，在commit时写日志，为避免I/O性能影响，HANA建议将日志置于SSD盘上。
HANA的架构如下图：
此图需要说明的是，对于列式存储表的写首先是存为非压缩的行式（L1 Data Store），然后转化为压缩的列式（L2 Data Store）
Transactions to columnar tables are buffered in this delta store. Initially, the data is held in row-oriented format (the L1 delta). Data then moves to the L2 delta store, which is columnar in orientation but relatively lightly compressed and unsorted. Finally, the data migrates to the main column store, in which data is highly compressed and sorted.
HANA在commit和列式表按需从磁盘载入内存时会涉及到磁盘操作。
TimesTen，HANA，Redis都不可避免的有磁盘读写，而VoltDB号称纯内存数据库，交易在内存中提交，然后通过内存复制实现持久化。例如如果要保证 K-safety为2，则需要至少复制到两台机器。
VoltDB也支持磁盘日志，可以是同步或异步的。
VoltDB支持关系型模式，不过最适合的还是基于key将数据分片或分区分布。如果数据间没有关联可以大大提高并非性，如果需要聚集操作则需访问多个节点，存在开销。
更多的细节可以参见。
Oracle 12c “in-Memory Database”
In-Memory是12的一个option，是用列式存储来补充基于磁盘的行式存储的，主要是用来应对HANA的。 所以并非所有数据都在内存中。每个表都有行式和列式两种格式，对于用户是透明的，应用无需更改。
Oracle 12c In-Memory的架构如下：
上图中IMCU表示列式存储，In-Memory Columnar Unit，而Snapshot Metadata Unit (SMU) 是用来跟踪IMCU中数据的有效性的(是否被OLTP应用修改)，以与行式数据同步。
Oracle的这篇文章很好的阐述了TimesTen和In-Memory的区别。
Berkeley Analytics Data Stack and Spark
如果说TimesTen和HANA适合内存关系型，Redis适合内存key-value，则Spark适合内存Hadoop。
Hadoop已成为大数据处理的基石，传统的MapReduce基于磁盘，适合于批量处理非结构化和半结构化数据。而Spark的出现则将Hadoop带人实时处理的领域。
2011年，AMPlab在加州伯克利大学成立，来解决大数据环境下的高级分析和机器学习的问题，随后推出的Berkeley Data Analysis Stack (BDAS)包括Spark，Mesos（内存集群管理，类似于YARN）和Tachyon（内存分布式文件系统），其中Spark得到了大量采用。
Spark是基于内存的具有容错的分布式处理框架，它将MapReduce做了上层抽象，从而提高了开发效率，同时解决了传统MapReduce的磁盘I/O问题。
Spark和Hadoop紧密配合，并使用HDFS做持久化。
Spark也支持SQL，
Spark SQL provides a Spark-specific implementation of SQL for ad hoc queries, and there is also an active effort to allow Hive— the SQL implementation in the Hadoop stack—to generate Spark code.
Spark, Hadoop, and the Berkeley Data Analytics Stack的框架如下：
Cloudera, Hortonworks和MapR都集成了Spark。
Spark基于JVM实现，Spark可以存储string, Java对象，主要还是key-value存储。
Spark虽希望将数据在内存中处理，但Spark还是主要用于无法将所有数据完全置于内存中的情形。
Spark并非面向OLTP，因此也就没有事务日志的概念。
Spark也可以访问JDBC兼容的数据库，包括几乎所有的关系型数据库，以及NoSQL数据库如HBase 或 Cassandra。
Spark的处理流程如下图：
断言磁盘已死还为时过早，毕竟磁盘对于冷数据和温数据具成本优势，特别是在大数据时代。
当性能的需求比存储成本更重要时，就可以考虑SSD和内存数据库，特别是当数据库可以整个置于内存中时，内存数据库具有更大的吸引力。
总之，没有一种技术可以解决所有问题，这取决于你的需求，预算等因素，更多看到的应是磁盘，SSD和内存技术的结合。
基于SSD固态硬盘的数据库性能优化
基于SSD的数据库性能优化
数据库采用SSD效率会高吗？
如何在数据库应用中发挥SSD的优势
内存数据库主流的有哪些，并给出各自特点！
常用内存数据库介绍
主流内存数据库对比
SSD内部原理
没有更多推荐了，随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付 web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：1、High performance - 对数据库高并发读写的需求
web2.0 网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的 BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似 Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了 2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：1、数据库事务一致性需求很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。2、数据库的写实时性和读实时性需求对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。3、对复杂的SQL查询，特别是多表关联查询的需求任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类：一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：
Redis 是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有 github，Engine Yard。
TC 和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理 4-5万次读写操作。
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是 TC受到大家欢迎的主要原因之一，有一个Ruby的项目将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT 在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的 NoSQL数据库。
TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。
这个是Tim Yang做的一个
TC 是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给 TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：
MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的 bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的 10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读写性能，我（robbin）也打算有空的时候好好测试一下。
因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。
MongoDB也有一个ruby的项目，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。
2、CouchDB
CouchDB 现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于 HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：
Cassandra 项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的 Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说 Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：，有非常详细的介绍。
Cassandra 以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
Voldemort 是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个 SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在 Cassandra这么热门的主要原因。
如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说 NoSQL数据库领域也是博大精深的，我（robbin）也只能浅尝辄止，我（robbin）写这篇文章既是自己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。
从我（robbin）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能 NoSQLDB和海量存储NoSQLDB）都是我很感兴趣的，特别是Redis，TT/TC和MongoDB这3个NoSQL数据库，因此我接下来将写三篇文章分别详细介绍这3个数据库。
Redis（一）----NoSQL概述
NoSQL 发展，数据库发展MySQL瓶颈
nosql数据库与内存数据库
没有更多推荐了，摘要：与关系数据库相比，每个NoSQL都有自己不同的适用场景，这里带大家盘点文档数据库、图数据库、键值数据存储、列存储数据库与内存数据网络等领域的常用的NoSQL。
在几年内，NoSQL数据库一直以性能、可扩展性、灵活的模式和分析能力聚焦着人们的注意力。尽管关系型数据库对于某些用例来说仍是一个不错的选择，就像结构数据和要求ACID事务的应用，但是NoSQL在以下用例中将更具优势：
存储的数据实质上是半结构化或者松散的。 要求一定的等级的性能和扩展性。 存取该数据的应用与最终的一致性相吻合。 非关系型数据库典型支持以下功能：
灵活的模式 无共享架构 分片作为数据存储模型的一部分 异步复制 使用BASE替代ACID事务 InfoQ英文网对当下经常使用的NoSQL数据库进行了盘点： 文档数据库
：开源、面向文档，也是当下最人气的NoSQL数据库。
：Apache CounchDB是一个使用JSON的文档数据库，使用Javascript做MapReduce查询，以及一个使用HTTP的API。
：NoSQL文档数据库基于JSON模型。
：RavenDB是一个基于.net语言的面向文档数据库。
：MarkLogic NoSQL数据库用来存储基于XML和以文档为中心的信息，支持灵活的模式。
： Neo4j是一个图数据库；支持ACID事务（原子性、独立性、持久性和一致性）
：一个图数据库用来维持和遍历对象间的关系，支持分布式数据存储。
：AllegroGraph是结合使用了内存和磁盘，提供了高可扩展性，支持SPARQ、RDFS++和Prolog推理。
其他图数据库。
键值数据存储
：Riak是一个开源，分布式键值数据库，支持数据复制和容错。
：Redis是一个开源的键值存储。支持主从式复制、事务，Pub/Sub、Lua脚本，还支持给Key添加时限。
：Dynamo是一个键值分布式数据存储。它直接由亚马逊Dynamo数据库实现；在亚马逊S3产品中使用。
：来自Oracle的键值NoSQL数据库。它支持事务ACID（原子性、一致性、持久性和独立性）和JSON。
：具备数据备份和分布式键值存储系统。
：具备数据备份和分布式键值存储系统。
：Aerospike数据库是一个键值存储，支持混合内存架构，通过强一致性和可调一致性保证数据的完整性。
列存储数据库
：Cassandra是列存储数据库，支持跨数据中心的数据复制。它的数据模型提供列索引，log-structured修改，支持反规范化，实体化视图和嵌入超高速缓存。
：Apache Hbase源于Google的Bigtable，是一个开源、分布式、面向列存储的模型。在Hadoop和HDFS之上提供了像Bigtable一样的功能。
：Amazon SimpleDB是一个非关系型数据存储，它卸下数据库管理的工作。开发者使用Web服务请求存储和查询数据项。
：Apache Accumulo的有序的、分布式键值数据存储，基于Google的BigTable设计，建立在Apache Hadoop、Zookeeper和Thrift技术之上。
：Hypertable是一个开源、可扩展的数据库，模仿Bigtable，支持分片。
：Windows Azure Table Storage Service为要求大量非结构化数据存储的应用提供NoSQL性能。表能够自动扩展到TB级别，能通过REST和Managed API访问。
其它列存储数据库。 内存数据网格
：Hazelcast CE是一个开源数据分布平台，它允许开发者在数据库集群之上共享和分割数据。
：Oracle的内存数据网格解决方案提供了常用数据的快速访问能力，一致性支持事务处理能力和数据的动态划分。
：来自Terracotta的分布式内存管理解决方案。这项产品包括一个Ehcache界面、Terracotta管理控制台和BigMemory-Hadoop连接器。
：Vmware vFabric GemFire是一个分布式数据管理平台，也是一个分布式的数据网格平台，支持内存数据管理、复制、划分、数据识别路由和连续查询。
：Infinispan是一个基于Java的开源键值NoSQL数据存储，和分布式数据节点平台，支持事务，peer-to-peer 及client/server 架构。
：分布式、面向对象、基于内存、SQL+NoSQL键值数据库。支持ACID事务。
：GigaSpaces内存数据网格能够充当应用的记录系统，并支持各种各样的高速缓存场景。
原文链接： （编译/陈翔宇 审校/仲浩）
没有更多推荐了，