究竟哪种NoSQL数据库适合你？
由于NoSQL能够支持大数据的3V：数量、种类和速度，如今许多企业组织将目光转向这种非关系型数据库，可是你知道该选择哪一种NoSQL数据库吗？
NoSQL数据库可能很适合许多项目，但是为了力求降低开发和维护成本，你需要评估每一个项目的具体要求，以确保符合特定的标准。牢记一点：问题的关键不仅仅在于能够开发指定的应用程序，还意味着多年后生产环境的范围和规模可能急剧增加，能够轻松地管理和支持应用程序。我有个客户在不到4年的时间内，企业规模就扩大了12倍。
有鉴于此，下一步就是识别哪个类别的NoSQL最适合你的要求。NoSQL数据库有四大类：
键值（KV）数据库将数据作为关联阵列（又叫映射图或字典）存储起来，键具有唯一性，充当访问值（数据）的主要手段。许多键值数据库能支持基本键值架构上面更丰富、更复杂的数据模型。
文档型数据库以一种层次格式（比如JSON和XML）存储文档，文档含有键值组合。由于这是NoSQL，因而不需要任何关系型数据库模式，每个文档的结构可以与同一数据库中的其他文档不一样。
列数据库是一种稀疏矩阵系统，它使用行和列作为键，类似哈希表或字典，将键映射成一组键值对。可能会有好多列，但是每个记录只使用它需要的列，所以记录实际上相对比较小。
图形数据库与另外几类数据库大不相同。它们专注于实体之间的关系。节点就是人员或对象之类的实体，它们之间的边缘详述描述了节点之间的关系的类型。
虽然为数据库分门别类是可行的，但是许多厂商把更先进的功能特性堆叠到基本配置上，提供了更丰富的数据模型和高级功能。所以，虽然有行业定义的类别，但是许多NoSQL数据库拥有无法轻松塞入到一个设备里面的功能。
你在开始评估数据库时，要考虑到这一点：一些键值数据库功能如同文档型数据库，或文档型数据库功能如同图形数据库；如果你只考虑图形数据库这一类数据库，说不定文档型数据库可能比你物色的图形数据库还要合适。
为你的项目明确定义参数，比如数据（哪种数据、多少数据、数据大小如何、数据格式和来源），准备如何使用数据，预计会出现什么样的增长，你的站点有几个并发用户，性能，正常运行时间，等等。要知道哪些标准对贵公司的需求必不可少，然后按重要性依次排列。正如你所见，这是一份长长的清单，但是它让你得以提出正确的问题，从而有助于评估工作。
评估解决方案时要考虑的一些因素如下：
可扩展性：可扩展性涉及许多方面。单单就数据而言，你要明白每天会给数据库添加多少数据，数据过了多久会过时，准备如何处理旧数据（卸载到另一个存储系统以供分析，将它保留在数据库中但迁移到不同的存储层，还是兼而有之？），该数据来自哪里，需要对数据进行什么处理（任何预处理？），将该数据添加到数据库有多容易？它来自什么数据源？实时还是批量？
在一些情况下，你的总数据量保持一样；在另一些情况下，数据日积月累、越来越多。你的数据库将如何处理这种增长？你的数据库可以通过添加新资源（比如服务器或存储空间）来轻松扩展吗？添加资源有多容易？数据库能够自动重新分配数据，还是说它需要人工干预？在这个过程中会不会出现任何停机时间？
需要几台服务器、哪种类型的磁盘容量才能处理你所要存储的数据？太多的服务器意味着硬件、数据中心和人员方面更高的成本。在一些情况下，数据使用方面可能出现相当显著的高峰和低谷，比如黑色星期五的电子商务（12月份的节假日购物旺季）。规模扩增或缩减有多容易？在资源使用量较大的时段可以使用云吗？
你必须能够对数据和数据库增长的方方面面做好预测。不管数据库处理这一切的能力有多强，还是应该不断监控资源使用情况，那样才能积极主动地扩增资源，以便从容应对使用情况，而不是让数据库不堪重负。
正常运行时间：应用程序对于何时需要访问有不同的要求，有些只在交易时段需要访问，有些需要全天候不间断访问，可用性还要达到99.999%（不过它们其实意味着100%的时段可以访问）。这有可能吗？绝对有可能！
这涉及许多功能特性（比如复制），所以数据库里面有多个数据副本。万一某个节点或存储设备出了故障，数据仍然可以使用，那样你的应用程序就能继续进行CRUD（创建、读取、更新和删除）操作，不受到任何干扰，这就是所谓的故障切换（Failover）和高可用性（HA）。
要是整个集群都出现了故障，会出现什么状况？可能会发生这种情况：整个地区遭到飓风或停电之类的自然灾难，持续时间之长超过大多数备份计划的预期。有没有制定灾难恢复计划？借助放在不同地区的辅助数据库，你就能不受干扰地继续正常运行。我接触过的一个客户投入运行NoSQL后4年间，在100%的时段都正常运行，而且这个记录继续在保持。
要是开发和IT方面确保良好的规划和管理，又有合适的NoSQL数据库架构和设计，就有可能让数据库一直正常运行。
全面功能：正如另一个客户在评估期间查明的那样，如果整合十几个组件，一套NoSQL解决方案也许就能完成它需要完成的任务，它会履行功能一览表上的每项功能。但是实际上，在重大活动时期（比如购物旺季），NoSQL解决方案的这种本领有多强：既做到能够正常运行，又仍能够实现每秒25000多次交易，支持全球3500多万浏览器通过多种类型的设备访问主网站，以及更新10000多个网页，而不让用户满腹牢骚？
使用一种“集所有功能于一身”的解决方案当然更容易，那样它们可以无缝地协同工作，只需要你投入较少的资源。
性能：数据库处理你需要它处理的任务有多好，又仍拥有合理的性能？对NoSQL来说，有两大类性能需求。
第一类是需要实时的应用，响应时间常常在20毫秒以下，有时低至10毫秒或5毫秒。这种应用可能有更简化的数据和查询要求，但是这通常意味着要有高速缓存或内存中数据库，才能满足这样的速度。
第二类是需要拥有人觉得合理的性能的应用，所以作为信息接收方，我们对于延迟时间不是太注意。这类应用可能需要查看更复杂的数据、查询更大的数据集、执行更复杂的过滤操作。对这类应用而言，性能通常为响应时间在0.1秒或1秒之间。
还有两者的结合体：你有一个无法更换的记录系统（system of record），NoSQL数据库被用作高速缓存，以便加快使用信息的速度。
接口：NoSQL数据库通常有访问信息的编程接口，支持Java以及Java脚本、C、C++以及C#的变种，还支持各种脚本语言，比如Perl、PHP、Python和Ruby。一些包含SQL接口，支持关系型数据库管理系统（RDBMS）用户改用NoSQL解决方案。许多NoSQL数据库还提供REST接口，允许可以更灵活地访问数据库，以及访问数据和功能。
评估应用编程接口（API）有多全面。该API可以扩展吗？它能处理你需要数据库处理的所有任务吗？
安全：安全不仅仅指限制对数据库的访问，还指保护数据库里面的内容。如果你不想让某人看到或更改数据，可是数据库又适应不了这种细粒度级，可以使用应用软件作为保护数据的手段，做到这一点。但是这给你的应用层增添了工作。如果你从事政府、金融或医疗保健行业，这可能是决定某款特定的NoSQL解决方案能否用于敏感项目的一大因素。
你还应该考虑管理用户权限、角色和访问有多容易。数据库能与你可能拥有的轻型目录访问协议（LDAP）或其他单点登录解决方案轻松集成吗？你有哪种细粒度？是在数据库层面、“表”层面，还是在记录层面？
全面管理：生产环境应用程序的一个日常要求就是对数据库进行全面管理。管理和维护服务器和数据库软件有多容易？你需要添加服务器或存储资源时，管理起来多容易？某个节点或磁盘崩溃时，数据库的表现有多好？是否需要联络数据库管理员采取行动，还是数据库架构会轻松处理这种情况，不需要管理员立即干预（假设做好了容量规划）？
数据库可以多轻松地与你的管理系统集成，以便提醒注意任何问题？你所能获得的关于数据库的信息有多精细，它够细化吗？
开源和成本：企业组织在评估所用软件时，开源是绕不过的一大趋势，这有诸多原因。一个原因是，据信开源更稳健，因为每个人都可以查看代码，提供反馈意见，或者为代码库贡献代码，以堵住这些漏洞。但是在2015年2月，一种知名的开源数据库被发现在其广大用户当中有上万台服务器的安全没有保障。倒不是由于代码，而是由于说明文档并没有建议用户对服务器采取适当的保护措施。
另一种普遍的看法是，开源成本比较低，因为许多项目可以用社区版来完成，社区可以回答许多问题，不必花钱签订支持合同。对一些项目来说是这样。必须确信你在评估所有的成本因素，而不仅仅是“免费”软件。如果你要把其他核心功能整合到基本的开源数据库中，就要考虑到你的团队做集成工作或额外的开发工作，以及继续维持这项工作需要花时间。“免费”看起来根本不是完全免费。
一个NoSQL客户之所以由开源解决方案换成商用解决方案，就在于其基于开源的原始配置使用了将近200台服务器。换成商用解决方案让该客户可以使用不到20台服务器，这为他节省了硬件、数据中心以及管理（服务器和数据库管理员）等方面的成本。
很容易沉迷于“无论什么，我们只使用开源”这种做法。如果你能成功地这么做，自然很好！但是如果这意味着你还要把所有部分集成起来、整合到你的业务应用程序中，而不是专注于你的应用程序，这从长远来看可能不是最佳解决方案。
NoSQL能够满足许多类型应用的需要，从小型简单的应用到庞大复杂的应用，以及介于两者之间的应用，统统都能搞定。你要确保在评估解决方案的全面性时做好了摸底工作，避免受到行业炒作的误导。
欣然面对NoSQL带来的变化，抓住大好机会！
云头条编译自：Network World（未经授权谢绝转载）