数据库各个派系的起源和应用场景

数据库各个派系的起源和应用场景

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

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

文档数据库

源起：受Lotus Notes启发。

数据模型：包含了key-value的文档集合

例子：CouchDB, ***

优点：数据模型自然，编程友好，快速开发，web友好，CRUD。

图数据库

源起： 欧拉和图理论。

数据模型：节点和关系，也可处理键值对。

例子：AllegroGraph, InfoGrid, ***

优点：解决复杂的图问题。

关系数据库

源起： 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。

数据模型：列簇，每一行在理论上都是不同的

例子：***, Hypertable, ***

优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。

数据结构服务

源起： ?

数据模型：字典操作，lists, sets和字符串值

例子：Redis

优点：不同于以前的任何数据库

网格数据库

源起：数据网格和元组空间研究。

数据模型：基于空间的架构

例子：GigaSpaces, Coherence

优点：适于事务处理的高性能和高扩展性

你的应用应该用什么?

关键是要意识到不同的应用需要不同的数据模型和产品。选择合适的数据模型和产品。

要了解你的应用需要什么样的数据模型可以看 What The Heck Are You Actually Using NoSQL For? 在这篇文章里我总结了一些特色各异的非常规的使用场景。

适应你的需求和应用场景。依次而为你就能找到最适合你的架构的产品。无论NoSQL还是SQL都不重要。

综合考虑数据模型、产品特性和应用情景。不同产品功能各异，只凭数据模型来决定选择谁是不可能的。

哪个产品具有你最需要的特点哪个就是***的。

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

复杂事物，如果你不能承受数据丢失的风险或者你想要一个简单的事务编程模型可以选择关系数据库和网格数据库。

例子：一个库存系统需要完整的ACID特性。如果我在买了一个东西后才被告知它已经售罄我会非常不快。不不想要补偿，我只要我买的东西。

扩展性，NoSQL或SQL皆可，目标产品要支持水平扩展、分区、在线增减硬件、负载均衡、自动分片、数据平衡和容错等特性。

追求高可用性，可用Bigtable类型的等支持最终一致性的数据库。

需要处理长期的快速读写，可以看看文档数据库，Key-value数据库或者内存数据库，还可以考虑***。

要实现社会化网络，***选择应该是图数据库。其次像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，尽管***也提供了文件服务。

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

要快速批量上传大量数据，得寻找支持这种场景的产品。但是大多数产品都不支持批量操作。

易于变化，要选择支持动态schema的文档数据库和 Key-value数据库。它支持可选域，不需要修改schema即可增加、减少域。

为了支持完整性约束，选择支持SQL DDL的数据库，可以在存储过程或者应用代码中实现。

深度连接用图数据库，它支持实体键间的快速定位。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。