NoSQL数据库的35个应用场景-转载

标签: 转载文章 | 发表时间:2013-04-15 22:39 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
中午原文: http://news.cnblogs.com/n/172096/

英文原文:35+ Use Cases For Choosing Your Next NoSQL Database,编译:Juliashine

  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.

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

文档数据库

  • 源起:受 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,非常适合于快速处理大量事务。
  • 企业级支持及服务级协议 ,可以寻找市场上以此为卖点的产品,如 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 也是一样。每个产品都会有问题,你能解决你选择的产品的问题吗?

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [nosql 数据库 应用] 推荐:

NoSQL数据库的35个应用场景-转载

- - 人月神话的BLOG
中午原文: http://news.cnblogs.com/n/172096/. 英文原文:35+ Use Cases For Choosing Your Next NoSQL Database,编译:Juliashine.   现在我们站在各个用例的角度上来考虑哪种系统适合于这些用例. 源起:受 Lotus Notes 启发.

如何让NoSQL内存数据库适合企业级应用

- - CSDN博客数据库推荐文章
如何让NoSQL内存数据库适合企业级应用. 作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 英文原文: How to Make Your In-memory NoSQL Datastores Enterprise-Ready. 对于每一个关注用户体验的Web应用或移动应用而言,NoSQL内存数据库(例如开源的 Redis和Memcached)正逐步成为事实上的标准.

Oracle 发布 NoSQL 数据库

- 冷月 - 博客园新闻频道
  Oracle 作为全球最大的关系型数据库提供商,在其产品链条中,也加入了 NoSQL 数据库这一环,而且这个新的数据库名字很霸气,就叫 NoSQL Database,想起了当年新浪微博更换 weibo.com 域名之时的一个笑话:. 原来有三家人做面包,张三家的面包叫三张牌面包,李四家的牌子叫李四牌面包,王五家出品的是王五牌面包,而突然有一天,张三家的面包改名了,叫面包牌面包.

nosql数据库选型

- - IT技术博客大学习
标签:   nosql   选型.    今天在书店里翻完了一遍《七天七数据库》. 这本书简单介绍了postgreSQL,riak,mongodb,HBase,riak,Neo4j,redis七个数据,并着重谈了数据库的特性差异和在部署维护时候的特点,并对不同需求下的数据库选型做了很多建议,感觉受益非浅.

NoSQL数据库面面观

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站原创的文章,原文地址是:. Alexey Vasiliev是一位知名的Web开发者与Linux系统管理员,曾参与开发过多个项目,如 falcon、 mongodb_logger、 sht_rails及 piro等项目. 近日,Vasiliev就当前各种NoSQL数据库的优势与劣势 撰文进行了详尽的分析.

NoSQL数据库的出现及选择哪种NoSQL数据库

- - 数据库 - ITeye博客
    在没有NOSQL数据时,关系型数据库一直是数据持久化的唯一选择,比较典型的关系型数据库有SQL Server、Oracle,MySQL,DB2.做.NET开发的同学一般会选择SQL Server,做JAVA的可能会偏向Oracle,MySQL,Python则是PostgreSQL或MySQL等等.

8种Nosql数据库系统对比

- xcv58 - 伯乐在线 -博客
  导读:Kristóf Kovács 是一位软件架构师和咨询顾问,他最近发布了一片对比各种类型NoSQL数据库的文章. 文章由敏捷翻译 - 唐尤华编译.   虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破. 这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举.

Couchbase Server 2.0 发布,NoSQL 数据库

- - 开源中国社区最新新闻
Couchbase Server 2.0 发布了,主要特性包括:. 增量 Map Reduce. 详细功能描述和下载地址请看:. Couchbase Server (前身是 Membase) 是一个分布式的面向文档的 NoSQL 数据库管理系统,该系统联合了 CouchDB 的简单和可靠以及 Memcached 的高性能以及 Membase 的伸缩性.

NoSQL数据库的分布式算法

- - NoSQLFan
本文英文原文发表于知名技术博客《 Highly Scalable Blog》,对NoSQL数据库中的 分布式算法和思想进行了详细的讲解. 文章很长,由@ 可观 进行翻译投稿. 英文原文:《 Distributed Algorithms in NoSQL Databases》. 译文地址:《 NoSQL数据库的分布式算法》.

NoSQL反模式 - 文档数据库篇

- - 我自然
我们设计关系数据库Schema的都有一套完整的方案,而NoSQL却没有这些. 半年前笔者读了本《SQL反模式》的书,觉得非常好. 就开始留意,对于NoSQL是否也有反模式. 好的反模式可以在我们设计Schema告诉哪里是陷阱和悬崖. NoSQL宣传的时候往往宣称是SchemaLess的,这会让人误解其不需要设计Schema.