NoSQL数据库的35个应用场景

本文另外一地址请见 NoSQL数据库的35个应用场景

本文翻译自 35+ Use Cases For Choosing Your Next NoSQL Database

以前有三篇文章

What The Heck Are You Actually Using NoSQL For?. 

101 Questions To Ask When Considering A NoSQL Database. 

What Should I Do? Choosing SQL, NoSQL or Both for Scalable Web Applications.

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

你的意见是?

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

文档数据库

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

图数据库

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

关系数据库

• 源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
• 数据模型：各类关系
• 例子：VoltDB,  Clustrix, MySQL
• 优势：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好。

对象数据库

• 源起：图数据库研究
• 数据模型：对象
• 例子：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，很是适合于快速处理大量事务。
• 企业级支持及服务级协议 ，能够寻找市场上以此为卖点的产品，如Membase。
• 要记录连续的大量数据，又对一致性无过高要求，能够看看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也是同样。每一个产品都会有问题，你能解决你选择的产品的问题吗？