前言

NoSQL数据库在2012年左右成为 "流行模式"，并引发了一场数据库革命，导致许多企业用基于NoSQL的数据平台取代他们传统的RDBMS技术。

有趣的是，现在这些公司中的许多人要么对他们做的这样决定感到后悔，要么发现，要继续使用他们的NoSQL解决方案，而不花费不合理的金钱或承担不合理的风险，是极其困难的。

很多客户在其他平台上实施了NoSQL，然而最初的解决方案让他们失望，于是来到了Volt Active Data,。在研究了他们的失败原因时，出现了许多共同的因素，最常见的事情之一就是对NoSQL能做什么或不能做什么的某种误解。

让我们回顾一下我们对NoSQL梦想破灭的真实经历。

误解1

我需要NoSQL，是因为SQL很慢

我们已经多次看到这种情况。因为传统的数据库很慢，所以人们倾向于认为是SQL导致了它们的缓慢。

现在我们要清楚：SQL可以很慢。破坏SQL的最简单的方法是在每次向数据库发送SQL语句时都要进行解析，而不是使用 "预备语句"。你也可以在复杂的查询和可疑的执行计划中获得数小时的乐趣。或者，如果你真的想让你的DBA有一个 "充分就业的行为"，可以使用基于成本的优化器。

但是，SQL本身并没有什么内在的缓慢。传统的SQL数据库之所以慢，是因为它们的架构可以追溯到1984年左右，那时你只有一个CPU，最小的RAM，以及一个如果你揭开盖子就可以看到旋转的磁盘。

Volt Active Data是为了解决现代硬件背景下的这个问题而建立的，在同样的硬件下，它的吞吐量是传统RDBMS的10倍左右，因为它是为现代多核CPU编写的。SQL本身并不是问题所在。

我们听到的第二个反对SQL的理由是——"开发人员不喜欢它"。但是正如我们上面指出的，某种形式的模式和结构是需要的，而且随着越来越多的用例得到支持，它将迅速变得更加复杂。这就是人们在NoSQL数据库中加入SQL层的原因。这反过来又让我们回到了如何让SQL快速运行的问题上，这是我们所知道的一两件事情。快速的SQL必须从一开始就被纳入架构。在NoSQL存储中添加一个SQL层，充其量会让你面临你在使用传统RDBMS时想要逃避的那种性能挑战。

围绕着数据库速度，你应该考虑的是：交易的快速运行--即在1到2毫秒内。

​

误解2

我可以直接使用开放源码，获得两方面的好处

管理层喜欢开源NoSQL技术的概念，不是因为他们想为代码库做贡献，而是因为它是'免费'的。

但是，开源软件是 "免费"的，就像给动物园提供一只“免费”大熊猫一样。熊猫本身并没有花费动物园的钱，但维护、照顾和用空运的新鲜竹子喂养肯定要花钱，用量也会迅速增加。实际上，在商业背景下，软件许可证是整个系统运行过程中相关费用和成本的一部分。因此，虽然你可能不花任何钱就能获得软件，但你不可能免费使用它。

一旦你获得了一个软件，你就需要支持它。对于开放源码，我们经常听到员工自愿自己做支持的故事。虽然这对相关人员的简历有好处，但这不一定符合公司的最佳利益。通过内部支持，他们有效地创造了一个要求，即新员工必须具有与原来的内部志愿者相同的高度专业化的技能水平。另一个选择是付钱给支持开源产品的公司来提供支持，在这种情况下，整个 "开源 "的区别就开始变得有点模糊了。

另一个因素是NoSQL数据库的复杂性在增加。随着他们解决更多的功能，他们变得越来越复杂，尤其是当你开始为诸如SQL和ACID事务添加子系统时。

开源的NoSQL数据库还有一个长期的问题。几乎所有成功的数据库现在都已经上市了，经常以令人瞠目结舌的估值上市。这意味着他们未来的开发工作将不可避免地集中在企业功能上，并抓住那些尚未与他们签订协议的企业客户。SSPL的崛起就是这方面的明显证据。

围绕数据库和数据平台的成本，你应该考虑什么。与它所创造的价值相比，技术的长期总成本应该是可预测、可负担的。

​

误解3

我们希望模式具有灵活性，所以我们需要一个无模式的NoSQL数据库

当涉及到定制和灵活性时，传统的关系型数据库是非常无助的。但多亏了JSON，现在无论你使用什么数据平台，都可以更容易地在记录层面添加额外的、自定义的数据。

也就是说，在追求灵活性的过程中，很多开发人员最终放弃了他们处理数据所需的结构。模式层面的灵活性是一把双刃剑，它将复杂性从单一的数据存储副本推向了多个客户端应用程序，所有这些应用程序都必须就自定义数据的含义达成一致。在你追踪的事物上有可选的属性和拒绝说出不同种类的事物之间也有很大的区别。迟早有一天，需要确定关键的数据结构。

虽然在一些合理的情况下，拥有一个非常灵活的模式是非常有帮助的，比如定制。但实际上并不存在真正的 "无模式 "数据库，因为所有的数据至少都有一个高级结构。如果数据真的没有固有的结构，那么你只需要一条记录，那就是一个BLOB，包含与业务有关的一切。

但在现实中，你与不同种类的 "事物 "打交道，这些 "事物 "具有相同的属性集，而且这些事物与其他事物相关。因此，你的数据总是有一个结构，即使它的各个组成部分有独特的属性。

事实上，任何一种自动化的数据处理都以工作结构为前提。你可以在模式内拥有无模式的区域，但这需要在更广泛的企业模式的背景下进行。

围绕模式的灵活性，应该考虑的是：有能力用任意的额外数据（即JSON）扩展记录，并为这些记录建立索引。

误解4

我需要一个NoSQL键值存储，因为我们不希望我们的服务器做应用逻辑

在我们见过的所有古怪的要求中，这在某种程度上是最奇怪的。它似乎是对使用3GL SQL操作语言（如PL/SQL）所带来的无可争辩的麻烦、苦难和痛苦的一种反应。它通常与上述要求同时出现，即服务器支持完全无模式的存储。

他们的想法是，因为一般的存储过程，特别是PL/SQL，处理起来很痛苦，所以未来与数据库的所有交互都应该限于 "获取 "和

"投放 "操作。作为一个曾经的PL/SQL开发者，我可以同情这种做法，但试图避免这种做法会产生其他更糟糕的问题。

如果处理的是一个简单的用例，对一个键/值进行一次读取，然后再进行写入修改，那么虽然可能会遇到争用和乐观锁定的问题，但事情或多或少都会正常。

当你需要读取和改变多个键，例如 "A"、"B "和 "C "时，问题就开始了。如果你按顺序读取和改变它们，你会面临两个主要问题：

1. 有人可能在你读完A后，在你读C前改变A，导致错误的结果。
2. 在依次写入'A'、'B'和'C'之前，依次读取它们所花费的时间会影响你的SLA。

简而言之，有一个用例的子集，需要在一个步骤中读取和修改一组相关的值，或者在出错时写很多很多的代码来清理事情。

NoSQL处理这个问题方式比较糟糕，要么是把工作转嫁给开发人员，要么是实现与使用传统RDBMS时让我们发疯的那种笨重的锁定技术。

围绕一致性和逻辑，你应该考虑什么。能够处理涉及多个数据项的复杂事务，而不必担心读取一致性或清理代码。

​

误解5

我们今天只需要一个简单的NoSQL数据存储，所以我们可以这样做，并在其他时间担心未来的复杂性

敏捷开发一般来说是件好事，但我们看到的情况是，重点已经从专注于通过每次快速迭代为客户增加价值，变成了奇怪的、故意拒绝为未来做计划的状态。仅因第一个版本有一个简单的模式，并不意味着你在未来不需要一个功能更全面的数据平台，而且改变数据平台可能是非常昂贵的。

未来对地理复制的要求就是一个典型的例子。像我们的​​Active(N)​​这样可信的地理复制数据平台是很罕见的。在应用层面上对成品进行地理复制的改造是一场噩梦，经常导致完全重写。这就像建造一辆飞行汽车和让现有的汽车飞起来之间的区别。

即使你使用一个具有地理复制能力的数据平台，你仍然需要一个很好的计划来解决应用层面的冲突，而这样的系统会带来巨大的操作挑战。

地理复制只是这种现象的一个例子。底线是，在定义需求时，如果只盯着眼前的问题，而不考虑长期的需求，将会很灾难。

围绕复杂性，应该考虑——挑选一个能满足长期需求的产品，同时也要充分了解它是如何做到的，以及它是如何影响架构选择和总成本的。

​

总结

每个人的情况都不一样，在Volt Active Data，我们并不声称我们的产品是一个神奇的、通用的数据平台，可以满足你所有的需求。在我们与你交谈之前，我们不知道Volt Active Data是否适用于你。

但我们确实看到，从传统的RDBMS到NoSQL的转变出了问题，因为人们使用的需求乍看之下是合理的，在深入了解后，会发现这些需求既简单又与企业的长期目标脱节。

如果你正在从传统的RDBMS迁移，或者有一个新实施的NoSQL解决方案让你失望，因为它不能满足你对规模、速度或交易的需求，请随时与我们交流。我们非常肯定，我们至少可以引导你走向正确的方向。

如果您希望集成VOLT到您的技术栈中，请与我们联系！

​​ Volt Active Data中文站​​

sgao@voltactivedata.com