NOSQL 选择五维度
背景
关系数据库在大多数企业或组织中具有很长的历史，这是有充分理由的。关系数据库是满足当前业务需求的现有应用系统的基础；它们得到了广泛的工具生态的支持；而且有大量的技术从业者有能力实施和维护这些系统。
但是目前企业或组织越来越多地考虑遗留关系数据库架构的替代方法。在某些情况下，这样做的动机是技术上的，例如需要处理新的，多结构的数据类型，这些数据类型不适合关系数据库的表格数据模型，或者数据规模超出现有系统的容量限制；在另一些情况下，企业或组织考虑替换遗留关系数据库的动机是希望找到可行的替代昂贵的专有数据库软件和硬件的替代方案；还有一种情况是敏捷性或开发速度，因为企业或组织希望更快地适应市场并采用敏捷开发方法，DevOps 和微服务。
开发团队在技术选择过程中具有强大的影响力，这个群体中目前的一些趋势是发现关系型表格结构的数据模型越来越不能更好的满足他们应用的需求，例如：
开发人员开发的应用正在创造一些新的，快速变化的数据类型：结构化、半结构化、非结构化、多态的数据，通常这类数据的量比较大；
传统十二到十八个月的瀑布式开发周期的时代已经过去了，现在都是小型的团队，采用敏捷的工作方式，快速迭代，每周或每两周都有新代码的上线，甚至每天有多次上线的可能；
过去应用的受众有限，目前以服务的方式发布，需要一直在线，可以从很多不同的设备访问，在全球范围内进行扩展，并在用户附近分发数据，以实现低延迟体验，并符合一些数据合规性法规；
企业和组织现在正在转向横向扩展架构，使用开源软件，并运行在普通的硬件平台或云计算平台，而不是采用大型单体服务器和存储的基础架构。
与关系数据库相比，许多非表格“NoSQL”数据库具有几个关键特征，包括更灵活的数据模型，更高的可伸缩性和卓越的性能。但是，大多数这些 NoSQL 数据库也舍弃了使关系数据库对过去几代应用程序都非常关键的基础：富查询能力、二级索引和强一致性。实际上，“NoSQL”通常作为所有非表格数据库的总体类别。就像我们将看到的那样，这个术语太过宽泛，定义太松散而无法真正有用。它通常忽略了 NoSQL 数据库在实现灵活性，可伸缩性和性能方面所进行的取舍。
本文我们的目的是帮助您在选择 NOSQL 或非表格数据，这一复杂又快速变化的领域时提供一些建议，我们描述了企业或组织在确定其应用程序和业务的正确选择时应使用的五个关键维度来评估这些数据库。
1. 数据模型
非表格结构的数据库与关系数据库最主要的不同是数据模型。尽管有许多非表格结构的数据库，但它们主要属于以下三类之一：
文档模型
关系数据库将数据存储在行和列中，而文档数据库将数据存储在文档中。这些文档通常使用类似于JSON（JavaScript Object Notation）的结构，这种结构在开发人员中很流行。文档提供了一种直观自然的方式来数据建模与面向对象编程紧密相关 - 每个文档实际上都是一个对象。 文档包含一个或多个字段，其中每个字段都包含一个有数据类型的值，例如字符串，日期，二进制，浮点值或数组。不是将记录分散在与外键连接的多个列和表上，而是将每个记录及其关联（即相关）数据一起存储在单个层次结构文档中。这种模型可以提高开发人员的生产率，简化数据访问，并且在许多情况下，不需要昂贵的 JOIN 操作和复杂的跨表的事务。
在文档数据库中，数据模型是动态的：每个文档可以包含不同的字段。这种灵活性对于建模非结构化和多态数据特别有用。它还使在应用程序的生命周期中演化的过程，例如添加字段，变得更加容易。此外，某些文档数据库提供了开发人员期望的，类似关系数据库中的富查询能力。 特别是，可以基于文档中多个字段的组合来查询数据，其中丰富的二级索引可提供有效的访问路径以支持几乎任何查询模式。
应用： 文档数据库是通用目的的，由于数据模型的灵活性，在任何字段上查询的能力以及文档数据模型与现代编程语言中对象的自然映射，它可用于多种应用。
示例： MongoDB、CouchDB。
图模型
图数据库使用具有节点，边和属性的图结构来表示数据。本质上，数据被建模为特定元素之间的关系网络。虽然图模型可能是不直觉的，并且需要一些时间来理解，它对特定类型的查询很有用。它的主要吸引力在于，它使在应用程序中实体之间的关系建模和遍历更加容易。
应用： 应用的核心是使用图数据库关系遍历功能，例如便利社交网络连接，网络拓扑或供应链。
示例： Neo4j、AWS Neptune。
键值和宽表模型
从数据模型的角度来看，键值存储是非表格数据库的最基本类型。数据库中的每一项都作为属性名称或键及其值存储。但是，该值对系统完全不透明，只能通过键来查询数据。该模型对于表示多态和非结构化数据很有用，因为数据库不会在键/值对之间强制执行设置模式。
宽表列存储或列族存储使用稀疏的，分布式的多维排序的映射来存储数据。每个记录的存储列数可以不同。可以将列分组在一起从列族中进行访问，也可以将列分布在多个列族中。通过每个列族的主键检索数据。
应用： 键值存储和宽表存储对于仅通过单个键值查询数据的应用很有用，可以提供较好的性能和可伸缩性，由于数据访问模式的简单性和数据本身的不透明性，可以对其进行高度优化。
示例： Redis 和 AWS DynamoDB（键值）、HBase 和 Cassandra（宽列）
总结：
所有这些数据模型都提供了模式灵活性。
键值和宽表数据模型在系统中是不透明的-只能通过主键查询。
文档数据模型具有最广泛的适用性。
由于直接与面向对象语言中的对象映射，文档数据模型直观自然，且高效。
宽表模型提供了比键值模型更细粒度的数据访问能力，但对比文档数据模型，少了灵活性。
2. 查询模型
每个应用程序都有其自己的查询要求。 在某些情况下，可以使用非常基本的查询模型，其中应用程序仅基于主键访问记录。 但是，对于大多数应用程序而言，具有能够基于每条记录中的几个不同值进行查询的能力很重要。例如，存储有关客户的数据的应用程序可能不仅需要查找特定的客户，还需要查找特定的公司或特定大小的客户，或者按邮政编码或州来查找客户销售价值的集合。
应用程序更新记录（更新一条字段，或多条字段）是很常见的，为了满足这些要求，数据库需要能够基于二级索引查询数据。 在这些情况下，文档数据库通常是最合适的解决方案。
文档数据库
文档数据库通常提供查询和更新文档中任何字段的能力，尽管这个域中的产品功能有所不同。某些产品（例如MongoDB）提供了丰富的索引选项集，可以优化各种查询，包括文本，地理空间，复合，稀疏，TTL，唯一索引等。此外，其中一些产品提供了就地分析数据的能力，而无需将其复制到专用的分析或搜索引擎。例如，MongoDB 为开发人员提供了聚合框架，以创建复杂的处理管道以进行数据分析和转换，直至进行分阶段流水线匹配，级联，地理空间处理和图形遍历。它还通过 MongoDB 图表提供本机可视化功能，以及用于Apache Spark 和 BI 工具的连接器。为了更新数据，MongoDB 提供了丰富的更新方法，使开发人员可以在单个事务更新操作中针对文档的匹配元素（包括嵌套在嵌套数组中的元素）执行复杂的操作。
图数据库
这些系统倾向于提供丰富的查询模型，在其中可以查询简单和复杂的关系以对系统中的数据进行直接和间接推断。在这些系统中，关系类型分析往往非常有效，而其他类型的分析则可能不太理想。结果，图数据库很少用于更通用的操作应用程序，而是与常规文档数据库或关系数据库结合使用，以实现图特定的数据结构和查询。
为了尝试使用多种存储技术所带来的复杂性，业界正朝着“多模型”数据库的概念迈进。此类设计基于在单个数据平台提供多个数据模型和查询类型的支持。从而满足各种应用需求。例如，MongoDB 提供了$graphLookup 聚合阶段，用于数据库内部的图形处理。 $graphLookup 支持跨图，树和层次结构数据的有效遍历，以发现模式并显示以前未标识的连接关系。
键值和宽表数据库
这些系统提供了仅基于单个或有限范围的键来查询和更新数据的能力。为了查询其他值，建议用户建立并维护自己的索引。某些产品对二级索引提供的支持有限，但有一些限制。要在这些系统中执行更新，可能需要多次操作：首先找到记录，然后更新它，然后更新索引。这些系统中，这种更新相当于在客户端实现对整个记录的完全重写，而不管单个属性或单个记录是否已更改。
总结：
非表格数据库之间的最大区别在于有效查询数据的能力。
文档数据库提供最丰富的查询功能，从而使它们能够处理各种操作型和实时分析应用程序。
键值存储和宽表存储提供了一种通过主键访问数据的单一方法。 这可能很快，但是它们提供的查询功能非常有限，并且可能增加额外的开发成本和应用程序级要求，以支持除基本查询模式以外的任何内容。
3. 一致性和事务模型
大多数非表格系统通常出于可用性和可伸缩性的目的而维护数据的多个副本。这些数据库可以对跨副本的数据一致性施加不同的保证。非表格数据库往往被归纳为两类：强一致性和最终一致性。
在强一致性的系统中，应用程序的写入将在后续查询中立即可见。如果最终保持一致，则写入不会立即可见，这主要是因为查询提供服务的数据副本。例如，当在产品目录中反映产品的库存水平时，在系统一致的情况下，当应用程序更新库存水平时，每个查询都将看到当前库存，而在最终一致的系统中，库存水平对于在给定时间进行查询，但最终会变得准确，因为最终“最终”跨数据库集群中的所有节点复制了数据。因此，对于最终一致的系统，应用程序中的代码会有很大不同，例如，不是通过获取当前库存并减去一个库存来更新库存，而是鼓励开发人员发出明确设置库存级别的幂等查询。开发人员还需要在其应用程序中构建其他控制逻辑，以处理可能过时或已删除的数据。
大多数非表格系统都在单个记录的级别上提供原子性保证。由于这些数据库可以将相关数据聚集在一起，而这些数据本来可以以文档模式表示在表结构下父子表之间的模式，因此单记录原子性提供了满足大多数应用程序的数据完整性需求的事务语义。但是，一些开发人员和DBA已经接受了有 40 年历史的的关系数据建模的约束，他们假定多记录事务对于任何数据库都是必需的，而与它们所基于的数据模型无关。有些人担心，尽管当今的应用程序并不需要多文档交易，但将来可能会。对于某些工作负载，需要支持跨多个记录的ACID事务。
出于这些原因，MongoDB 添加了对多文档 ACID 事务的支持。这使开发人员更轻松地使用 MongoDB 解决全部问题，他们感觉就像开发人员熟悉关系数据库中的事务一样，多语句，相似的语法并且易于添加到任何应用程序中。通过快照隔离，事务可提供一致的数据视图并强制执行全部或全部放弃。 MongoDB 在提供类似传统关系数据库的事务保证方面是与其他非表哥数据库最大的一个不同，同时具有非表格数据库的灵活性和可扩展性。
强一致性系统
应用程序可能对数据一致性有不同的要求。 对于许多应用程序，必须始终保持数据强一致性。由于开发团队已经在关系数据库一致性的模型下工作了数十年，因此这种方法更加自然和熟悉。在其他情况下，最终的一致性是在系统可用性方面具有的灵活性，是可以接受的折衷方案。
文档数据库和图数据库可以是强一致的，也可以是最终一致的。MongoDB 提供可调整的一致性。默认情况下，数据是强一致的，所有写入和读取都访问主节点的数据主副本。作为选择，可以对从节点副本发出读取查询，如果写操作尚未与从节点副本同步，则数据最终可能会保持一致。一致性选择是在查询级别进行的。
最终一致性系统
对于最终一致的系统，在一段时间内主从节点之间数据副本是不同步的。这对于不经常更改的只读应用程序和数据存储（例如历史档案）是可以接受的。同样对于写密集型用例，数据库正在捕获诸如日志之类的信息，也只会在以后的某个时间点读取，这也很合适。键值和宽表存储通常是最终是一致的。
最终一致的系统必须能够接收在单个记录更新中冲突问题，因为写操作可以应用于数据的任何副本，所以当在不同节点上更新同一属性时，写操作彼此冲突的可能性很高，一些系统使用矢量时钟来确定更新事件的顺序，并确保在发生冲突的情况下最新操作获胜。但是较久的值可能已经被提交回应用程序。其他系统保留所有冲突的值，并将解决冲突的责任推给用户。由于这些原因，插入操作在最终一致的系统中表现良好，但是更新和删除可能涉及折衷，这使应用程序显著复杂化。
总结：
大多数应用程序和开发团队期望强一致性系统。
不同的一致性模型在一致性和可用性方面为应用程序带来了不同的权衡。
MongoDB 提供可调整在查询级别定义一致性的能力。
最终一致的系统以使读取，更新和删除变得更加复杂的代价为插入提供了一些优势，同时通过读取修复和压缩而产生了性能开销。
大多数非表格数据库提供单个记录的原子性。对于大多数应用程序来说这已经足够了，但对所有应用程序来说还不够。MongoDB 提供了多文档 ACID 事务保证，从而使用单个数据平台解决完整范围的用例更加容易。
4. APIs
目前还没有非表格系统的统一接口标准，每个系统为应用程序开发团队提供不同的设计和功能。API 的成熟度可能会对开发和维护应用程序和数据库所需的时间和成本产生重大影响。
驱动
编程语言的种类繁多，每种语言都提供了处理数据和服务的不同规范。驱动程序是被开发者创建，开发团队是给定语言的专家，并且了解程序员如何在该语言中工作。这种方法还可以受益于其利用编程语言中的特定功能的能力，这些功能会提高访问和处理数据的效率。
对于程序员来说，驱动程序更易于学习和使用，它们减少了团队开始使用基础数据库的入门时间。例如，驱动程序提供直接接口来更新或获取文档或文档中的字段。MongoDB 支持十多种语言的驱动：Java，.NET，Ruby，Node.js，Perl，Python，PHP，C，C ++，C＃，Javascript 和 Scala。社区还支持数十种其他驱动程序。
RESTful APIs
一些系统提供 RESTful 接口。这种方式具有简单和被开发者熟悉的吸引力，但是它依赖于 HTTP 自身特点相关的固有延迟。构建这些借口也给开发人员带来了额外的负担，并且这些接口可能与其余的编程接口不一致。
类似 SQL 的 APIs
一些非关系型数据库已经尝试向数据库中添加类似于 SQL 的访问层，希望通过这种功能减少那些已经掌握 SQ L的开发人员和 DBA 的学习难度。在开始重要开发工作之前，评估这些实现也很重要，请考虑以下因素：
与 SQL 的强大功能和可表达性相比，这些实现的类 SQL 的 API 在大多数情况下都远远不够，并要求 SQL 用户学习该语言功能受限的方言
基于 SQL 的 BI，报表和 ETL 工具将与自定义 SQL 实现不兼容。
尽管 SQL 开发人员可能熟悉某些语法，但数据建模则完全不同。试图在任何非表格数据库上施加关系模型将对性能和应用程序维护造成灾难性的后果。
可视化和报表
许多公司使用基于 SQL 的 BI 平台进行数据可视化，分析和报告，而这些平台本身并未与非表格技术集成。为了解决这一问题，企业或组织转向使用 OBDC 驱动程序，该驱动程序在其非表格数据库和第三方分析工具之间提供了行业标准的连接。例如，用于 BI 的 MongoDB 连接器允许分析师，数据科学家和业务分析师使用最受欢迎的 BI 工具无缝地可视化 MongoDB 中管理的半结构化和非结构化数据，以及来自其 SQL 数据库的传统数据。
MongoDB Charts 使用户可以快速，轻松地实时创建和共享可视化其 MongoDB 中的数据，而无需将数据移至其他系统或利用第三方工具。由于 Charts 本身了解 MongoDB 文档模型，因此用户可以根据形状不同或包含嵌套文档和数组的数据创建图表，而无需先将数据映射到平面表格结构中。
总结：
在非关系型数据库产品中，API 的成熟度和功能差异很大。
MongoDB 的驱动程序可最大程度地缩短新开发人员的上手时间，并简化应用程序开发。
并非所有的 SQL 都具有同等功能。仔细评估非关系数据库提供的类似 SQL 的 API，以确保它们可以满足您的应用程序和开发人员的需求
5. 商业支持、社区实力、及避免厂商绑定
选择数据库是一项重大投资。 一旦选定某数据库，并在它上构建了应用程序，将其迁移到其他数据库将是昂贵，且是具有挑战性和风险的。公司通常会投资少量的核心技术，他们可以开发中培养专家，积累技能，并可在许多项目中使用，集成和最佳实践。非表格数据库系统仍然相对较新，尽管市场上有很多选择，但少数技术和供应商是否将经受住时间的考验还有待观察。
商业支持
一个企业或组织在评估数据库时应考虑公司或项目的运行状况。重要的是，不仅产品要继续存在，而且要不断发展并提供新功能。 拥有一个强大的，经验丰富的支持组织，兵能够在全球范围内提供服务是另一个相关的考虑因素。
社区实力
特别对一个数据库而言，围绕着技术有一个强大的社区显得尤为重要。具有强大社区用户的数据库使查找和雇用熟悉该产品的开发人员更加容易。它使查找最佳实践，文档和代码示例变得更加容易，所有这些都降低了新项目中的风险。它还可以帮助组织保留关键技术人才。 最后，一个强大的社区鼓励其他技术供应商开发集成并参与生态建设。
避免厂商绑定
过去，许多企业或组织一直受困于被一些传统企业软件供应商的数据库锁定。开放软件和普通硬件的使用为许多企业或组织提供了逃脱途径，但他们还担心，当他们迁移到云中时，最终可能会以一种形式的锁定换成另一种形式。
对任何新软件的投资，认真评估其许可证，和可用性很重要。 另外可自由的运行在任何地方也很重要，从开发人员所使用的便携式计算机，到投入生产时可在自己的基础架构上运行，并且按需可以灵活地从任何公共云中将数据库作为服务使用。MongoDB 使开发人员和 DevOps 团队可以在自己熟悉的基础架构上自由下载和运行数据库。借助 MongoDB Atlas，它还可以作为完全托管的云服务在所有领先的云提供商之上。无论选择在何处运行 MongoDB，您都可以享受完整的平台可移植性，您使用的是相同的代码库，API 和管理工具。
总结：
社区规模和商业实力是评估非关系数据库的重要组成部分。
MongoDB是成为上市公司的极少数非关系数据库提供商之一；它拥有最大，最活跃的社区；支持团队遍布全球，可提供 7x24 的全天候服务；使用者集中在大多数主要城市；提供大量的文档。
MongoDB 可在您自己的基础架构上运行，也可以在所有领先的公有云平台上作为完全托管的云服务运行。
为什么 MongoDB
MongoDB 旨在帮助开发人员及其所构建的应用，充分发挥软件和数据的力量：
最佳的数据处理方式
简单 - JSON 格式简单，以自然、直观的方式处理数据
高效 - 无需大量的工作，即可获得出色的性能表现
灵活 - 数据模型可灵活更改，迅速应对应对业务变化
强大 - 功能强大，支持各种类型的数据和查询
智能的将数据放在您想要的位置
高可用 - 数据需要天然高可用，业务无中断
可扩展 - 通过原生分片水平扩展
负载隔离 - 事务性操作和分析型操作在用一个数据平台下同时进行，负载隔离
本地读取 - 本地读取，更好的用户体验，增加客户粘性
可自由的运行在任意地方
可移植性 - 在任何地方都可以运行的数据库
无云厂商绑定 - 利用多云策略的优势而无无云厂商绑定
全球覆盖 - 在全球主要公有云厂商的 60 多个地区提供服务
更多信息参照MongoDB 架构概览。
结论
随着技术的发展，企业或组织越来越发现需要评估新数据库以支持不断变化的应用程序和业务需求。围绕非表格结构的数据库，媒体上有各种炒作，以及市场上缺乏相应的清晰度，使得企业或组织的了解可用的解决方案之间的差异非常重要。 如本文所述，评估这些技术时要考虑的关键标准是数据模型，查询模型，一致性和事务处理模型，API，商业支持和社区实力。许多组织发现文档数据库如 MongoDB 最适合满足这些标准，尽管我们鼓励技术决策者自己评估这些考虑因素。