时间：2021-07-01 10:21:17 帮助过：75人阅读
【51CTO外电头条】我们曾经讨论过“到底NoSQL能在我们的工作中发挥什么作用？”我们也在考虑如何选择一款NoSQL数据库方面提出过101个相关问题。我们甚至召开了一个在线研讨会，深入剖析了SQL、NoSQL或者同时应用两者在网页应用程序的扩展性方面能带来哪些助
【51CTO外电头条】我们曾经讨论过“到底NoSQL能在我们的工作中发挥什么作用？”我们也在考虑如何选择一款NoSQL数据库方面提出过101个相关问题。我们甚至召开了一个在线研讨会，深入剖析了SQL、NoSQL或者同时应用两者在网页应用程序的扩展性方面能带来哪些助益。
现在我们改变目标，转而思索哪些具体应用因素会对选择产生影响以及哪种系统在应对此类因素时更加适用。
你有什么意见？
首先，我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。
文档类数据库
传承:受Lotus Notes启发而来。
数据模型:文档汇总，包括键-值汇总。
实例: CouchDB, MongoDB
优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD（即添加、查询、更新及删除的简称）。
图形类数据库
传承:来自 Euler 及图形理论。
数据模型:节点及关系，二者结合能够保持键-值间的成对状态
实例: AllegroGraph, InfoGrid, Neo4j
优势:轻松玩转复杂的图形问题、处理速度快
关系类数据库
传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论
数据模型:以关系组为基础
实例: VoltDB, Clustrix, MySQL
优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异
面向对象类数据库
传承:源自图形数据库方面的研究成果
数据模型: 对象
实例: Objectivity, Gemstone
优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能
键-值存储
传承: Amazon Dynamo中的paper概念及分布式hash表
数据模型:对成对键-值的全局化汇总
实例: Membase, Riak
优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手
BigTable Clones
传承自:谷歌BigTable中的paper概念
数据模型:纵列群，即在某个表格模型中，每行在理论上至少可以有一套单独的纵列配置
实例: HBase, Hypertable, Cassandra
优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化
数据结构类服务
传承: 不明
实例: Redis
数据模型: 执行过程基于索引、列表、集合及字符串值
优势:为数据库应用引入前所未有的新鲜血液
网格类数据库
传承:源自数据网格及元组空间研究
数据模型:基于空间的构架
实例: GigaSpaces, Coherence
优势:优良的性能表现及上佳的交易处理扩展性
我们该为自己的应用程序选择哪套方案？
选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。
要探究哪类数据模型能够切实为我们的应用程序提供帮助，可以参考“到底NoSQL能在我们的工作中发挥什么作用？”一文。在这篇文章中，我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。
将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL，这已经不重要了。
关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来，因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。
对功能及特性的需求存在优先级，只要对这种优先级具备较为清晰的了解，我们就能够做出最佳选择。
如果我们的应用程序需要…
复杂的交易：因为没人愿意承受数据丢失，或者大家更倾向于一套简单易用的交易编程模式，那么请考虑使用关系类或网格类数据库。
例如:一套库存系统可能需要完整的ACID（即数据库事务执行四要素：原子性、一致性、隔离性及持久性）。顾客选中了一件产品却被告知没有库存了，这类情况显然容易引起麻烦。因为大多数时候，我们想要的并不是额外补偿、而只是选中的那件货品。
若是以扩展性为优先，那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。
要求持续保有数据库写入功能，则需要较高的可用性。在这种情况下不妨关注BigTable类产品，其在一致性方面表现出众。
如有大量的小规模持续读写要求，也就是说工作负载处于波动状态，可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。
以社交网络为实施重点的话，我们首先想到的就是图形类数据库；其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。
如果我们的应用程序需要…
在访问模式及数据类型多种多样的情况下，文档类数据库比较值得考虑。这类数据库不仅灵活性好，性能表现也可圈可点。
需要完备的脱机报告与大型数据集的话，首选产品是Hadoop，其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。
如果业务跨越数个数据中心，Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象，并具备较好的分区兼容性。
要建立CRUD应用程序，首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话，推荐Riak。
要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作，Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。
将数据以便于处理的形式反馈给程序员（例如以JSON、HTTP、REST、Javascript这类形式），文档类数据库能够满足这类诉求，键-值类数据库效果次之。
如果我们的应用程序需要…
以直观视图的形式进行同步交易，并且具备实时数据反馈功能，VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。
若是需要企业级的支持及服务水平协议，我们需要着眼于特殊市场。Membase就是这样一个例子。
要记录持续的数据流，却找不到必要的一致性保障？BigTable Clone交出了令人满意的答卷，因为其工作基于分布式文件系统，所以可以应对大量的写入操作。
要让操作过程变得尽可能简单，答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。
要向企业级客户做出推荐？不妨考虑关系类数据库，因为它们的长项就是具备解决繁杂关系问题的技术。
如果需要利用动态方式建立对象之间的关系以使其具有动态特性，图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型，因此可以通过编程逐步建立。
S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块，尽管MongoDB本身具备文件服务功能。
如果我们的应用程序需要…
有高效批量上传大量数据的需求？我们还是得找点有对应功能的产品。大多数产品都无法胜任，因为它们不支持批量操作。
文档类数据库或是键－值类数据库能够利用流畅的模式化系统提供便捷的上传途径，因为这两类产品不仅支持可选区域、添加区域及删除区域，而且无需建立完整的模式迁移框架。
要实现完整性限制，就得选择一款支持SQL DLL的产品，并在存储过程或是应用程序代码中加以运行。
对于协同工作极为依赖的时候就要选择图形类数据库，因为这类产品支持在不同实体间的迅速切换。
数据的移动距离较短且不必经过网络时，可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。
如果我们的应用程序需要…
键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储，这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。
对于数据安全及工作状态要求较高的话可以尝试使用定制产品，并且在普遍的工作范畴（例如向上扩展、调整、分布式缓存、分区及反规范化等等）之外一定要为扩展性（或其它方面）准备解决方案。
多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分，其复杂的结构及用户组成（也可能还有其它各种因素）只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。
有时其它业务部门会需要进行快速关系查询，引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。
如果我们的应用程序需要…
支持辅助索引，以便通过不同的关键词查找数据，这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。
创建一套处于不断增长中的数据集合（真正天文数量级的数据）然而访问量却并不大，那么Bigtable Clone是最佳选择，因为它会将数据妥善安排在分布式文件系统当中。
需要整合其它类型的服务并确保数据库提供延后写入同步功能？那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。
通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。
若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖，不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。
尝试在移动平台上工作并关注CouchDB及移动版couchbase。
哪种方案更好？
25%的状态改善尚不足以让我们下决心选择NoSQL。
选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗？
如果你的公司尚处于起步阶段，并且需要尽快推出自己的产品，这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。
性能表现在一台主机上来说也许差别并不大，但如果我们要将其部署在N多台主机上呢？
世上万物皆不完美，如果大家常逛Amazon论坛就会发现上面的EBS响应缓慢，当然没准我这属于特例。不过GAE的数据存储体系响应也很缓慢，有时甚至干脆显示红叉。每种我们使用着的产品都存在诸多问题，但对于自己亲手选择的方案，你能接受它所存在的问题吗？