- A+
本文翻译自 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也是一样。每个产品都会有问题，你能解决你选择的产品的问题吗？
- 我的微信
- 这是我的微信扫一扫
-
- 我的微信公众号
- 我的微信公众号扫一扫
-
