虚拟专家小组会：NoSQL 数据库的现状

要点：

• 通过被企业所采用的情况了解 NoSQL 数据库的现状；
• 理解当在基于 NoSQL 的应用上工作时改进开发人员生产力的有关工具；
• 理解多模型数据库的概念，以及多模型数据库与混合持久化方法的相对优劣之处；
• 如何结合使用 NoSQL 数据库和大数据技术（例如 Hadoop 和 Spark）解决大数据的问题；
• 学习如何将 NoSQL 数据库与微服务、Docker 等容器技术等其它新兴趋势相集成。

NoSQL 数据库现已存在多年了。在对半结构化和非结构化数据的管理中，NoSQL 已经成为数据存储的优先选择。

这些数据库在线性可扩展性、数据读写性能等方面具有很多优势。

随着由物联网（IoT）设备和传感器所产生的时序数据的大量涌现，重新审视 NoSQL 数据库的现状是很重要的。这样可以了解到当前正发生着什么，以及将来这些数据库中会出现什么技术。

为得到对 NoSQL 数据库现状的不同观点，InfoQ 访谈了四位来自不同的 NoSQL 数据库企业的专家，组织成一个虚拟专家小组会。

这四位专家小组会的参与者分布是：

• Seema Jethani 女士：新近担任了 Basho 科技公司产品管理部门的主管；
• Perry Krug 先生： Couchbase 公司的主要解决方案架构师及客户利益代言人；
• Jim Webber 博士： Neo 科技公司的首席科学家；
• Tim Berglund 先生： DataStax 公司的培训主管。【备注：以下的观点仅代表 Tim 先生本人而非其雇主。任何关于未来的推测仅是 Tim 先生的虚构，当然是某种有根据的虚构，但这些并不能反映任一其曾供职的公司的未来规划。】

InfoQ：NoSQL 数据库已经存在十多年了。从被工业界所采纳情况看，NoSQL 数据库的现状如何？

Seema Jethani：现在近乎达到了在每种产业中都有一些 NoSQL 数据库的部署的状况。NoSQL 数据库的第一波部署是由 Web 规模的应用以及社会媒体和移动 App 所驱动的，而物联网将驱动下一波的大规模部署。

Perry Krug：通常我们认为 NoSQL 的采用过程经历三个扩展阶段。我将第一阶段归结于草根和开发人员的应用。通常一个组织仅是去开展试点运行，亦或在非关键业务的应用中部署 NoSQL，而这些应用是完全处于生产系统之外的。第二阶段的标志是 NoSQL 被更广泛地采用。在第二阶段中，NoSQL 虽然已经在关键业务或关键商业应用中发挥了日益重要的作用，但是仍然未成为组织投资组合中的标准部分。第三阶段意味着 NoSQL 进入了组织的策略提案中，并为使 NoSQL 成为组织内的标准，在组织的内部已广泛地开展了“重新架构”工作。在不同的组织中，第三阶段可能是仅由 NoSQL 所实现，或者仅仅使用那些已被充分了解的实现方法，即权衡使用 NoSQL 和 RDBMS。

我们的产业观是一个组织应以自己的节奏通过这三个阶段。当前，Google、Facebook、PayPal、LinkedIn 等企业显然是已处于第三阶段多年了。而其它的一些企业（在这里就不提及企业名称了）依然在第一和第二阶段中推进。

总而言之，我们并不否认 RDBMS 依然占据着大部分的市场份额，但是它们市场份额的增长要明显慢于 NoSQL 数据库的。这种比率变化部分是由两者间的相对规模所驱动，但也取决于这样一个事实，那就是对 NoSQL 的需求正在以更快的速度增长。

Jim Webber：宽泛地讲，我认为 NoSQL 数据库已经从一种被先期使用者和 Web 巨头所使用的奇特技术这样的地位，转变为至少是被早期大多数人所完全接受的一类技术。此外，在反映了受关注度的数据库引擎排序榜中，已有不少 NoSQL 数据库（各种类型的）位列前二十位。非正式地讲，感觉上 NoSQL 在开发者和 OSS 社区已经是人所尽知了，并且像大数据这样的 NoSQL 相关应用在某种程度上已经得到商业社区的理解。

Tim Berglund：至少在五年前，NoSQL 技术就是十分酷的。完全可以就 NoSQL 技术去单独召开一个研讨会；在那时，我曾做过一个被广为流传的演讲，题目是“NoSQL 的对决”。报告中对比了一些已被广泛采用的产品。因为涉及到 NoSQL 这个流行词，演讲的当时房间都被坐满了。

时至今日，开发人员事实上仍然对采用 NoSQL 技术兴趣十足，但是 NoSQL 的应用案例已司空见惯。供职于金融、零售业、医院等看似普通的企业中的开发人员，正在使用非关系型数据库构建真实的应用系统。企业 IT 选型 NoSQL，不再需要是特别激进的决策制定者才会这样做。NoSQL 的发展目标是成为一类成熟实现的产品，并能完全平等地与关系数据库在技术选择上开展竞争。虽然距离这样的目标依然还有很长的路要走，但是至少对我而言，这种发展趋势已是十分明显了。

InfoQ：在使用 NoSQL 数据库进行数据建模的项目中，有哪些最佳实践？

Seema Jethani：

• 对所有事物的反范式化：通过使用反范式化技术，可对在同一地点的查询所需的所有数据进行分组。这加快了查询的速度；
• 确定性的物化键值：将键值组合为复合键值，进而使用该键值确定性地获取数据，这种做法可避免对数据的搜索；
• 应用端的连接运算：考虑到并非所有的 NoSQL 解决方案都支持连接运算，这需要在设计时实现对连接运算的处理。

Perry Krug：驱动 NoSQL 数据库被采用的一个更为重要的因素是 NoSQL 在数据建模和管理上的灵活性（另外一个因素是对性能、规模、可用性等方面上的操作能力的需求）。当讨论数据建模时，首要的“最佳实践”就是能够更紧密地对齐应用对象与数据库间的数据模型或结构。这里 ORM 层理念正迅速削弱，因为该理念的建立涉及了应用对象的获取、将这些对象切分为僵化的行和表并将这些行和表连接在一起等过程。

Jim Webber：考虑到 NoSQL 这个头衔下所涵盖的数据模型范围，这是个相当宽泛的问题！在一些数据模型中，为使得这样的模型运行，关键是领会如何将数据反范式化为键值、列或者是包含一些必要用户层面技巧的文档。然后需认真考虑如何通过索引之类的技术去支持新的模型。在图领域，这也是我的专业领域，建模是一个相当困难的事情，但是考虑到数据模型（节点、关系和标签）和处理模型（图遍历）的独特之处，总体而言这还算是一个相对愉快的过程。

在 Neo4j 这样的原生图数据库中，数据库引擎原生支持连接运算。这种连接运算并非我们通常在关系数据库中所使用的那种集合连接运算，而是根据两条相关记录间的关联关系所实现的记录间的高性能协调。鉴于这种连接运算所具有的性能（甚至于在我的笔记本上都可实现每秒数百万次的连接运算），我们可以快速地遍历大规模的图。在 Neo4j 中，这样的连接运算实现为使用低代价的指向追踪去遍历图中节点间关联关系。这是原生图数据库的一个特性，被称为“无索引近邻”，它可用 O(n) 的代价去访问 n 个图元素。与之对比的是，在非原生图数据库技术下这需要至少 O(nlogn) 的代价。

这样，大规模关联数据结构的低代价且快速的遍历能力真实地驱动了数据建模。给定一个由白板上的环和线所组成的典型领域模型，我们发现该模型通常与数据库中的数据模型相同，即白板所设计的就是需要去存储的。进一步，鉴于我们扩展了对数据所意图咨询的问题，导致了建模中添加了更多的关系、数据层、扩展子图、精确命名和属性。我们把这样的过程看做是查询驱动建模方法（如愿意也可称为 QDD）。这意味着数据模型是对领域专家而非仅是对数据库专家开放的，并且也支持建模和演化过程中的高质量协作。图建模赋予我们以这样的自由，即绘制出你所要存储的模型及一小组可提供的功能，这样的功能用于确认你非常地了解如何与底层栈一起和谐地工作。

Tim Berglund：如果将讨论限定于我认为传统上是“重量级”的产品，即 Cassandra 、 MongoDB 和 Neo4j，我们可以看出此问题的答案不止一个。上面提及的每个数据库彼此都是非常不同的，就像它们与关系数据库之间的差异一样。因此事实上这里并没有统一的 NoSQL 数据建模方法；相反，我们必须使用这些数据库自身提供的方式去访问它们，了解适合它们的数据建模技术。

在当前，我的工作专注于 Cassandra 教育资源的建立。例如一些用 Cassandra 存储时序数据这样应用，它们对于一些特定的数据模型工作良好，并可作为罐装解决方案进行学习。使用关系数据库进行商业领域建模对于大多数开发人员而言是直观的方法，但是更通用的商业领域建模则需要特定的方法，不同于公认的传统关系数据库方法的方法。过去我们曾一度将关系数据建模作为一种新奇事务，而那时我们必须去学会如何做好这件事情。这对于 NoSQL 数据库而言也是同样的事情。必须有人可让我们坐下来并向我们阐述 NoSQL 的工作原理，及使用 NoSQL 所揭示的数据模型去表示真实世界的方法的优越性所在。

InfoQ：当在数据建模需求上要求特定的 NoSQL 数据库（例如文档数据库），但是在性能需求上则要求另一完全不同类型的数据库（例如键值数据库）时，面对这种冲突，开发人员应该如何做出选择？

Seema Jethani：开发人员应总是选择性能。数据模型是可以改变以适合用例的需求的。诚然这样做可能需要在应用中做额外的工作，但性能是不可能凭空获取。开发人员应总是为取得更好的性能而努力。

Perry Krug：在我看来，对于这类决策问题，这里所提供的文档数据库和键值数据库这两个选项是非常相似的。更好的例子是将键值数据库或文档数据库与图数据库、列数据库相对比……

这无疑是当前开发人员和架构师所面对的一个主要挑战。一些厂商正在提供多模产品，亦或对数据库中某种类型的特性和功能进行扩展，这仅是为了让愈来愈多的用例能被数据库所处理。从某种意义上讲，这些不同类型的数据库技术正在性能和“适合度”上日渐趋同。另一方面讲，这些不同类型的技术间的差异是来源于这样的一个理念，即 NoSQL 并非是另一种采用了“用大锤猛敲每个钉子”这种 RDMBS 处理方式的技术。它是一个双刃剑：一方面，它增加了选择范围和复杂性；另一方面，它提供了根据任务选取正确工具的能力。

在不远的将来，我们期待看到这些技术类型间越来越多的合并，这样用户不必再从这么宽泛的不同选择范围中做出选择，并可依然对他们各自的系统进行优化以适合不同应用的需求（无需做到面面俱到）。

Jim Webber：近来我对此问题思考很多，因为在非原生图数据库上已经出现了各种各样的图功能库。我认为重要的是，认识到你的数据库应该对什么样的应用是原生的，而对哪些应用应该是非原生的。例如，Neo4j 对于图是原生的，就此而优化了图遍历运算（通过指针追踪实现的低代价连接运算）及针对写操作的 ACID 事务。考虑到关联文档可受益于图模型技术，在 Neo4j 之上再构建一个（关联）文档库层是可行的。这两种技术类型结合得很好，正如 Structr 这样的系统所展示的。

但反过来却并非正确。这么说吧，如果你有一个不支持连接运算的文档或列数据库，那么将关系嫁接到这样的系统上（或者是在应用中通过封装图操作库实现）是一种背道而驰的做法。Neo4j 的高性能连接运算是通过底层指针追踪而原生实现的，这种运算必须在应用层或函数库层实现。就非原生方法的效率和遍历性能而言，通过网络检索文档、检查文档内容、解析另外一个地址、通过该地址检索文档并如此类推，这一系列操作极大地限制了其实用性。

这里需指出 Neo4j 也并非是全能的，例如它就不是一种原生的时序数据库。如果想要在 Neo4j 中实现时序操作，应在你的模型中编码时间树结构（一种看上去像是 B+ 树的索引模式），并指明查询是依赖于这种树结构的。在原生的时序数据库中，上述工作将由数据库自动完成。唯一可选择 Neo4j 作为非原生时序数据库的场景，是当需要去混合管理时间点数据（例如，事务历史、地理空间等）及伴生于时间点数据的其它数据（图）时。在这种场景中，虽然图数据库对任何一个维度的应用而言都并非是原生支持的，但是这是为达到平衡所需付出的小费。

Tim Berglund：通常性能需求是必然胜出的。如果能发挥底层数据库的最优性能，那么不满足延迟性能 SLA 的项目也可转变为成功的项目。例如，Cassandra 数据模型可被转变成支持像文档数据库那样的存储和访问模式，如果你必须要这么做的话。这个例子并非说能最优表示为文档数据库的系统是不存在，而是说任何现实世界的形态都可最终被关系表型数据模型所表示，即使对个别实例来说这样的表示很粗糙。但是性能的改变不具有这样的灵活性。

InfoQ：大家能探讨一下在从事 NoSQL 应用开发时，有助于提高开发人员生产力的工具吗？

Seema Jethani：这里需指出影响开发人员生产力的两个关键因素：易用性，以及易于开发人员用数据库去实现强大功能的特性。易用性可通过提供立即可用的、按类别聚合在一起的工具实现，这些工具节省了开发人员在产品认知引导过程中的宝贵时间。还有很多丰富的特性，例如支持更高层的语言以及由各种语言编写的用户库，可使开发人员无需在应用中做很多繁重的开发就能执行复杂的查询。最终，追踪和调试将使开发人员可快速地识别导致问题的根本原因所在，并将开发人员从耗费时间的调试工作中解放出来。

Perry Krug：该领域无疑是当前所缺乏的，也是快速增长的。从部署和供应的角度看，各种技术间已相当好地实现了标准化，并且通用的工具链之中已集成了这种标准化。但是在大多数情况下，每种技术仅提供了一套筒仓式的工具给它们自身的开发人员。我认为今后几年内值得密切关注的事情，将会是不同的技术间某种程度上的语言或者 API 的标准化。但是这样的事情什么时候会发生，或者是根本不会发生，这在当前还有很大的未知性。

总而言之，现在已出现了很多的新语言（例如 node.js，Go 等）。这些语言正在改变应用的设计、开发和部署方式。

当前那些我们所见到的并非常有用的工具都提供了可参考的架构或实现，即这些工具提供可供拷贝 - 粘贴的例子，并根据这些例子去构建程序。此外还包括培训，提供了动手实践式的工作室，并有机会与各技术方面专家的进行交流。

Jim Webber：我清楚相比于 NoSQL 数据库，在与开发者工具的集成方面关系数据库是更加成熟的，但这个问题会随着时间而发生改变的。当前随着 NoSQL 市场的打开，数据库和工具厂商开始围绕着它们中一小部分得到了狂热的 OSS 社区所支持的领跑者进行整合，该问题正在迅速地发生改变。

就 Neo4j 而言，我们通过近五年的努力推出了一种非常高效的查询语言，命名为 Cypher。Cypher 语言针对图数据提供了便利的、人性化的访问方法。但距离成为“openCypher”这种标准化语言而言，该语言依然处于初级阶段。Cypher 将在一段时间以后以 API 的形式，提供给其它的图处理技术使用（例如，有倡议提出将 Cypher 移植到 Spark 平台上）。

在我们最新推出的 Neo4j 3.0 版本中，我们努力实现了用已为人熟知的方法去访问数据库。我们提供了一种二进制 RPC 协议，该协议已被多种热门语言（C#、Java、Python、PHP、JavaScript）的惯用驱动所使用，感觉上就像 RDBMS 所使用的驱动一样。

该网络栈可调用任何 JVM 语言所编写的服务器端过程。一开始，虽然最初存储过程因为常常用于处理一些细枝末节的问题而被判了死刑，它也成了这段伤心史有意思的注脚，但结果却是令人惊奇的。Neo4j 过程仅是代码。被部署前可在 IDE（甚至是 TDD）中进行严格地测试。更奇妙的是，虽然我们原打算将过程用于迭代图算法中，现在过程已用于从其它的系统（包括非图数据库、Web 服务甚至是电子表格中）中获取数据、并将这些数据混合到操作本地图数据的同一 Cypher 查询中。这种做法让生产力得到了惊人的提高。

在此之上，我们和其它的图领域厂商正致力于实现图的可视化，以使即使是非专家人士也可与模型进行交互。我们近期已经看到这样功能的实现，例如，“巴拿马文件”的披露就是使用了 Neo4j 实现图查询、Linkurious 实现可视化这样的技术组合。对开发人员而言，在面对复杂互联的数据集时，图可视化工具变得日益重要。

Tim Berglund：这取决于你使用工具的偏好，NoSQL 要么看上去就就像是工具作业的荒地，要么看上去一切情况还好。如果你只是想要一个简单的可视化数据模型探测工具和命令行查询能力的话，那么如今这些就足够用了，并且任何主流的数据库都可以提供这些功能。在所有主流的（以及一部分小众的）数据集成工具中，都提供对其中不少数据库的连接器。

但是如果你需要的是支持双向可视化建模之类功能的工具，现在仍会令你失望的。我期望在未来的五年内，对于那些适合的数据库产品，这些工具间的鸿沟将会逐渐弥合。

InfoQ：大家如何看待多模型数据库？对比于混合持久化，多模型数据库选项的优缺点各是什么？

Seema Jethani：混合持久化提倡根据每个应用或程序组件对数据的不同使用方式，应用多个数据库去存储数据，也就是说是对适当的用例选取恰当的数据库。但是这种方法对运营和所需掌握的技能提出了挑战。与之形成对比的是，多模型数据库在设计上就是用于支持多个数据模型，而非单一集成的后台系统。相比于混合持久化而言，这样的数据库设计提供了更好的数据建模方法，避免了操作迥异数据库的复杂度，也避免了相对于单一数据库而言需要精通多种数据库操作技能的问题。

Perry Krug： 我认为在上面的回答中我已经涉及到了该问题的一小部分。混合持久化是一个位于“这正是适合工作的工具！”和“这里有太多的工具了！”之间的滑动杆。传统的 NoSQL 用户通常首选混合持久化，因为每种独立的技术只在一小部分用例上具有优势，而一个大范围适用的应用对多种技术具有需求。NoSQL 的新接触者通常首选的是更小的一组技术，并期待对于那些应用范围更广的用例，其中的每一种技术都是适用的。

我个人倒是担心多模型数据库的结果会是，其中的各模型会在各自的特性集上产生冲突，这样反而是做不好任何事情。我已经看到多模型数据库在相对较小规模的（一到三种）一组技术上取得了好结果，而这一小组技术足以处理一个组织的所有或者大多数的需要。对非常专业技术的需求总是存在的，这并非只对数据库是这样的。

Jim Webber： 在这样一个占据支配地位的系统是由服务（微服务）所组成的世界中，我认为开发人员应为他们的服务选择一个或多个适合的数据库，并通过组合这些服务组实现交付功能。正因如此，我认为混合持久化是非常可信的。

我还认为陪审模式在多模型中已经过时了。捎带一句，任何让单一数据库去满足所有需求的做法都是令人难以容忍的。我们在 RDBMS 的时代就看到了这一点，那时我们将所有事情都硬塞到关系数据模型中。正是这样的经验教训催生了 NoSQL！

但正如我前面所提到的，我所考虑的是这样的一种理念：即数据库对一些事情是原生支持的，而对其它事情是非原生支持的，并且原生模型是否能被和谐地组织到非原生的数据模型中。由于图模型在建模中所表现出的丰富内涵，使得它成为很好地符合以上理念的原生模型。通过收缩图模型去承载其它的模型看上去是可行的（如果你选择这样去做的话）。

Tim Berglund：没有人能说服我去将混合持久化作为一种架构策略。可能在一些由部分遗留系统集成而组成的特定系统中，混合持久化方法表现良好，但对于全新投资的项目而言，它却可能是反模式的。我持反对意见的原因，部分是运营上的考虑，部分是取决于设计上的考虑。从运营角度讲，相对于管理单一系统而言，对软件架构中多个复杂部分的正常运行时间和性能 SLA 的管理是更加困难的事情。就代码本身而言，在一个项目中尽可能地兼顾多个数据模型也一件困难的事情。要使混合持久化成为合理的选择，该模型所给出的价值必须超越上述两个方面上存在的代价。但我认为这种情况是很少见的。

这也意味着，这种与众不同的模型确实有真实的用例。架构师可能愿意将一部分的系统建模为图，而在另一部分系统上做即席查询，并用可被简单建模的那部分系统去满足极其严格的性能 SLA。但多模型数据库对于这类问题也是一个好的解决方案，因为将所有模型置入同一数据库的方法可解决上述运营上的挑战，并且通过借助不同模型的接口实现对可能多的“API 表面积”（API surface area）的共享，使得多模型技术具有简化 API 问题的潜力。我认为未来的趋势是，所有主要的 NoSQL 数据库为其它数据库的原生模型共享可能多的特性。该领域下一个十年将带来什么变化，我翘首以盼！

InfoQ：Gartner 提出引领行业的数据库厂商将在同一平台中提供多种的关系和 NoSQL 数据模型。大家对该预估是怎么考虑的？

Seema Jethani：当前一些由行业领先的数据库厂商所提供的 NoSQL 产品，它们的市场牵引力依然很小，距离实现在同一平台上提供多模型的 RDBMS 和 NoSQL 这个目标，依然还有很长的路要走。即使这些厂商这样做了，其产品的吸引力依然受限于一些功能和性能上的权衡考虑。现在随着 RDBMS 的发展，我们看到世界正向多模型 NoSQL 发展。

Perry Krug：如果依据 Oracle 和 IBM 等厂商愿意提供这样产品的现实而言，我认为这个预估可能是对的；而如果根据什么才是市场所真正所需要的或缺乏的产品而言，我认为这个预估是错的。关系和 NoSQL 数据库间在设计和架构有着本质上的差异，但这两者间肯定存在者某种程度上的重合。简单的物理学定律（更不用说 CAP）指出在关系和 NoSQL 的纯理论上的需求上，不能将两者之间与事务、复制、分布等相关的功能混为一谈。最终厂商可能会提供多种选择，但是我确信这些厂商必将是提供完全不同的产品去处理每种选择。

Jim Webber： 就这一点而言，毋庸置疑看上去 Gartner 是这个预估的主要支持者。在我看到一些数据库开始提供多模型特性时，我对此理念还是完全没有印象的。正如我曾讲过的，我们曾在关系数据库上尝试了“符合所有人的需求”的方法。但实际上是又回到了这样的一个问题，就是你的数据库究竟对什么模型是原生的？如果对图是原生的，你能为你的数据给出一个合理的文档视图。相对而言，如果对列是原生的，那么如果你的底层引擎不能处理连接运算，模型难以实现达到原生图的性能交付。

对于多模型与混合持久化的对比，我怀疑两者间的断层是由 CIO 和软件交付的不同责任所导致。作为企业的 CIO，我想去合理化企业运行所需具有的数据库数量。然而作为软件的构建和运营者，我早已变得习惯于“用正确的工具做正确的事”（如果在管理上许可的话）。很明显 Gartner 所指的社区角色是哪一个。在某种程度上，按你的职责去选择做事方式是一种可行的做法。

Tim Berglund：我觉得这一预估就如同停留在想象中的永不会实现的开发者 API，但撇开此点不谈，这种大趋势却已经呈现。凡是具有 Spark 集成功能的非关系数据库，都通过 SparkSQL 提供了关系的和非关系的数据模型。在我们所创建的所有新数据库中，我们已降低了关系数据库相关特性的重要性（正如所有 NoSQL 倡导者在某种程度上已经实现的！）。在此之后，我们希望有朝一日能在这些数据库上重新实现关系代数。这种做法可使我们在保留关系模型功能的同时，继续与时俱进地探索各种运营和性能相关的特性空间（例如：弹性扩展性、低延迟写操作、无模式数据模型等）。

InfoQ：大家能探讨一下如何结合使用 NoSQL 数据库和大数据技术（例如 Hadoop 和 Spark）去解决大数据的问题吗？

Seema Jethani：NoSQL 数据库和 Hadoop、Spark、Kafka 等这些其它的大数据技术，已经用于构建面向大规模数据集的数据分析流水线。在这里举一个这样的例子，对于具有经常性查询和更新需求的短期运营数据而言，数据分析可使用 Riak 或者是借助于 Riak 实现；之后，数据可迁移到用做数据仓库的 Hadoop 平台上，这里 Hadoop 实现长期存储数据所需的数据仓库；Spark 用于 Riak 和 Hadoop 批分析之上的数据抽取和实时分析。

Perry Krug： 这有点走回到上面围绕混合持久化所做的讨论中去了。在几乎所有的时间里，“运营数据库”和“分析数据库”技术间是存在差距的。即使在某些地方上，两者可使用相同的技术，但因为需要适合不同的需求，两者在部署上还是有差别的。

“大数据”是个非常宽泛的流行词，它包含了 NoSQL（运营）和 Hadoop、Spark（分析）这样的传统“大数据”技术。从应用整体的角度看（设想一下 Facebook 或 LinkedIn），为达到应用的总体需求，将 NoSQL 和 Hadoop 技术结合起来是十分关键的。结合了数据批处理与实时处理的“lambda 架构”理念，当前正很好的确立起来。

这个问题也可以从 NoSQL 与 RDBMS 的对比方面看……NoSQL 系统的设计、架构和资源需求与 Hadoop 和批处理系统是完全不同的。这是完全合理的，因为每种不同系统的目标不同，并且在两者间通常很少有交集。虽然 Spark 的出现模糊了批处理和实时处理间的这个界限，但是 Spark 依然还不是一种“运营数据库”技术。

我期待将可继续看到两类技术间的趋同，即运营和在线处理技术与批处理和离线处理技术。但是我期望在同一应用中这两种需求间总是能分离开的。

Jim Webber： 在 Neo4j 的世界观中，可轻易地将这个问题一分为二。其中一半是图存储和查询领域，目前为止 Neo4j 是该领域的领先技术；另一半是图计算领域，这个领域的引领者明显就是 Spark。在很多用例中，我们可看到 Neo4j 用作权威图的仓库，为下游系统以及运行图查询的工作负载提供输入。但是我们也看到 Spark 这样的图处理基础架构从 Neo4j 中取出子图的投影，进行并行处理并将结果返回到图中。如此良性循环丰富了图模型。

Tim Berglund：首先需要重点指出的是，“NoSQL”并不总是意味着“规模”。一些 NoSQL 数据库选择了在性能和数据模型上做创新，这些数据库的规模与关系数据库相比并无任何的不同。但是，对于这些也归属于大数据类别的 NoSQL 数据库，架构上的关键差异在于与分布式计算工具的集成上。尤其是将 Spark 与 Cassandra 或 Riak 这样的数据库集成，这为数据模型增加了进行即席分析的灵活性。如果不是这样，就不能很好地支持即席查询。这种架构提供了这样一种承诺，即无需在系统间进行 ETL 即可在运营数据仓库上进行分析。这虽然是一种刚开始被架构师们所采用的新方法，但是它将是一种由于传统分析系统的成功方法，至少有时是如此的。

InfoQ：在构建模块化且可扩展的企业应用中，微服务近来正受到大量关注。大家能讨论一下如何结合使用微服务与 NoSQL 数据库吗？

Seema Jethani：微服务与 NoSQL 有多种结合使用的方式。从一个极端上讲，每个服务可拥有自己的数据库实例。但这种方式对于运营而言是一个挑战，所以并不建议这样做。而在面向用例的方法中，解决特定问题的服务共享同一数据库集群的方式更适合于微服务架构。这里，Riak 是一种非常受欢迎的解决方案，它适用于微服务架构。具体而言，Riak 是不需要主服务器的，它在每个节点上运行同样的代码，因此 Riak 集群可实现水平地扩展和收缩，无需依赖其它服务。此外，对于数据的读取、写入、更新和检索，Riak 提供了良好定义的 HTTP 和 PBC API；对于远程监控，Riak 提供了 REST 终端；对于自动部署和配置，Riak 具有随即可用的 Ansible playbook 和 Chef recipe。

Perry Krug： 微服务可很好地与 NoSQL 结合使用。NoSQL 所给出的主要优点（这通常取决于厂商），就是易于设置和运行大量的小型实例或集群，与此同时，当应用或微服务需求增加时，NoSQL 依然可以快速地扩展这些实例或集群。从硬件、代价和配置角度看，对于 RDBMS 上述功能虽然在理论上是成立的，但实际中是不太可能被实现的。

Jim Webber：一般来说，每个微服务都会去使用最适合自身的数据库（如果该微服务需要数据库的话）。但是管理由微服务组成的系统，这本身就是一个高要求的挑战。这不仅是因为从计算机科学角度看分布式系统是个难以处理的问题（尤其是对故障的处理），而且因为需要工具去管理由许多相互独立微服务所构成的网络的演化。

幸运的是 Neo4j 以微服务管理而著称，可将系统整体看作一个由相互影响的服务所构成的图。在近期举办的 GraphConnect 大会上，我们给出了一个非常好的视频，其中来自 LendingClub 的人讲述了他们用 Neo4j 管理微服务资产的方法。视频在这里 http://neo4j.com/blog/managing-microservices-neo4j/ 。

从图的视角看待你的系统，可使你针对系统中存在的错误和竞争情况，进行预测性的以及响应性的分析。你可将故障作为影响价值的因素，推断故障的成本，并将所有这些提供给终端用户。你也可以通过定位单点故障，用实时监控数据保持你的模型是最新的。这样对于整个系统的可靠性和所具有的风险而言，该模型提供了经实际验证所调整的视图。

对于在 IT 选型上特别大胆的用户（正如我几年前所讲到的某个大型电话公司），可以考虑用图模式对用户的微服务部署进行权威地描述。考虑到图遍历所具有的副作用，可以考虑建立用做在 PAAS 上实际构建系统的部署脚本，该脚本中将图作为最终的配置管理数据库。

Tim Berglund： 关系数据库的建立发展环境是由单一模式支持一系列小型客户 - 服务器架构应用，而 NoSQL 数据库的建立发展环境是由一个数据库为单一大型 Web 站点提供服务。在后一种架构形式中，相对而言像程序上的事务边界和粒度安全这样的特性并非是十分重要的，正好通常在 NoSQL 数据库中这些特性也是缺失的或不成熟的。

但是采用 NoSQL 的领域正从不常使用 NoSQL 的大型 Web 领域中，转移到更常使用 NoSQL 的企业 IT 应用领域中。这看上去好像单一应用架构的假设已不再成立了，因为许多不同企业中的应用和服务或许想要去访问 NoSQL 数据库中的数据。

对于这个问题，微服务是一种很好的解决方案。微服务可使架构支持小部分代码与数据库的通信，这符合 NoSQL 数据库设计所依赖的最初假设，使得该服务对其它企业 IT 应用栈的用户可用。如果在企业范围内采纳了微服务，我们称这种集成方法为“原生方法”，这样内部工具和企业的专门知识可围绕这种方法发展。源自上世纪九十年代的数据库所提供的“缺失”特征，相对而言在这种新范例中也并非是十分重要的。

InfoQ：容器技术提供了在独立部署环境中部署软件应用的机制。在 Docker 这样的容器中运行 NoSQL 数据库有哪些优缺点？

Seema Jethani：容器易于建立，并且容器所具有的轻量级本质可使硬件得到更有效地使用。但同时，围绕着服务发现、联网和实例存储的挑战却依然存在：

• 服务发现：虽然在 Docker 容器中可以建立多个集群，但是如何连接到我们所需的集群呢？如何与包含了我们所需集群的容器保持联系？虽然 Weave 这样的工具可有助于实现这些功能，但是如何发现用于建立连接的主机及端口依然是一个问题。
• 实例数据存储：启动 Docker 中的数据库集群时，除非是出于运营的考虑而使用同一节点中的同一数据目录，否则每次启动后将会得到一个全新的集群。在某些情况下这样的新集群可能正是你所需要的，但是并非全部情况下都是如此。这个问题在云环境中尤其严重，因为云中的节点经常会发生故障。恐怕没有人会愿意去承担由数据分区收敛和重分区所导致的代价。
• 联网：数据库所绑定的 Docker 内部 IP 不能被 Docker 驻留进程以外的应用所访问。而在用户指明了覆盖规划中数据所在的节点，而数据库必须对这样的用户做出响应的情况下，容器需要提供可被用户所理解的地址。

Perry Krug：鉴于在容器中运行数据库依然是一个初生事物，我认为该技术很有希望并将迅速成为被广泛采纳的技术。“NoSQL+Docker”的优势在本质上是与“任何技术 +Docker”的搭配是一样的……相比于当前的虚拟机技术，该技术提供了更多的优点，包括：去除了管理程序的性能代价开销，考虑了部署上的灵活性。

在我看来，该技术还存在着一些缺点，但是这些缺点主要取决于这两种技术结合使用的成熟度，而非是由于继承两者间的局限性所导致的。

1. 安全和资源隔离是一个大问题，但是这个问题可以通过技术进步和最佳实践解决；
2. 目前通常认为容器是非常“无状态的”，而数据库常常是需要持久化存储的。这也是在容器层面正在改进的事情。

Jim Webber：类似于大多数 NoSQL 数据库，Neo4j 在容器中运行良好（或者说实际上在其它虚拟化环境中也运行良好）。事实上，现在已有支持 Neo4j 与 Docker 结合使用的官方 Docker 镜像，点击这里查看。

数据库虚拟化的唯一问题就是邻居行为的不确定性。数据库（包括 Neo4j）喜欢运行于 RAM 中，如果做不到这一点，那么它们喜欢运行于快速无竞争的磁盘通道上。如果因为存在无法预测的行为或是贪心的邻居，而使得在以上两点喜好上存在竞争，那么数据库实例的性能会受到影响。但是如果这个问题能很好地得到解决，所有事情都 OK。

Tim Berglund：这个问题再次使我想到了分布式 NoSQL 数据库。这些数据库是按部署在多个服务器上而设计的，这样的数据库集群具有可弹性地扩大或缩小的潜力。

部署自动化和不可变基础架构所具有的优点，对于任何你想要部署的计算机程序都是适用的，对数据库同样也不例外。但是相对于其它使用 Docker 部署特定微服务这样的独立服务而言，Docker 在部署 NoSQL 数据库中的价值稍逊。在微服务架构中容器的使用情况依赖于这样一个事实，即已部署的镜像会随着代码的改变而一起改变。而在理想情况下，每个数据库节点所部署的镜像并不经常发生改变。

这并非说在面对 NoSQL 时，Docker 是个错误的选择。如果你已经在系统中的其它地方使用了 Docker，愉快地将数据库也包括进来可能是一个聪明的做法，但是 NoSQL 自身并不便于转向基于容器的方法。

InfoQ：当前 NoSQL 数据库对安全和监控的支持情况如何？

Seema Jethani：监控功能通常是通过与 New Relic、Datalog 等监控厂商的集成而提供，或者是使用诸如 Nagios 这样的在家中即可设置的软件。两者所使用的指标是由数据库采集并提供的。

一般情况下，数据库系统原装地提供了认证、数据管治和加密等安全特性。每种数据库对安全特性支持的程度不同。

以 Riak 为例，它支持存取控制，及支持多认证来源及组和用户角色的认证。Riak 具有访问日志，可以被审计。对于监控而言，Riak 具有状态信息，其中包括计算所得的状态，以及从命令行和 http 接口中获取的原始状态。企业用户还可以访问 Java 管理扩展监控、SNMP 状态和陷阱（trap）。

Perry Krug：确实应该将安全和监控区分开，或者是对两者给予进一步地澄清。监控一直是 NoSQL 数据库的运行和管理中的一个关键部分，而安全是直到最近才成为其中的一个关键部分。这并非说某种技术在某一领域中体现出较好的或较差的能力，而是说监控早已成为一个讨论话题，并得到了相对更长时间的改进。在我看来这使得监控在整体上处于更好的发展状态。

我认为安全是更具有讨论意义的话题:-)。NoSQL 技术的早期采用者并未对非常稳定的安全功能给予高度重视，或是对此提出很高的需求。NoSQL 技术的创建者们所遵循的原则是：当面对无止境的可能特性或改进列表时，选取其中对客户最为重要的特性。在过去的数年中，安全的价值和重要性程度正在发生转变，这与那些采用 NoSQL 的应用和组织在类型上所发生的转变是一致的……进而这种转变得到了技术的创建者们的纷纷效仿。

在我看来，将 NoSQL 与 RDBMS 在安全方面进行对比是不对的。在安全特性的构建上，RDBMS 已经经历了三十到四十年的发展历史。当回顾数据库自身的历史时，会发现数据库使用了“用例驱动”的决策，这正同样在 NoSQL 的早期发展阶段中采用。我毫不怀疑在 NoSQL 中安全将会具有越来越重要的地位，不断进步的技术将会继续创建 NoSQL 用户所需的特性。

Jim Webber：我确实不知道什么才是通用案例，但既然 NoSQL 数据库已支撑了很多的生产系统，我猜想这些案例应该是合理的。对于 Neo4j 的案例而言，我们已将安全和监控融入了系统中，并设立了专职的团队负责运营的相关事宜。将来我们会实现开箱即用的与 LDAP、Kerberos 和 AD 认证的集成（当然部分代码已经在我们的 github 代码库中可见），并完善我们的监控界面。进一步，我们将通过自有的二进制协议向用户 app 完全地公开系统监控相关数据，这可使这些监控 app 可以成为使用官方监控数据的“正规”app。

Tim Berglund：我可以轻松给出 Cassandra 在这个领域中的情况，因为我就是专门从事于此的。开源 Cassandra 具有非常基本的安全特性，并可被 Nagios 等开源工具所监控。Cassandra 的商业版本，即 DataStax Enterprise 企业版，具有与 LDAP 和 Kerberos 等认证方式集成这样更加复杂的安全特性（而非将安全证书存储在数据库自身中），并提供面向 Cassandra 生产集群管理需求而优化的用户定制管理工具。

InfoQ：大家认为即将在 NoSQL 数据库空间出现哪些新特性和创新？

Seema Jethani：举例说，一个值得关注的研究方向是，为了维持事务（即使是并发事务）的正确性如何尽量降低操作间的相互协调，进而使得分布式数据库中事务不仅可行而且高性能。可在这里找到该研究的相关细节。

多年以来，NoSQL 数据库逐渐拉近了关系数据库的优点与 NoSQL 数据库所提供的灵活性和可扩展性之间的距离。如上所述的研究和创新，使得我们可以享用来自于这两个世界的优点。

Perry Krug：因为每种技术都是完全不同的，并沿着不同的路径发展，这个话题非常难以从最宽泛的 NoSQL 层面上讨论。我认为将会看到越来越多的 NoSQL 特性试图去解决或者模仿 RDBMS 中所具有的特性。我并不认为简单地拷贝是一个好的主意，但是也不能否认为达到一些应用的需求，确实需要完全相同“类型”的特性（在此特别针对“事务”来思考的，但其他特性也可举一反三）。

不同技术间也将会持续地扩展和重合，这将会导致这些技术在性能和可靠性上更加地差异化。我认为伴随着大多数（大于 100 种）NoSQL 数据库的消失，将会出现技术和销售商间的合并。

如果真正地以创新为导向，我期望 NoSQL 中会加入更多的实时分析能力，以及或许是标准的语言或 API 的出现。

Jim Webber：我研究生毕业后的第一份工作就是做事务处理（现在依旧得到 InfoQ 编辑 Mark Little 的支持）。伴随着 NoSQL 的出现和最终一致性的普及，这整个领域已变得非常不酷了。但是在 2012 年左右事情发生了改变，Peter Bailis (高可用事务)、Diago Ongarro (Raft)、Emin Gun Sirer(线性事务) 以及其他许多的研究人员开始从高通量、避免协调可扩展系统的角度，重新地考虑交易和一致性协议问题。在高可用世界中，对强一致性研究兴趣的复活是一件十分令人激动的事情，我期望能看到这种思考对 NoSQL 世界产生广泛的影响。事实上它已经影响了 Neo4j 的工作方式，并在很大程度上构成了我们未来产品路线图中一些与容错和规模相关的特性。有一些日子，我简直不能想象我的老板事实上是付钱让我去做这些事情。这真是让人难以抗拒呀！

Tim Berglund: 我期望能看到以下的这些特性：

• 更好地支持在水平可扩展数据库中对的运营数据实时分析；
• 改进的工具；
• 越来越多原生可用的关系代数。

针对 NoSQL 数据库，专题讨论小组参加者们还给出了如下的额外评论。

Perry Krug： 几点思考：

• 事实上在更高的层次上，NoSQL 只提供两样事情：一个是数据和开发的灵活性，另一个是更优的可运营性（性能、规模、高可用等）。这次专题讨论小组会主要聚焦于开发人员，因此看上去更多地侧重于第一个事情上，并未花费多少时间探讨运营问题。而对于依赖于底层的数据库的组织或应用而言，运营是十分关键的。从历史上看，在 NoSQL 空间中的不同技术也是侧重于这两样事情其中之一的……但是客户对两者都有需求。在一个组织决策是否根本不使用 NoSQL，或是使用哪种 NoSQL 技术时，需要将两样事情都列入考虑中。
• 移动计算和应用正被日益看重。最前沿的处理能力正在迅速增长，对以离线或者半连接方式工作的应用的需求也在增加。NoSQL 数据库是否可用于移动设备，以及它们将起到怎样的作用，这是一个有趣的话题。

Jim Webber：数据库依然是一个应参与进来的、令人激动的领域。但是我考虑的是，NoSQL 这个头衔还要维持多久。现在，列数据库、键值仓库、文档数据库、图数据库具有它们各自的强项。这些系统将如何发展是令人关注的。这确实是个有意思的时代。

结论

在这次虚拟专家小组会上，我们从四位具有不同的 NoSQL 数据库经验的主题专家那里，学到了 NoSQL 数据库的现状，也学到了如何去使用具有大数据技术的 NoSQL 数据库，以及包括微服务和容器技术等在内的其它新技术趋势。

专题讨论小组参加者的简介

Seema Jethani 新近担任了 Basho 科技公司的产品管理部门主管，负责公司的旗舰产品 Riak KV 键值数据库、Riak TS 时序数据库和分布式 NoSQL 数据库。在加入 Basho 公司之前，她曾在 Dell 公司、Enstratius 公司和 IBM 公司担任产品管理和策略职位。可通过 twitter 账号 @seemaj 联系到她。

Perry Krug是 Couchbase 公司的首席解决方案架构师及客户利益代言人。Perry 曾与数百用户和公司一起部署并维护 Couchbase 公司的 NoSQL 数据库技术。他在高性能缓存和数据库系统上具有十多年的经验。

Dr. Jim Webber是 Neo Technology 公司的首席科学家，在公司中他致力于图数据库服务器技术及开源软件的编写。Jim 的兴趣在于使用 Web 这样大规模的图构建分布式系统，这也引导他与其他人一起合著了《REST 实战》一书，以及更早的著作《开发企业级 Web 服务 - 架构师指南》一书。

Tim Berglund是一位讲师、作家及 DataStax 公司的技术负责人。他在 DataStax 公司中担任培训主管。他经常在美国国内及全球范围内的各种会议上做演讲。他也在 O’Reilly 培训视频中担任合作讲师，讲授的内容从 Git 到分布式系统。此外他也是《Gradle，超越基础》一书的作者。他用 @tlberglund 账号发表推文，并时常发表博客文章。他与发妻及他们的最小的孩子共同生活在美国科罗拉多州利特尔顿市。

查看英文原文： Virtual Panel: Current State of NoSQL Databases

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。