CAP定理(又名Brewers定理)不能用于单条信息(如一致的数据库).如果您有一个水平扩展的数据库,则无法获得一致性和性能.这个结论来自物理定律,可以从Brewers定理和Einsteins相对论中推导出来.你需要缩小/缩小,而不是缩小.不是很“阴天”,但是如果伽利略的敌人今天还活着就会承认,大自然在尊重人类时尚方面做得很差.

扩展一致的数据

我确信还有其他方法,但Starcounter通过在RAM中托管数据库映像来工作.应用程序代码的一部分移动到数据库,而不是将数据库数据移动到应用程序代码.只有最终响应中的数据才会从RAM内存中的原始位置移动(数据位于第一位).即使每秒处理数百万个请求,这也会使大部分数据保持不变.缺点是数据库需要知道应用程序逻辑的编程语言.但是,如果您曾尝试过数百万个HTTP请求/秒,每个都需要大量数据库访问,那么这一点很明显.

一个更好的答案

问题很好.难怪你发现它很奇怪,因为仅仅几年前CAP被证明了(变成了一个定理).当理论物理学家告诉他停止寻找永动机时,许多开发人员都像小孩一样失望,因为它无法工作.我们仍然希望横向扩展一致的数据库,不是吗？

CAP定理

CAP定理给出了任何信息都不能具有一致性(C),可用性(A)和分区容差(P).它适用于信息单元(例如数据库).您当然可以拥有不同的独立信息.一件可能是AP,另一件可能是CA,第三件可能是CP.你不能将相同的信息作为CAP.

在一致且可用的数据库中不可能出现“P”的问题导致扩展数据库必须如何在节点之间进行信令.结论必须是,即使在一百年后,CAP也只能使用硬线或光束将一条连续数据存储在互连的硬件上.

CAP中P的问题

如果将水平扩展应用于可用的一致数据库,则问题在于性能.一个好的表现是首先进行横向缩放的原因,这是一件非常糟糕的事情.每当有数据库访问以实现一致性时,每个节点都需要与其他节点进行通信,并且鉴于信号最终受到光速的限制这一事实,您将面临数据库科学家(以及cpu科学家)的悲惨但真实的事实. )不仅仅因为没有将横向扩展视为神奇的银弹而感到顽固.它不会发生,因为它不会发生(但是,您的数据库的某些部分可以放在AP集中,所以请记住,我们在这里讨论一致的数据).将爱因斯坦的理论加入到CAP定理中,并将阴天数据中心的小盒子加入以获得一致的数据.

永久机器和CAP

数据库社区中的事物状态有点像永久运动机器的状态,当马和马车是上班的方式.在没有任何理论证据的情况下,专利局为不可能的永久机器授予了数百项专利.今天,我们可能会嘲笑这一点,但我们在数据库行业中有类似的情况,并且具有一致的横向扩展数据库.当你听到有人声称他们有一个横向扩展的ACID数据库时,要小心.只是在麻省理工学院的数学家崩溃之后,数学家才证明布鲁尔在CAP定理的正确出生,所以不幸的是,对不可能的追捕还没有消失.你可以比较一下,如果你愿意的话,就像现代理论物理学应该合理地制止它的那样,laggards一直试图发明永久机器的方式.旧习惯很难过(我向Stack上溢出的人道歉仍然在制作轴承和手臂的图纸,并且他们自己一动不动 – 我不是故意冒犯).

CAP和性能

然而,一切都没有丢失.并非所有信息都需要保持一致.并非所有部分都需要横向扩展.你只需要接受Brewers定理并充分利用它.

对于Facebook等应用程序,会降低一致性.这是可以的,因为数据输入一次然后由单个用户操纵.我们仍然可以在日常的Facebook使用中体验副作用,例如暂时存在和不存在的东西.

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

扩展可用数据的问题在于您必须在没有分区容差的情况下进行操作.这个奇特的单词只意味着您必须始终在云中的节点之间发出信号.并且由于单个仪表需要几纳秒的时间才能运行,如果没有使您的横向扩展导致性能降低而不是提高性能,这将变得不可能.当然,这仅适用于一致的数据. Intel,AMD,Oracle等工程师已经知道这一点的含义.很长一段时间.他们的科学家没有听说过横向扩展.正如爱因斯坦所描述的那样,他们已经接受了这个世界.

在幽暗中有些安慰

如果你进行数学计算,你会发现一台PC上的每一个人都在运行它的每一秒都有指令可供使用(google on’modern cpu’和’MIPS’).如果你做一些更多的数学运算,比如获取Amazon.com的总营业额(你可以在wwww.nasdaq.com找到)除以平均账簿的价格,你会发现销售交易的总数可以适合单个现代PC的RAM.很酷的是,2012年的物品,客户,订单,产品等数量占用的空间与1950年相同.图像,视频和音频的尺寸增加,但数字和文字信息不会增加项目.当然交易数量增加,但与计算机功率增长的阶段不同.因此,逻辑解决方案是扩展只读和AP数据以及“扩展/扩展”业务数据.

“缩小”而不是“向外扩展”

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

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

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

事实证明,磁盘在顺序写入时速度很快,因此搜索磁盘可以保持每兆字节或每分钟更改一次.

Starcounter中的水平缩放

通常,您不会缩放Starcounter节点.它可以扩展而不是扩展.这适用于几百万同时用户.要超越它,您需要添加更多Starcounter节点.它们可用于分区数据(但随后您失去了一致性,Starcounter不是为分区而设计的,因此它不如Volt DB等解决方案那么优雅).因此,更好的选择是使用其他Starcounter节点作为网关服务器.这些服务器一次只能累积所有传入的HTTP请求一毫秒.这可能听起来时间很短,但如果您决定需要扩展Starcounter,则足以积累数千个请求.然后将该批请求一秒一千次地发送到ZLatan节点(零LATency原子节点).每个这样的批处理可以包含数千个请求.通过这种方式,单个ZLatan节点可以提供数亿个用户会话.虽然您可以拥有多个ZLatan节点,但一次只有一个活动的ZLatan节点.这就是CAP定理如何得到尊重.要超越它,你需要考虑与Facebook和其他人相同的权衡.

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

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

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