Get best of the week

为什么NoSQL数据库不是现代应用程序的糟糕解决方案

哈Ha

今天，我们提请您注意MemSQL博客文章的翻译，该文章最初是一则广告（致力于MemSQL的优势，于2020年1月上旬更新）。但是我们还是决定以缩写形式进行翻译，因为它详细解释了为什么我们尚未决定在MongoDB，Cassandra或其他非关系数据库上发布任何内容。也许我们是对的，将自己局限于一本非常成功的书《最大限度地使用MySQL》。

现在是时候认识到这一长久以来的真理：NoSQL数据库不适合解决现代应用程序面临的许多实际问题，而这些数据库的时代已经过去了。

之所以出现NoSQL数据库，是因为发明之初就存在的传统数据库无法应对所需的任务规模。新一代的数据处理服务已经出现在十多年前，它可以解决与整个Web相关的许多问题，并可以处理快速增长的数据集。 NoSQL还提供了一种新的经济高效的方法，可以对PB级数据量进行冷存储/间歇式批量访问。但是，在急于尝试应对大数据挑战并支持大量竞争用户的过程中，NoSQL范式要求放弃传统数据库的某些关键属性，这使它们如此高效且易于使用。

也许成功找到所有这些折衷方案是NoSQL对数据库世界的最大贡献。他们通过将大数据处理的最佳功能与成熟的关系模型的结构和灵活性相结合，并创建可扩展的关系数据库，来推动发展。

关系数据库已经得到发展，从而产生了新一代的系统，该系统几乎可以应付任何负载并满足适用于现代应用程序的可伸缩性，可靠性和可用性要求。我们正在谈论的是不同的工作负载-从传统的工作负载（例如事务处理应用程序和业务分析）到更具创新性的工作负载（例如，不同订户之间共享软件（多租户）和运营分析）。新数据库的兴起，尤其是Google Spanner，Azure数据仓库和MemSQL，已证明在大多数情况下，关系数据库比NoSQL系统更易于使用，并且通常表现出更好的性能。

我知道这些是有争议的问题，您可以轻易地拒绝我的观点有偏见。但是，让我对这些数据库的历史，体系结构和应用程序组成部分进行排序-然后自己进行判断。

NoSQL日出


NoSQL在2000年代后期才问世，尽管它们的历史要早得多。他们的开发主要是为了解决现有数据库系统固有的伸缩性问题。显而易见，在创建大型系统时，水平缩放是一种更经济的模型。最大的系统，例如来自Google，Facebook，Microsoft和Yahoo的搜索引擎和电子邮件服务，只能以这种方式扩展。

就个人而言，当我阅读本文时，我首先欣赏了水平缩放的全部价值James Hamilton关于设计和部署Internet范围的服务。最初，我设法扩展应用程序级别，因为无状态系统更易于扩展。数据存储级别是另一回事。根据定义，数据库可以进行状态保存，并且实际上很难在整个分布式系统的规模上提供有关此状态的保证（即ACID）。因此，在现有数据库系统（MySQL，SQL Server等）的基础上建立了新的级别，以创建一个分布式数据存储级别。

当我在Microsoft的SQL Server团队中担任产品经理时，我不得不处理这种情况。第一个案例与Microsoft内部产品有关。然后该公司创建了Webstore，这是一个基于SQL Server构建的分片层，Hotmail及其相关服务使用了该分片层。实际上，正是由Webstore激励创建了作为当前Azure SQL数据库原型的产品。 Webstore有点笨拙，它缺少关键功能的很大一部分，但是它可以正常工作，并且为Microsoft提供了可扩展到任何所需数据量和高可用性的功能。但是，要创建和进一步支持Webstore，就需要整个工程师团队。

在2000年代中期，MySpace使用了大量的SQL服务器来管理快速增长的站点。该公司的用户群增长如此之快，以至于每天都需要安装新的SQL Server实例。所有这些SQL Server的操作以及对所有这些SQL Server的查询的执行都是如此巨大的复杂性，以至于整个工程师团队也参与其中。
随着所有迅速发展的技术巨头都遇到了扩展问题，在Facebook和其他公司上也重复了类似的故事。

显然，以这样的增长和利用速度，这些新的数字服务需要一种新的解决方案，用于数据吸收，管理及其输出到地面。理想情况下，需要一种解决方案，该解决方案可以提供一个本机界面，但可以在许多计算机上水平扩展，同时具有内置工具来确保高可用性。

结果，大规模的云服务（Google，Facebook，Yahoo，Microsoft等）构建了自己的特殊系统，以满足扩展需求。这些系统是不同的，但是它们具有共同的思想。在下一阶段，使用相同思想的开源系统开始大量发展，因此NoSQL运动兴起。

为了解决Web规模的问题，NoSQL在几个关键指标上与传统数据库有所不同。因此，让我们看看为什么在这里做出这些特定的决定。

性能和构象缺陷最终


有两种架构方法，ACID和BASE。

ACID表示“原子，一致，隔离，耐用”（原子，一致，隔离，耐用）。此范例涵盖了关系数据库中通常提供的所有保证。 ACID确保写入操作将不得不等到数据到达磁盘后，只有在此之后，客户端才会被告知操作已成功完成。另外，如果您真的在乎数据的寿命（即，尽量不要丢失它们），则可以配置数据库，以便写操作可以通过网络继续到其他计算机，并且数据也将被写到磁盘上。 。因此，您可以保证写入的内容始终会准确地写入数据中，但是，在一定程度上会牺牲写入速度。

NoSQL系统的典型BASE架构表示“基本可用，软状态，最终一致”（“基本可用性，不稳定状态和最终一致性”）。一致性最终提供了更快的记录速度，因为应用程序不必等待确认记录已保存的情况。一旦数据存储接受了记录，但即使在数据永久存储在其磁盘或另一台计算机的磁盘上之前，数据库也可以通知应用程序写操作已成功，并且应用程序可以继续进行下一个操作。因此，您可以提高性能，但是，您可能会看到看不到刚刚记录的数据，否则由于某种错误，数据可能会完全丢失。

一致性最终是在争取寿命和数据可用性时可以达成的合理折衷。如果您的业务涉及消费者参与，那么任何延误都会直接影响您的收入（这同样适用于任何内容，社区和商业应用程序）。自然，您将获得最大程度的用户界面响应能力。如果您的任务是扩展规模以服务与该系统竞争的数百万用户，那么任何瓶颈都是您无法接受的。当您在数据库体系结构中实现一致性时，会冒意外丢失某人的帖子或评论的风险，这种风险在这种类型的应用程序中可以接受。

在“长寿与风险”的另一端，则是金融应用。当然，如果您通过ATM进行交易，那么一致性最终将不适合您。同样适用于交易所交易。在这种情况下，仍然会有一些用户只同意最小的延迟（或根本不同意），但不准备接受不会将事务写入磁盘的事实。

因此，从长远来看，我们具有在哪里应用一致性的地方，但是，当然，这不是唯一的解决方案。架构师和数据系统开发人员必须能够选择所需的一致性级别。该选择应取决于使用的细节，而不取决于平台的功能。

试图没有计划就过


尚不清楚为什么在NoSQL运动中决定放弃模式。是的，在NoSQL诞生之初，很难建立一个用于管理分布式元数据的管理器，该管理器将为整个分布式系统中的方案提供支持，并支持诸如添加列之类的操作。因此，架构在此类数据库的最早项目中消失就不足为奇了。但是，没有找到随后重新添加方案的方法，而是决定完全放弃它们。那些指出如果有方案的人的观点是，数据库变得不太灵活。设计一个好的方案是困难的，为此，必须仔细考虑并事先做好一切准备。当情况在迅速变化时（从过去到现在），谁想要将自己囚禁在该计划中。

但这是一个谬论。

实际上，电路的缺乏使工程师受益，工程师的任务是将数据写入系统。但是，在这种情况下，问题被推到了读取数据的人员的手中，并且通常比工程师大一个数量级，并且通常他们不具备有关记录时数据所处环境的信息。通常是用户从数据中获取价值，他们需要尽可能少地处理信息方面的障碍。

我会打个比方。想象一下，图书馆员声称他们厌倦了使用Dewey十进制目录，现在他们只需将书放到地板上的一个大洞里-因为大大简化了图书馆员的工作。有时会发生使用部分结构化数据的情况是适当的，因为有时您无法想象某些数据的形式，或者数据本身太稀疏。但是，如果您真的不了解该数据或数据的来源，或者看起来如何，那么它的用途是什么？

事实是，总会有电路。数据总是对某人有意义。但是，有些人应该花一些时间，并将他们对这种含义的知识嵌入平台中，以便其他人可以使用它之后的数据。如果我们正在处理数据，其中一些数据对于我们来说是可以理解的，而另一部分正在快速变化，则第二部分将落入包含部分结构化信息的列中，然后我们确定随后将根据此部分结构化信息形成哪些列。 15年前，SQL Server和Oracle设法用XML做到了这一点。在如今的MemSQL和其他一些现代数据库中，使用JSON数据完成相同的操作。数据的文档存储（和键值对一起使用）应该是现代数据库的功能，但不是该产品或该产品的唯一可能性。

查询语法与SQL中的语法不同


NoSQL数据库设计中的这一决定遵循了该方案。如果没有架构，则放弃SQL语法似乎是适当的。此外，查询处理器很难为单台计算机编写，但是对于分布式系统则要复杂得多。最值得注意的是，如果您是需要快速启动新应用程序的开发人员，那么这样的新系统似乎更容易。

MongoDB完善了无需经验即可轻松安装和使用的技术。但是，事实证明关系模型非常强大。如果您从未比“选择ID为2的对象”更难解决问题，那么最好与get和put函数相处。但是大多数现有应用程序需要做的更多。如果您想阅读得出此结论的作者的出色文章（并且同时不适用于存储数据的产品），请使用MongoDB制定两个单独的项目-阅读该文章。一个很好的例子，说明何时文档数据库功能受到限制。

在除最琐碎的系统之外的任何系统中，迟早都需要根据与保存数据不同的原理来请求数据。具有讽刺意味的是，关系模型是在1960年代发明的，用于解决与当时存在的数据仓库（IMS和Codasyl）完全相同的问题。提供联接功能的关系模型似乎是提取数据的唯一明智的方法。是的，起初很难，但是比将所有数据提取到应用程序中然后自己创建关联要容易得多。我看到客户尝试使用NoSQL数据库一次又一次地这样做，这总是使他们陷入某种无聊的状态。

这些NoSQL系统中的许多已经实现了其主要目标。他们为数据仓库提供了一个单一的接口，通过它可以依靠内置的高可用性扩展到许多系统。但是，尽管NoSQL一直取得了一些进步，但其实现却一直在停止。

有几种不同的原因。关键原因是性能，尤其是在遵循服务质量协议执行分析查询时。另一个原因是可管理性，因为已知管理分布式系统有多困难。但是，除了对人员进行再培训之外，没有什么阻止NoSQL的广泛采用。在关系数据库领域，许多专家进行了研究并形成了专业的团队。 NoSQL尝试改变世界已有十多年了，但几乎没有取得任何成就。所有使用NoSQL的公司加在一起，只占数据库市场的百分之几，其市场规模为500亿美元。

尽管NoSQL程序员显然很喜欢它，但是数据专家（DBA，数据架构师，分析师）不情愿地进入NoSQL世界，因为似乎只有这种范例才能解决当前的伸缩问题。但是，这意味着他们将不得不重新学习新的API，工具，开发新的生态系统，而放弃了花费大量时间研究成功的方法，模式和资源。他们希望按照熟悉的模型进行工作，但同时又实现了必要的可伸缩性，同时又不放弃系统的耐用性，可用性和可靠性。

再见NoSQL


出现了NoSQL数据库，以便工程师可以应对针对不同订户设计的现代Web应用程序和服务的可伸缩性要求。考虑到解决此类问题有多困难，很明显，首次尝试在数据存储级别进行扩展会迫使客户做出艰难的折衷。

但是，关系数据库已经发展。如今，他们几乎可以应付任何工作负载，满足了现代应用程序对可伸缩性，可靠性和可用性的所有要求。

例如，这涉及诸如工作分析之类的工作负载。由于所有公司都认识到数据驱动方法的价值，因此他们努力为员工提供相关数据。这需要新一代的分析系统，该系统可以扩展到数百个竞争性查询，无需事先聚合即可发出快速查询，并以与生成数据相同的速度吸收数据。最重要的是，您需要向客户和合作伙伴提供数据，为此，您需要遵守服务质量（SLA），安全保证，性能和可伸缩性级别上的某些协议，这对于大多数现代数据仓库来说都是很难的。这是传统遗留数据库无法处理的一种工作负载。没有NoSQL系统。

关系模型经受了时间的考验，并且在创新方面不断增长，例如MemSQL的SingleStore。另外，旧的范例吸收了许多新的数据类型（搜索，空间，半结构化等）和匹配模型，这些模型允许所有这些数据类型共存于同一系统中。关系模型和SQL查询的语法没有不可克服的障碍。它只需要数据仓库的不同实现，就可以使您充分利用垂直可扩展架构的优势。

新数据库（例如MemSQL）证明，在大多数实际情况下，关系数据库比NoSQL系统更易于使用，并且通常表现出更高的性能。

谢谢，NoSQL。您对数据库开发社区施加了必要的压力，这使我们对云世界的挑战给出了有价值的答案。有效。关系数据库开始发展并开始满足现代要求。谢谢你。

More articles:


All Articles