cap - 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定理和多云数据中心的小盒子胜利中，以获得一致的数据。

永动机和CAP

数据库社区中的事物状态有点像永动机的状态，当时马和马车是上班的方式。没有任何理论依据，专利局为不可能的永久机器授予了数百项专利。今天，我们可能会对此大笑，但在数据库行业中，如果使用一致的横向扩展数据库，情况也将类似。当您听到有人声称他们拥有横向扩展ACID数据库时，请保持谨慎。只是在麻省理工学院的互联网泡沫破裂数学家证明CAP定理正确的Brewer诞生之后，不幸的是，对不可能的追捕还没有消亡。如果需要，您可以将其与落后者在现代理论物理学合理地制止该机器多年后一直试图发明该永久机器的方式进行比较。旧习惯很难消亡（我向Stack Overflow上的任何人致歉，仍然使轴承和手臂按照自己的意愿移动ad的图形-我并不是要冒犯他人）。

CAP和性能

但是，一切并没有丢失。并非所有信息都需要保持一致。并非所有部分都需要横向扩展。您只要拥有公认的Brewers定理，并充分利用它即可。

对于Facebook之类的应用程序，一致性会下降。没关系，因为只输入一次数据，然后由单个用户操作即可。尽管如此，我们仍可以体验Facebook日常使用中的副作用，例如事物突然出现和消失的情况。

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

扩展可用数据的问题在于您必须在没有分区容忍的情况下进行工作。这个花哨的词只是意味着您必须始终在云中的节点之间发出信号。而且，由于移动一米需要花费几纳秒的时间，因此如果不进行横向扩展会导致性能降低而不是性能提高，这将成为不可能。当然，这仅适用于一致的数据。英特尔，AMD，甲骨文等的工程师已经知道了这一点。长时间。并不是他们的科学家没有听说过横向扩展。正如爱因斯坦所描述的那样，只是他们开始接受世界。

忧郁中有些安慰

如果您进行数学计算，您会发现一台PC上有指令，可以让每一个人在地球上运行的每一秒钟都免于痛苦（使用“现代CPU”和“ MIPS”的Google）。如果您做更多的数学运算，例如将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节点（零LATency Atomicity节点）。每个这样的批次可以包含数千个请求。这样，单个ZLATAN节点可以为几亿个用户会话提供服务。尽管您可以有多个ZLATAN节点，但是一次只有一个活动的ZLATAN节点。这就是兑现CAP定理的方式。为此，您需要考虑与Facebook和其他人相同的权衡。

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

通过减少工作量来使“共享的一切”节点更快

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