我一直在阅读一个名为Starcounter的数据库。它声称它可以处理“NoSql”数据库只能处理而不会降低一致性的负载。据我所知，CAP定理，如果保持一致性，就会失去可用性或分区容忍度。那么StarCounter的作用是什么？
我可以想象StarCounter速度很快，但NoSql需要降低一致性以保持同步的说法对我来说似乎有点奇怪。有人可以解释一下吗？
提前致谢 罗兰
答案 0 :(得分：14)
CAP定理（又名Brewers定理）不能为单条信息（如一致的数据库）打败。如果您有一个水平扩展的数据库，则无法获得一致性 和 的性能。这个结论来自物理定律，可以从Brewers定理和Einsteins相对论中推导出来。你需要缩小/缩小，而不是缩小。不是很多＆＃34;多云＆＃34;但是如果伽利略的敌人可能会承认如果他们今天还活着，大自然在尊重人类时尚方面做得很差。
我确定还有其他方法，但Starcounter通过在RAM中托管数据库映像来工作。应用程序代码的一部分移动到数据库，而不是将数据库数据移动到应用程序代码。只有最终响应中的数据才会从RAM内存中的原始位置移动（数据位于第一位）。即使每秒处理数百万个请求，这也会使大部分数据保持不变。缺点是数据库需要知道应用程序逻辑的编程语言。但是，如果您曾尝试提供数百万个HTTP请求/秒，每个都需要大量数据库访问，那么这一点很明显。
这个问题很好。难怪你发现它很奇怪，因为仅仅几年前CAP被证明了（变成了一个定理）。当理论物理学家告诉他停止寻找永动机时，许多开发人员都像小孩一样失望，因为它无法工作。我们仍然想要横向扩展一致的数据库，不是吗？
CAP定理给出了任何信息都不能具有一致性（C），可用性（A）和分区容差（P）。它适用于信息单元（例如数据库）。您当然可以拥有不同的独立信息。一件可能是AP，另一件可能是CA，第三件可能是CP。你不能将相同的信息作为CAP。
P＆＃39; P＆＃39;不可能出现的问题。在一致且可用的数据库中，结果是扩展数据库必须如何在节点之间进行信令。结论必须是，即使在一百年后，CAP也会使用硬线或光束连接硬件上的单个数据。
如果将水平扩展应用于可用的一致数据库，则问题在于性能。一个好的表现是首先进行横向缩放的原因，这是一件非常糟糕的事情。由于每当有数据库访问以实现一致性时，每个节点都需要与其他节点进行通信，并且鉴于信号最终受到光速的限制这一事实，您将面临数据库科学家（以及CPU科学家）的悲惨但真实的事实。 ）不仅仅因为没有将横向扩展视为神奇的银弹而感到顽固。它不会发生，因为它不会发生（但是，您的数据库的某些部分可以放在AP集中，所以请记住，我们在这里谈论的是一致的数据）。将爱因斯坦的理论加入到CAP定理中，并将阴天数据中心的小盒子用于一致的数据。
数据库社区中的状态有点像永久运动机器的状态，当马和马车是上班的方式。在没有任何理论证据的情况下，专利局为不可能的永久机器授予了数百项专利。今天，我们可能会嘲笑这一点，但我们在数据库行业中也存在类似的情况，并且具有一致的横向扩展数据库。当你听到有人声称他们有一个横向扩展的ACID数据库时，要小心。只是在麻省理工学院的数据学家崩溃后，数学家才证明布鲁尔在CAP定理中的正确出生，所以不幸的是，对不可能的事情的追捕还没有消失。如果你愿意的话，你可以比较一下，在现代理论物理应该合理地制止它之后，laggards一直试图发明永久机器的方式。旧习惯很难过（我向Stack上溢出的人道歉仍然在制作轴承和手臂的图纸，并且他们自己一动不动 - 我不是故意冒犯）。
对于Facebook等应用程序，会降低一致性。这是可以的，因为数据输入一次然后由单个用户操纵。我们仍然可以在日常的Facebook使用中体验副作用，例如暂时存在和不存在的东西。
但是，在大多数业务应用程序中，数据需要正确。您的簿记中所有帐户的总和需要达到零。如果您出售10个项目中的2个，即使有多个用户从同一个股票购买，您的库存也必须等于8。
扩展可用数据的问题在于您必须在没有分区容差的情况下做到这一点。这个奇特的单词只意味着您必须始终在云中的节点之间发出信号。并且由于单个仪表需要几纳秒的时间才能运行，如果没有使您的横向扩展导致性能降低而不是提高性能，这将变得不可能。当然，这仅适用于一致的数据。英特尔，AMD，甲骨文等公司的工程师都知道这一点的含义。很长一段时间。他们的科学家并没有听说过横向扩展。正如爱因斯坦所描述的那样，他们已经接受了这个世界。
如果你进行数学计算，你会发现一台PC上的每一个人都有关于每一个人正在运行的每一个人的指令（google on＆＃39;现代CPU＆＃39;以及＆＃39; MIPS＆ ＃39）。如果你做一些更多的数学运算，比如拿Amazon.com的总营业额（你可以在wwww.nasdaq.com找到它）除以平均账簿的价格，你会发现销售交易的总数可以适合单个现代PC的RAM。很酷的是，2012年的物品，客户，订单，产品等数量占用的空间与1950年相同。图像，视频和音频的尺寸增加，但数字和文字信息不会增长项目。当然，交易数量会增加，但与计算机功率增长的阶段不同。因此，合理的解决方案是扩展只读和AP数据以及＆＃34;缩放/扩展＆＃34;业务数据。
在VM中运行的数据库引擎和业务逻辑（如Java VM或.NET CLR）通常使用相当有效的机器代码。这意味着移动内存是一致数据库总吞吐量的黯然失色瓶颈。这通常被称为记忆墙（维基百科有一些有用的信息）。
诀窍是将代码传输到数据库映像而不是将数据从数据库映像传输到代码（如果使用MVC或MVVM模式）。这意味着消费代码在与数据库映像相同的地址空间中执行，并且数据永远不会被移动（并且磁盘仅仅保护事务和映像）。数据可以保留在原始数据库映像中，而不必复制到应用程序的内存中。数据库不是将数据库视为RAM数据库，而是将其视为主存储器。一切都保持不变。
只有属于最终用户响应的数据才会移出数据库映像。对于具有数亿个并发用户的大规模应用程序而言，这通常仅相当于每秒几百万个请求，因为只要HTTP封装在网关服务器上完成，单个PC就没有处理问题。幸运的是，这些服务器可以很好地扩展，因为它们不需要共享数据。
事实证明，磁盘在顺序写入时速度很快，因此搜索到的磁盘可以保持太字节或每分钟更改一次。
通常，您不会缩放Starcounter节点。它可以扩展而不是扩展。这适用于几百万同时用户。要超越它，您需要添加更多Starcounter节点。它们可用于对数据进行分区（但随后会失去一致性，而Starcounter不是为分区而设计的，因此它不如Volt DB等解决方案那么优雅）。因此，更好的选择是将其他Starcounter节点用作网关服务器。这些服务器一次只能累积所有传入的HTTP请求一毫秒。这可能听起来像是一个短暂的时间，但如果你决定需要扩展Starcounter，它就足以累积成千上万的请求。然后，该批请求被发送到ZLATAN节点（零LATency原子节点）每秒一千次。每个这样的批处理可以包含数千个请求。通过这种方式，单个ZLATAN节点可以提供几亿个用户会话。虽然您可以拥有多个ZLATAN节点，但一次只能有一个活动的ZLATAN节点。这就是CAP定理如何得到尊重。要超越它，你需要考虑与Facebook和其他人相同的权衡。
另一个重要的注意事项是ZLATAN节点不为数据应用程序提供服务。相反，应用程序控制器代码由ZLATAN节点运行。序列化/反序列化和向应用程序发送数据的成本远远大于处理控制器逻辑周期的成本。即代码被发送到数据库而不是相反（传统的方法是应用程序请求数据或发送数据）。
将数据库用作＆＃34;堆＆＃34;对于编程语言而不是远程系统进行序列化和反序列化是Starcounter调用VMDBMS的一个技巧。如果数据库在RAM中，则不应将数据从RAM中的一个位置移动到RAM中的另一个位置，大多数RAM数据库就是这种情况。
答案 1 :(得分：0)
没有'技巧'。 Starcounter正在谈论速度，而CAP / NoSQL正在谈论可扩展性。功能+可扩展性与速度之间存在权衡。
如果能证明其他地方存在瓶颈，有时可以忽略可扩展性。例如，一个新的创业公司不应该担心他们的网站扩展到一百万用户，他们应该担心获得他们的前百名用户。 （有没有人记得Twitter早期的频率有多低？）如果他们的交易率远高于你的网页命中率，那么Starcounter会很有用。
另一方面，我不相信任何将所有“NoSQL”数据库整合在一起的人。各种NoSQL数据库的不同之处。它们具有完全不同的架构和属性。其中一些节点可扩展到数千个节点，其中一些节点不能扩展到一个节点以外。有时添加可伸缩性会降低您的速度。有时删除功能会加快你的速度。
http://strata.oreilly.com/2010/12/strata-gems-mysql-handlersocket.html