现在我们站在各个用例的角度上来考虑那种系统适合于这些用例。

你的意见是?

首先，我们要纵览各种数据模型。这些模型的分类方法来自于Emil Eifrem 和 NoSQL databases。

文档数据库

  • 源起：受Lotus Notes启发。
  • 数据模型：包含了key-value的文档集合
  • 例子：CouchDB, MongoDB 
  • 优点：数据模型自然，编程友好，快速开发，web友好，CRUD。







图数据库



  • 源起： 欧拉和图理论。
  • 数据模型：节点和关系，也可处理键值对。
  • 例子：AllegroGraph, InfoGrid, Neo4j
  • 优点：解决复杂的图问题。









关系数据库





对象数据库

  • 源起：图数据库研究
  • 数据模型：对象
  • 例子：Objectivity, Gemstone
  • 优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点。

Key-Value数据库

  • 源起：Amazon的论文 Dynamo 和 Distributed HashTables。
  • 数据模型：键值对
  • 例子：Membase, Riak
  • 优点：处理大量数据，快速处理大量读写请求。编程友好。







BigTable类型数据库



  • 源起：Google的论文 BigTable。
  • 数据模型：列簇，每一行在理论上都是不同的
  • 例子：HBase, Hypertable, Cassandra
  • 优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。









数据结构服务



  • 源起： ?
  • 数据模型：字典操作，lists, sets和字符串值
  • 例子：Redis
  • 优点：不同于以前的任何数据库









网格数据库



  • 源起：数据网格和元组空间研究。
  • 数据模型：基于空间的架构
  • 例子：GigaSpaces, Coherence
  • 优点：适于事务处理的高性能和高扩展性



你的应用应该用什么?

  • 关键是要意识到不同的应用需要不同的数据模型和产品。选择合适的数据模型和产品。
  • What The Heck Are You Actually Using NoSQL For?
  • 适应你的需求和应用场景。依次而为你就能找到最适合你的架构的产品。无论NoSQL还是SQL都不重要。
  • 综合考虑数据模型、产品特性和应用情景。不同产品功能各异，只凭数据模型来决定选择谁是不可能的。
  • 哪个产品具有你最需要的特点哪个就是最好的。

假如你的应用有以下需求：

  • 例子：一个库存系统需要完整的ACID特性。如果我在买了一个东西后才被告知它已经售罄我会非常不快。不不想要补偿，我只要我买的东西。
  • 扩展性，NoSQL或SQL皆可，目标产品要支持水平扩展、分区、在线增减硬件、负载均衡、自动分片、数据平衡和容错等特性。
  • 追求高可用性，可用Bigtable类型的等支持最终一致性的数据库。
  • 需要处理长期的快速读写，可以看看文档数据库，Key-value数据库或者内存数据库，还可以考虑SSD。
  • Riak这样支持关系的数据库也可以。一个支持简单SQL join操作的内存关系数据库能够处理数据量不大的情况。Redis' set 和list 操作就是这样。

假如你的应用有以下需求：

  • 需要不同的访问方式和数据类型的话可以看看文档数据库，它们在这方面很灵活。
  • 大数据量的离线分析首先应该考虑Hadoop，其次是其他支持MapReduce的产品。当然，支持MapReduce与擅长MapReduce处理不是一回事。
  • 如需跨越多个数据中心，可选用基于Bigtable模型的产品，或其分布式的，能解决延迟问题，分区容错性问题的产品
  • CRUD类型的应用可以考虑文档数据库，这样不需要join就可访问复杂的数据结构。
  • 搜索可以考虑Riak。
  • 需要lists, sets, queues, publish-subscribe等数据结构的话，可以考虑Redis，它的分布式锁等特性也非常有用。
  • 编程友好，如果要使用JSON, HTTP, REST, Javascript等程序员喜闻乐见的数据类型，第一选择就是文档数据库和Key-value数据库。

假如你的应用有以下需求：

  • 用于实时事务处理的物化视图，可以考虑VoltDB，非常适合于快速处理大量事务。
  • 企业级支持及服务级协议
  • 要记录连续的大量数据，又对一致性无太高要求，可以看看Bigtable类型数据库，因为它工作在分布式文件系统上，可以处理大规模的写入请求。
  • 需要尽可能使用简单，请考虑PAAS方案，用这种方案你自己几乎不需要做什么。
  • 如果你的产品要卖给企业客户请考虑关系数据库，因为他们习惯于关系数据库。
  • 要动态构建对象间的关系，对象的属性能够动态加减，可以考虑图数据库，因为它不需要schema，可以在代码中随需建模。
  • 要支持大影音文件，可以看看像S3这样的存储服务。NoSQL不适于存储BLOBS，尽管MongoDB也提供了文件服务。

假如你的应用有以下需求：

  • 要快速批量上传大量数据，得寻找支持这种场景的产品。但是大多数产品都不支持批量操作。
  • 易于变化，要选择支持动态schema的文档数据库和 Key-value数据库。它支持可选域，不需要修改schema即可增加、减少域。
  • 为了支持完整性约束，选择支持SQL DDL的数据库，可以在存储过程或者应用代码中实现。
  • 深度连接用图数据库，它支持实体键间的快速定位。
  • 为了让计算靠近数据，减少数据在网络中传送的开销，可以考虑存储过程。关系数据库，网个数据库，文档数据库和Key-value数据库都支持存储过程。

假如你的应用有以下需求：

  • 要存储BLOB数据，可选择Key-value数据库。它可以存储网页或者复杂对象，后者在关系数据库中要用join才能获取，代价高昂。还可以降低延迟。
  • 选择一个经过验证的成熟产品，在处理扩展性问题的时候的时候选择通用的方案（纵向扩展、调优、缓存、数据分片、反范式等等）
  • 多变的数据类型，数据不规整，列数不固定，复杂的数据结构等，考虑文档数据库，Key-value数据库，和Bigtable型数据库。它们的数据类型都比较灵活。
  • 需要快速的关系查询，但是又不想自己实现，那么就选择支持SQL的数据库。
  • 能够在云中操作，自动利用云的一切特性和好处，目前还没有这样的东西。

假如你的应用有以下需求：

  • 支持二级索引，通过不同的键来检索，可以考虑关系数据库和 Cassandra，后者新增了对二级索引的支持。
  • 规模不断增长（真正的大数据场景），但是访问不频繁的数据可以使用Bigtable类型的数据库，因为它的数据存储在一个分布式文件系统上，很容易扩展 。
  • 要和其他服务集成，检查数据库是否提供某种写后同步功能，以便能够捕捉到数据库变化，通知其它系统，保证一致性。
  • 容错性，检查在停电、分区故障以及其他故障场景下写操作是否能够成功。
  • 如果只是为了推动某个方向上的技术创新，似乎没有现成的东西能够达到这个目的，你得自己去创造一个新的。这可不是件容易事。
  • 移动平台上可以用CouchDB/Mobile couchbase.

那个更好?

  • 为了25%的性能提升而迁移到NoSQL是不值得的。
  • 性能测试数据都有其特定的场景，不见得能适合你的情况。 
  • 如果你的公司刚刚成立，还没有一个成型的产品，并且你很愿意尝试一些新东西，那么选择SQL还是NoSQL对你而言需要费上些心思（言下之意，一张白纸好作画，没有既有系统的负担就可以随便折腾？）。
  • 数据量不大的时候性能差距并不明显，但是当数据量变大的时候呢？
  • 没有完美的东西，如果你去Amazon的论坛上去看，上面充满了对各种产品的性能和服务的抱怨，GAE也是一样。每个产品都会有问题，你能解决你选择的产品的问题吗？