nosql - StarCounter 和 CAP

Question

我一直在阅读一个名为 Starcounter 的数据库。它声称它可以处理“NoSql”数据库只能处理的负载，而不会降低一致性。据我了解 CAP 定理，如果您保持一致性，您将失去可用性或分区容错性。那么 StarCounter 的工作原理是什么？

我可以想象 StarCounter 很快，但是 NoSql 需要降低一致性才能跟上的说法对我来说似乎有点奇怪。谁能解释一下？

提前感谢罗兰

Answer 1

简短的回答

CAP 定理（又名 Brewers 定理）不能因单一信息（如一致的数据库）而被击败。如果您有一个水平扩展的数据库，您将无法获得一致性和性能。这个结论来自物理定律，可以从布鲁斯定理和爱因斯坦的相对论中推导出来。您需要扩大/扩大，而不是扩大。不是很“多云”，但如果伽利略的敌人今天还活着，他们可能会承认，大自然在尊重人类时尚方面做得很差。

缩放一致的数据

我确信还有其他方法，但 Starcounter 通过将数据库映像托管在 RAM 中来工作。不是将数据库数据移动到应用程序代码，而是将部分应用程序代码移动到数据库中。只有最终响应中的数据从 RAM 内存中的原始位置（数据最初所在的位置）移动。即使每秒处理数百万个请求，这也使得大部分数据保持不变。缺点是数据库需要了解应用程序逻辑的编程语言。但是，如果您曾经尝试过每秒处理数百万个 HTTP 请求，每个请求都需要大量的数据库访问，那么好处是显而易见的。

---

一个更彻底的答案

这个问题很好。难怪你会觉得奇怪，因为仅仅几年前 CAP 才被证明（变成了一个定理）。当理论物理学家告诉他停止寻找永动机，因为它无法工作时，许多开发人员就像孩子一样失望。我们仍然想要横向扩展的一致数据库，不是吗？

CAP 定理

CAP 定理给出了任何一条信息都不能具有一致性（C）、可用性（A）和分区容限（P）。它适用于信息单元（例如数据库）。当然，您可以拥有运行方式不同的独立信息。一件可以是AP，另一件可以是CA，第三件可以是CP。您只是不能拥有相同的信息作为 CAP。

在一致且可用的数据库中不可能出现“P”的问题导致横向扩展的数据库必须如何在节点之间进行信令。结论必须是，即使在一百年后，CAP 也认为单个一致的数据必须存在于使用硬线或光束互连的硬件上。

CAP中P的问题

如果您将水平缩放应用于可用的一致数据库，则问题在于性能。良好的性能是首先进行水平缩放的原因，这是一件非常糟糕的事情。由于每个节点都需要在访问数据库时与其他节点进行通信以实现一致性，并且考虑到信号最终受到光速的限制，您会留下一个可悲但真实的事实，即数据库科学家（以及 CPU 科学家） ) 不仅仅是因为未能将横向扩展视为神奇的银弹而固执己见。它不会发生，因为它不可能发生（但是，您的数据库的一部分可以放在 AP 集中，所以请记住，我们在这里讨论的是一致的数据）。

永动机和 CAP

数据库社区的情况有点像永动机的状态，当时马和马车是上班的方式。在没有任何反对它的理论证据的情况下，专利局为不可能的永动机授予了数百项专利。今天，我们可能会对此一笑置之，但我们在数据库行业也有类似的情况，一致的横向扩展数据库。当你听到有人声称他们有一个横向扩展的 ACID 数据库时，要小心。直到麻省理工学院的网络崩溃数学家证明布鲁尔在 CAP 定理上的正确性才正式诞生，所以不幸的是，寻找不可能的事情还没有结束。你可以比较一下，如果你愿意，在现代理论物理学理应阻止它之后，落后者多年来一直试图发明永动机。旧习惯很难改掉（我向 Stack Overflow 上的任何人道歉，他们仍在自行绘制轴承和手臂无限移动的图纸——我并不是要冒犯他人）。

CAP 和性能

然而，一切都没有丢失。并非所有信息都需要保持一致。并非所有部分都需要横向扩展。您只需接受布鲁斯定理并充分利用它。

对于 Facebook 等应用程序，一致性被丢弃了。这没关系，因为数据输入一次，然后由单个用户操作。我们仍然可以体验 Facebook 日常使用中的副作用，例如一段时间内突然出现和消失的东西。

但是，在大多数业务应用程序中，数据需要正确。您的簿记中所有帐户的总和必须为零。如果您售出 10 件商品中的 2 件，即使有多个用户从同一库存中购买，您的库存也必须等于 8。

横向扩展可用数据的问题是您必须在没有分区容差的情况下勉强凑合。这个花哨的词只是意味着您必须始终在云中的节点之间发出信号。而且，由于光传播一米需要几纳秒，如果不使您的横向扩展导致性能降低而不是提高性能，这将变得不可能。当然，这仅适用于一致的数据。英特尔、AMD、甲骨文等公司的工程师已经知道这一点的含义。很长一段时间。不是他们的科学家没有听说过横向扩展。只是他们已经开始接受爱因斯坦所描述的世界。

阴霾中的一些安慰

如果您进行数学计算，您会发现单台 PC 在其运行的每一秒内都有备用指令用于地球上的每个人（谷歌上的“现代 CPU”和“MIPS”）。如果你再做一些数学运算，比如用 Amazon.com 的总营业额（你可以在 wwww.nasdaq.com 上找到）除以一本书的平均价格，你会发现销售交易的总数可以计算在内单个现代 PC 的 RAM。很酷的是，2012 年物品、客户、订单、产品等的数量与 1950 年占据的空间相同。图像、视频和音频的大小增加了，但数字和文本信息并没有随着时间的推移而增加物品。当然交易数量会增加，但不会与计算机能力的增长处于同一阶段。所以合乎逻辑的解决方案是横向扩展只读和 AP 数据并“纵向扩展/纵向扩展”

“缩小”而不是“扩大”

在 VM（如 Java VM 或 .NET CLR）中运行的数据库引擎和业务逻辑通常使用相当有效的机器代码。这意味着移动内存是一致数据库总吞吐量的巨大瓶颈。这通常被称为记忆墙（维基百科有一些有用的信息）。

诀窍是将代码传输到数据库映像，而不是将数据从数据库映像传输到代码（如果使用 MVC 或 MVVM 模式）。这意味着消费代码在与数据库映像相同的地址空间中执行，并且数据永远不会移动（并且磁盘只是保护事务和映像）。数据可以保留在原始数据库映像中，而不必复制到应用程序的内存中。不是将数据库视为 RAM 数据库，而是将数据库视为主内存。一切都保持不变。

只有属于最终用户响应的一部分的数据才会从数据库映像中移出。对于具有数亿同时用户的大规模应用程序，这通常相当于每秒只有几百万个请求，鉴于 HTTP 打包是在网关服务器上完成的，单台 PC 处理这些请求是没有问题的。幸运的是，这样的服务器可以很好地扩展，因为它们不需要共享数据。

事实证明，磁盘在顺序写入时速度很快，因此经过突袭的磁盘可以保持 TB 级或每分钟更改一次。

Starcounter中的水平缩放

通常您不会缩放 Starcounter 节点。它缩小而不是缩小。这适用于几百万同时用户。要超过这个，您需要添加更多 Starcounter 节点。它们可用于对数据进行分区（但随后您会失去一致性，并且 Starcounter 不是为分区而设计的，因此它不如 Volt DB 等解决方案优雅）。所以更好的选择是使用额外的 Starcounter 节点作为网关服务器。这些服务器简单地将所有传入的 HTTP 请求一次累积一毫秒。这听起来像是很短的时间，但如果您决定需要扩展 Starcounter，那么累积数千个请求就足够了。然后，这批请求以每秒一千次的速度发送到 ZLATAN 节点（零延迟原子性节点）。每个这样的批次可以包含数千个请求。这样，一个 ZLATAN 节点可以服务数亿用户会话。虽然您可以拥有多个 ZLATAN 节点，但一次只有一个活动的 ZLATAN 节点。这就是 CAP 定理的兑现方式。要超越这一点，您需要考虑与 Facebook 和其他公司相同的权衡。

另一个重要的注意事项是 ZLATAN 节点不为应用程序提供数据。相反，应用程序控制器代码由 ZLATAN 节点运行。序列化/反序列化和向应用程序发送数据的成本远远大于处理控制器逻辑周期的成本。即代码被发送到数据库而不是相反（传统的方法是应用程序请求数据或发送数据）。

通过少做事使“共享一切”节点更快

使用数据库作为编程语言的“堆”而不是远程系统进行序列化和反序列化是 Starcounter 称之为 VMDBMS 的技巧。如果数据库在 RAM 中，则不应将数据从 RAM 中的一个位置移动到 RAM 中的另一个位置，大多数 RAM 数据库都是这种情况。

Answer 2

没有“技巧”。Starcounter 谈论的是速度，而 CAP/NoSQL 谈论的是可扩展性。功能+可扩展性与速度之间存在权衡。

如果您能证明其他地方存在瓶颈，有时可以忽略可扩展性。例如，一家新创业公司不应该担心他们的网站扩展到一百万用户，他们应该担心获得前一百名用户。（有人记得早期 Twitter 的宕机频率吗？）如果他们的交易率远高于您的网页点击率，Starcounter 会很有用。

另一方面，我不相信任何将所有“NoSQL”数据库混为一谈的人。各种 NoSQL 数据库的不同之处多于同类。它们具有完全不同的架构和属性。其中一些扩展到数千个节点，其中一些不会扩展到超过一个节点。有时增加可扩展性会减慢您的速度。有时删除功能会加快您的速度。

http://strata.oreilly.com/2010/12/strata-gems-mysql-handlersocket.html