大数据 nosql_NoSQL和下一代大数据

大数据 nosql

今年，OSCON与会者将有机会听到Henrik Ingo在《 销售开源101》上的演讲。

Ingo是MongoDB的高级解决方案架构师。 他活跃于许多开放源代码项目，并且是《 开放式生活：开放源代码的哲学》一书的作者，该书是关于开放源代码社区道德和商业模式的书。

在这次采访中，他提供了对MongoDB的见解，并解释了为什么它是大数据分析和构建微服务的首选平台。

您所说的NoSQL数据库是什么？ NoSQL和RDBMS有什么区别？ 何时以及何时不使用NoSQL数据库？ NoSQL数据库的优点是什么？

所谓的“ NoSQL运动”始于2007年左右。也许NoSQL的萌芽形式是memcached的广泛使用，然后演变成许多键值数据库，例如Redis，Riak，Voldemort等。 也有关于该主题的学术论文发表，例如Google和Amazon描述了这些公司内部使用的系统。

此开发的主要推动力是需要从旧的RDBMS体系结构转变为更具可伸缩性的横向扩展方法。 RDBMS产品为我们提供了很好的服务，但是它们在不同的时间针对不同的需求进行了设计。 从历史上看，数据库是用来支持公司内部流程的。 甚至最大的公司也只有几十万名员工，即使那样，他们也不会一次全部使用同一个数据库系统。 相比之下，现代网络公司的系统上将同时存在数以万计，甚至数亿个用户。 这是规模的千倍增长，并且需要使用不同的架构方法。 同样，每个用户存储的数据量也在爆炸式增长，因此世界正在经历指数级增长。 全球数据量每隔14个月就会增加一倍-不管是取还是取。

名称“ NoSQL”仅表示以下事实：这种新型数据库摆脱了自1974年以来旧数据库一直依赖的API和查询语言。的确，两年前我加入MongoDB的主要动机之一是意识到，这是我一生中第一次（！），数据库世界中发生了新的事情，并且有机会我意识到，如果不加入数据库，那将是我的疯狂。

“ NoSQL”并不是最恰当的名称，因为它仅描述了产品类别不具备的功能，并且完全错过了存在各种NoSQL数据库以满足不同需求和用例的事实。 新一代数据库唯一的共同点是我们不是关系数据库。

更令人困惑的是，由于许多用户已经熟悉SQL，因此如今许多NoSQL数据库实际上都提供了类似于SQL的查询接口。 在我们自己的生态系统中，MongoDB也有几个第三方解决方案来提供该功能。 因此，现在我们已经进入了NoSQL数据库支持SQL的世界。 许多人会说现在应该淘汰“ NoSQL”名称了。 在我们的其余讨论中，我将使用“非关系数据库”代替“ NoSQL数据库”，以避免产生争议。

尽管如此，在这种非关系型非关系数据库中仍存在一些共性。 具有横向扩展体系结构（基于某种形式的分片）是一个常见特征。 对于复制或高可用性而言，它们是相同的，在当今，它仍然是关系数据库领域中的附加产品。

最后，这些数据库没有关系数据模型（这意味着数据被建模为二维表）也是一个特征。 例如，在MongoDB的情况下，我们基于JSON的数据模型和查询语言是开发人员真正喜欢的东西，通常是MongoDB的优势中提到的第一件事。 开发人员不仅熟悉JSON，而且动态架构允许更快速和迭代的开发风格，而无需事先进行繁重的计划。 今天生成的新数据中约有80％是非结构化的，因此这也是我们需要合适的数据库解决方案进行匹配的另一个原因。

哪些功能使MongoDB企业版成为MongoDB社区版（特别是企业客户）首选的平台？

粗略的经验法则是，核心差异在于开发人员可能会在MongoDB中找到他想要的所有内容，而运营团队将从中受益，它具有管理，备份和监视功能。 MongoDB Enterprise Advanced随附的MongoDB Ops Manager 。 在称为“云托管”的解决方案中，许多此功能也可用 MongoDB管理服务 。 此外，MongoDB Enterprise Advanced包括许多安全功能，这些功能一旦开始投入生产就可能变得很重要，例如与LDAP和Active Directory的单点登录集成，PKI证书以及针对数据库执行的所有操作的审核日志，合规报告。

MongoDB Enterprise Advanced还通过1小时的SLA提供24x7的全球支持，以及针对开发和DBA团队的企业认证和按需培训。

MongoDB 3.0集成了WiredTiger引擎和Ops Manager工具。 这对企业意味着什么？

这很简单： 更容易扩展！ 但是它们各自出于不同的原因而有助于扩展。

随着您的扩展，Ops Manager可以帮助Ops团队管理越来越多的MongoDB进程。 MongoDB的安装和管理非常简单，但是，如果您有100个节点的集群，甚至只有12个节点，则手动安装或升级每个服务器都没有意义。 Ops Manager可以通过单个控制台或REST API调用来配置，部署和管理整个集群。 您可以通过单击按钮启动复杂的操作，例如零停机滚动升级，然后喝咖啡。 当然，它会执行监视和连续备份等基本操作。

如果您不了解自动化的价值，请考虑Ops Manager的用户通常会报告DBA时间的效率提高10到20倍。

WiredTiger存储引擎是在MongoDB 3.0中引入的，它是数据库引擎在某些类型的工作负载（尤其是对数据库写入操作占主导的工作负载）上的性能方面的革命性进步。 顺便说一下，它在3.0中仍然是可选的。 您必须在启动时选择它。

WiredTiger由BerkeleyDB的原始开发人员创建，BerkeleyDB是世界上使用最广泛的嵌入式数据库。 MongoDB于去年12月收购了WiredTiger，因此它们与开发MongoDB的其余团队完全集成。

到目前为止，我们的数据库引擎仅称为MMAPv1引擎。 它为MongoDB提供了很好的服务，并且可以追溯到MongoDB是一个非常简单且年轻的非关系数据库的时代。 然而，如今，MongoDB已被要求非常严格的客户和越来越多样化的应用程序所使用。 因此，WiredTiger可以帮助我们很好地处理更广泛的应用程序。 毫无疑问，这无疑将我们的数据库引擎故事带到了性能和基准测试辩论的最前沿。 它是现代MVCC引擎，使用诸如危险指针的现代锁定算法来支持高度并发的工作负载。

WiredTiger的功能远远不止于写密集型工作负载的更好性能。 例如，大多数MongoDB用户存储大量数据，因此他们将从内置压缩中受益 。 存储引擎还具有一些很好的功能，这些功能将在将来集成到MongoDB中并公开给我-我已经知道将会发生的是基于LSM的索引。 （基于LSM的索引非常适合写繁重的磁盘绑定工作负载。）

您是否相信NoSQL数据库比关系数据库更适合云计算？

是。

令人惊讶的是，在2015年，即Amazon Web Services（AWS）推出近十年之后，没有一种主流的RDBMS解决方案对分片提供任何有用的支持。

为了避免来自RDBMS领域的朋友的抗议，我应该澄清一下：我知道一些不是主流的好的解决方案，还有一些不好甚至没有用的解决方案。 基本上，这对于RDBMS来说仍然是一个未解决的问题。

另一个区别是易于使用和配置。 从历史上看，在企业数据中心中，您至少需要三个月才能获得新服务器，有时甚至需要6到12个月！ 在这种情况下，安装和配置数据库软件可以花费一天甚至一周的时间并不是什么大问题。 但这在2015年是不可接受的。您可以在五分钟内启动一个云实例，并且即使手动完成，也不需要花太多时间在其上安装MongoDB。 （而且，就像我之前提到的那样，我们的MMS服务可以为您自动化安装，从而使其安装更快。如果您提供密钥，它甚至可以为您启动AWS实例。）

NoSQL实现主要基于CAP定理吗？ 您能否解释一下CAP定理如何帮助您选择正确的NoSQL技术？

噢亲爱的。 CAP定理 是一个有争议的话题 。 充其量是令人困惑的，而最糟糕的是没有用。

CAP定理讨论的问题仍然是真实的。 对于分布式数据库，管理可用性，可伸缩性和一致性之间的折衷是一项挑战。 有许多有趣的解决方案，解决方案的范围比“ CA”或“ AP”要广泛得多。 我个人花费大量时间来学习和讨论这个话题，并且可能是自己接受采访的话题！

MongoDB对此的解决方案非常简单并且易于理解。 我们基于“最小惊喜/最高生产率”的理念提供默认配置：客户端对单个主服务器进行写入和读取（每个分片），而复制到辅助服务器仅是为了提供高可用性。 这提供了一致的读取和无冲突的写入，我们相信这是任何开发人员都觉得自然且易于理解的东西。 使用配置选项，开发人员可以选择将读取发送到辅助节点，但随后他们必须了解并管理最终一致性的后果。

顺便说一句，我发现尝试理解不同一致性级别的含义是有用的，而不是试图理解CAP定理。 道格·特里（Doug Terry）写了一篇出色的论文，《 通过棒球解释复制的数据一致性》 ，我觉得非常有用！

MongoDB对大数据有何看法？ 它在构建大数据生态系统的过程中增加了什么价值？

大数据通常以“ 3V”规则为特征：体积，多样性和速度。 虽然这是一种“顾问式发言”，但实际上我发现它是一个有用的描述。

第一个V很明显：您有很多数据。 在MongoDB空间中，任何人都不可能拥有PB级的数据。 我们确实有大量数据的客户，但是通常将它们存储在多个单独的MongoDB集群中是有意义的-因为它起源于不同的应用程序，并且不需要将数据放在一起。 但是，即使对于单个应用程序来说，也具有大量的TB会发生很多事情。 在大约7年前的我卖MySQL的日子里，任何人甚至达到一个TB都非常罕见！

在我看来，多样性是MongoDB和我们基于JSON的具有动态模式的数据模型的强项。 人们经常陷入大数据的“大”部分，但实际上，现代数据的多样性和非结构化性质通常更具挑战性。 在我看来，MongoDB确实很好地处理了多样性部分。

最后，Velocity指的是对数据的新鲜度以及数据到达数据库的速度的期望变化。 从历史上看，您可以在晚上或什至周末将数据加载到数据仓库中，然后在月底生成报告。 当然，这不再被接受-数据必须在到达时加载到您的大数据数据库中。 而且在许多情况下，您还需要进行实时分析：这意味着在将数据插入数据库后的几秒钟甚至几毫秒内进行查询。

MongoDB在可能为大数据解决方案选择的技术中扮演什么角色？

我们在所有方面都很好地满足了上述3V要求。

当然，经常将两种最流行的技术结合使用也就不足为奇了：Hadoop和MongoDB。 它们彼此互补，可以为大数据应用程序提供支持。 Hadoop历史上一直专注于大量历史数据的真正重型处理。 此类Hadoop分析的范围从几秒钟到几小时不等。 另一方面，MongoDB是具有索引的数据库，并且可以在数分钟至毫秒的范围内进行相对较快的查询。

从MongoDB到Hadoop再回到MongoDB的典型数据流如下所示：

• MongoDB支持在线实时操作应用程序，为业务流程和最终用户提供服务。
• Hadoop使用来自MongoDB的数据，并将其与其他操作系统的数据混合，以促进复杂的分析和机器学习。
• 结果将被加载回MongoDB，以服务于更智能的运营流程，例如提供更相关的报价，更快地识别欺诈或改善客户体验。
• 还可以有一个实时个性化组件，其中，当用户使用网站或应用程序时，会话或个人资料信息将在MongoDB中直接更新。 Hadoop在历史上并未用于此目的，但是现在诸如Storm，Spark和Flink之类的流数据框架正是在执行此类任务。 因此，Hadoop现在可以在MongoDB中不断更新数据，而不是在分析工作结束时将数据提供给MongoDB。

我们有很多客户都在使用这样的大数据架构：eBay，Pearson，Orbitz，SFR，Foursquare和Square Enix只是其中的几个。 （ 您可以在我们的网站上阅读有关它们的信息 。）

我们查询语言的聚合框架部分真正体现在分析中。 我相信这是MongoDB成为大数据流行选择的原因之一。

什么时候以及为什么选择MongoDB作为构建微服务的平台？

在这里，我看到两种不同的体系结构方法：

对微服务的严格解释是，每个服务都是独立的，并且至少在理论上可以使用不同的编程语言和数据库。 在这样的体系结构中，您最终会获得多语种持久性，这意味着“正确的工具来完成正确的工作”的理念。 因此，如果我们相信各种市场份额研究（仅就此示例而言），那么也许您的一半服务选择构建在MongoDB上，而10％到20％的用户使用键值存储或宽列存储，而某些使用图形引擎或文本搜索引擎。

另一方面，您可能宁愿选择“数据库即服务”模型。 在这种方法中，数据库（也就是MongoDB）集中在一个专门的DBA团队中，该团队随后还负责备份，高可用性和调优。 然后，每个构建微服务的开发团队都将只使用此DBaaS，而根本不必担心数据库，从而使他们的工作变得更加轻松。 当然，某些服务可能仍需要其他功能，例如文本搜索引擎或图形数据库。

最近的范式转换意味着许多关系数据库已经合并了存储非结构化数据的功能。 一方面，这表明世界终于接受了以不同视角查看数据的重要性，但另一方面，它也弥合了关系世界和noSQL世界之间的差异。 您如何看待？

嗯，这与从相反的方向添加对SQL的支持的NoSQL数据库相同。 它表明对非结构化数据的需求正在增长。

但老实说，我仍然不认为这些添加与非关系产品真正竞争。 例如，PostgreSQL对JSON的支持看起来确实不错，但是我不记得有没有人在MongoDB或PostgreSQL之间进行选择。 在我看来，这些功能使RDBMS的现有用户的生活更加轻松，但是从根本上来说，它们仍然是RDBMS。 特别是，缺乏对分片以扩展数据库和支持内置复制以实现高可用性或跨区域数据分发的支持，这仍然是两个世界的一大区别。

OSCON
演讲者访谈

本文是OSCON 2015 演讲者访谈系列的一部分。OSCON OSCON是所有开源内容，包括完整的堆栈，以及您每天在工作中使用的所有语言，工具，框架和最佳实践。 OSCON 2015将于7月20日至24日在俄勒冈州波特兰举行。 。

翻译自: https://opensource.com/life/15/7/interview-henrik-ingo-mongodb

大数据 nosql