1. 我是CIO首页
  2. 观点

超越NoSQL:分布式SQL的情况

超越NoSQL:分布式SQL的情况插图(1)

随着面向对象编程语言的日益流行,一些人认为解决面向对象语言和关系数据库的“阻抗不匹配”的解决方案是在数据库中映射对象。因此,我们最终得到了“面向对象的数据库”。关于对象数据库的有趣之处在于,在许多情况下,它们基本上是一个内置了对象映射器的普通数据库。它们的受欢迎程度逐渐下降,下一个真正的大众市场尝试是2010年代的“ NoSQL ”。

对SQL的攻击

NoSQL以相同的方式攻击了关系数据库和SQL。这次的主要问题是Internet破坏了已有40年历史的关系数据库管理系统(RDBMS)体系结构的基本前提。这些数据库旨在节省宝贵的磁盘空间并垂直扩展。现在,有太多用户和太多资源供一个胖服务器处理。NoSQL数据库表示,如果您有一个没有联接,没有标准查询语言(因为实现SQL需要花费时间)并且没有数据完整性的数据库,则可以水平扩展并处理该卷。这解决了垂直比例尺的问题,但引入了新的问题。

与这些在线交易处理系统(OLTP)并行开发的是另一种主要是关系数据库,称为在线分析处理系统(OLAP)。这些数据库支持关系结构,但在执行查询时会理解它们将返回大量数据。1980年代和1990年代的业务仍主要由批处理驱动。此外,OLAP系统还为开发人员和分析人员提供了将数据想象和存储为n维多维数据集的能力。如果您想象一个二维数组并基于两个索引进行查找,从而使您的效率基本上与恒定时间相同,但可以采用此方法并添加另一个维或另一个维,以便您可以执行本质上是三个或更多因素的查找(例如供应需求,以及竞争对手的数量),您可以更有效地分析和预测事物。然而,构造这些是费力且非常面向批处理的工作。

与横向扩展NoSQL几乎同时,出现了图数据库。许多事物本身不是“关系”的,或者不是基于集合论和关系代数的,而是基于父子关系或亲友关系的。一个典型的例子是产品线到产品品牌,再到模型中的组件建模。如果您想知道“笔记本电脑上有什么主板”,您会发现制造商的采购很复杂,品牌或型号可能不够。如果您想知道产品线中使用的所有主板,那么在经典(非CTE或通用表表达式)SQL中,您必须遍历表并分多个步骤进行查询。最初,大多数图形数据库根本没有分片。实际上,无需实际将数据存储为图形即可完成许多类型的图形分析。

NoSQL诺言兑现而诺言破灭

NoSQL数据库的可扩展性确实比Oracle数据库,DB2或SQL Server(它们均基于具有40年历史的设计)要好得多,但伸缩性却更好。但是,每种NoSQL数据库都有新的限制:

  • 键值存储:没有比db.get(key)更简单的查找了。但是,世界上许多数据和用例无法以这种方式构造。而且,我们实际上是在谈论缓存策略。在任何数据库中,主键查找都是快速的。重要的只是内存中的内容。在最好的情况下,它们像哈希图一样扩展。但是,如果您必须进行30次数据库旅行才能将数据重新放在一起或进行任何类型的复杂查询,那么这将行不通。这些现在更经常地实现为其他数据库前面的缓存。(例如:Redis。)
  • 文档数据库:之所以如此流行,是因为它们使用JSON,并且对象易于序列化为JSON。这些数据库的第一个版本没有连接,将整个“实体”放入一个巨型文档中有其自身的缺点。没有交易保证,您还会遇到数据完整性问题。如今,某些文档数据库支持一种不太可靠的事务处理形式,但是它与大多数人习惯的保证级别不同。同样,即使对于简单查询,这些延迟通常也很慢-即使它们在整体扩展方面更好。(示例:MongoDB,Amazon DocumentDB。)
  • 列存储:这些存储与用于查找的键值存储一样快,并且它们可以存储更复杂的数据结构。但是,执行看起来像跨三个表(在RDBMS术语中)或三个集合(在MongoDB术语中)的联接的工作充其量是痛苦的。这些对于时间序列数据确实非常有用(请给我在1:00 pm和2:00 pm之间发生的所有事情)。

还有其他更深奥的NoSQL数据库。但是,所有这些数据库的共同点是缺乏对通用数据库惯用语的支持,并且倾向于关注“特殊目的”。一些流行的NoSQL数据库(例如MongoDB)编写了出色的数据库前端和生态系统工具,使开发人员确实很容易采用它们,但对存储引擎进行了严格的限制-更不用说弹性和可伸缩性方面的限制了。

数据库标准仍然很重要

使关系数据库成为主导的原因之一是它们拥有一个通用的工具生态系统。首先,有SQL。尽管方言可能有所不同-如果您是开发人员或分析人员,如果您从SQL Server 6.5升级到Oracle 7,则可能必须修复查询并使用“(+)”进行外部联接-但是简单的工作和困难的工作相当容易翻译。

其次,您拥有ODBC,以及后来的JDBC等。几乎所有可以连接到一个RDBMS的工具(除非专门为管理该RDBMS而设计)都可以连接到任何其他RDBMS。每天都有很多人连接到RDBMS,并将数据吸入Excel以进行分析。我指的不是Tableau或其他数百种工具。我说的是Excel的“母校制”。

NoSQL废除了标准。MongoDB不使用SQL作为主要语言。当MongoDB最接近的竞争对手Couchbase正在寻找一种查询语言来替代其基于Java的mapreduce框架时,他们创建了自己的SQL方言。

无论是要支持工具生态系统,还是因为很多查询数据库的人都不是开发人员,并且他们都知道SQL,所以标准很重要。

GraphQL和状态管理的兴起

您知道谁有两个大拇指,只是想让他的应用程序状态进入数据库,而不关心如何做吗?这家伙。事实证明,这是一整代开发人员。GraphQL(与图形数据库无关)将对象图形存储在基础数据存储中。它使开发人员不必担心此问题。

较早的尝试是使用对象关系映射工具或ORM(例如Hibernate)。他们获取了一个对象,并根据对象到表的映射设置将其基本上变成了SQL。前几代中的许多很难配置。此外,我们处于学习曲线上。

大多数GraphQL实现都与对象关系映射工具(例如Sequelize或TypeORM)一起使用。结构良好的GraphQL实现和API不会在整个代码中泄漏状态管理问题,而是会在对象图发生更改时写入并返回相关数据。谁真正在应用程序级别关心数据的存储方式?

面向对象和NoSQL数据库的基础之一是应用程序开发人员必须意识到数据如何存储在数据库中的复杂性。自然,这对于开发人员来说很难掌握新技术,但是现在不再困难了。因为GraphQL完全消除了这一担忧。

输入NewSQL或分布式SQL

Google遇到了数据库问题,写了一篇论文,后来写了“ Spanner”,它描述了全球分布的关系数据库如何工作。Spanner引发了关系数据库技术的新一波创新。实际上,您可以拥有一个关系数据库,并使其不仅可以随碎片扩展,还可以在需要时在全球范围内扩展。而且,我们正在谈论的是现代意义上的规模,而不是令人失望的且总是复杂的RAC / Streams / GoldenGate方法。

因此,在关系系统中“存储对象”的前提是错误的。如果关系数据库的主要问题是后端而不是前端怎么办?这就是所谓的“ NewSQL”或更恰当的“分布式SQL”数据库的思想。这个想法是将NoSQL存储知识和Google的Spanner想法与成熟的,开源的RDBMS前端(例如PostgreSQL或MySQL / MariaDB)相结合。

这意味着您可以拥有多个节点并可以水平扩展-包括跨云可用性区域。这意味着您可以拥有一个数据库,就可以拥有多个数据中心或云地理区域。这意味着您可以拥有真正的可靠性,这是一个数据库集群,对于用户而言,它永远不会崩溃。

同时,整个SQL生态系统仍然有效!您无需重新构建整个IT基础架构即可做到这一点。尽管您可能不愿意“淘汰并替换”传统的RDBMS,但大多数公司并未尝试使用更多的Oracle。最重要的是,您仍然可以在云中和全球范围内使用SQL和所有工具。

本文为作者 胡慧 独立观点,并不代表 我是CIO 立场。

发表评论

登录后才能评论