NoSQL和最终的一致性 - 现实世界的例子

jul*_*icz 14 distributed-system nosql

我正在寻找NoSQL应用程序的好例子,它们描述了如何处理缺乏事务性,正如我们在关系数据库中所知道的那样.我最感兴趣的是写密集型代码,因为对于大多数只读代码来说,这是一个更容易的任务.我已经阅读了很多关于NoSQL的内容,关于CAP定理,最终的一致性等等.然而,这些事情往往集中在数据库架构上,而不是与它一起使用的设计模式.我确实理解在分布式应用程序中实现完全事务性是不可能的.这就是为什么我想了解为什么要降低要求以使任务可行的原因.

编辑:

并非最终的一致性是我自己的目标.目前我还没有真正看到如何将NoSQL用于某些写密集型的东西.说:我有一个简单的拍卖系统,有优惠.理论上,接受报价的第一个人获胜.在实践中,我希望至少保证只有一个胜利者,并且人们在同一个请求中得到他们的结果.这可能不可行.但是如何在实践中解决它 - 也许一些请求可能需要比平时更长的时间,因为出了问题.也许一些请求应该自动刷新.这只是一个例子.

Add*_*dys 28

让我用纯粹直观的术语解释CAP.首先,C,A和P是什么意思:

  • 一致性:从外部观察者的角度来看,每个"交易"要么完全完成,要么完全回滚.例如,在进行亚马逊购买时,无论内部分区为子系统,购买确认,订单状态更新,库存减少等都应显示为"同步"

  • 可用性:100%的请求已成功完成.

  • 分区容差:即使系统中的节点子集不可用,也可以完成任何给定的请求.

从系统设计的角度来看,这些意味着什么?CAP定义的紧张是什么?

要达到P,我们需要复制品.很多人!我们保留的副本越多,即使某些节点处于脱机状态,我们所需的任何数据都可用的机会也越大.对于绝对"P",我们应该将每个数据项复制到系统中的每个节点.(显然在现实生活中我们在2,3等方面妥协)

要实现A,我们不需要单点故障.这意味着"主要/次要"或"主/从"复制配置会离开窗口,因为主/主要是单点故障.我们需要使用多个主配置.要实现绝对"A",任何单个副本必须能够独立于其他副本处理读取和写入.(实际上我们在异步,基于队列,仲裁等方面妥协)

为了实现C,我们需要在系统中使用"单一版本的事实".这意味着如果我写入节点A然后立即从节点B读回,则节点B应返回最新值.显然,在真正的分布式多主系统中不会发生这种情况.

那么,你问题的解决方案是什么?可能放松一些约束,并妥协其他约束.

例如,要在具有n个副本的系统中实现"完全写入一致性"保证,读取数和写入数必须大于或等于n:r + w> = n. 这很容易通过一个例子来解释:如果我将每个项目存储在3个副本上,那么我有几个选项来保证一致性:

A)我可以将项目写入所有3个副本,然后从3中的任何一个中读取并确信我正在获取最新版本B)我可以将项目写入其中一个副本,然后阅读所有3个副本并选择3个结果中的最后一个C)我可以写入3个副本中的2个,并从3个副本中的2个中读取,我保证我将在其中一个上有最新版本.

当然,上面的规则假设在此期间没有节点出现故障.为了确保P + C你需要更加偏执......

还存在几乎无限数量的"实现"黑客 - 例如,如果存储层无法写入最小仲裁,则可能会使调用失败,但即使在返回成功后,也可能继续将更新传播到其他节点.或者,它可能会放松语义保证并推动将版本控制冲突合并到业务层的责任(这是亚马逊的Dynamo所做的).

不同的数据子集可以有不同的保证(即单点故障可能对于关键数据是正常的,或者可以阻止写入请求,直到写入副本的最小数量成功写入新版本)

还有更多要讨论的内容,但请告诉我这是否有用,如果您有任何后续问题,我们可以继续...

[继续...]

解决90%案例的模式已经存在,但每个NoSQL解决方案都将它们应用于不同的配置中.这些模式类似于分区(基于稳定/散列或基于变量/查找),冗余和复制,内存缓存,分布式算法(如map/reduce).

当您深入研究这些模式时,底层算法也相当普遍:版本向量,merckle树,DHT,八卦协议等.

大多数SQL解决方案都可以这样说:它们都实现了索引(使用b-trees),具有基于已知CS算法的相对智能的查询优化器,都使用内存缓存来减少磁盘IO.差异主要在于实施,管理经验,工具集支持等

不幸的是,我无法指出一些智慧的中央存储库,其中包含您需要知道的所有信息.一般来说,首先要问自己你真正需要的NoSQL特性.这将指导您在键值存储,文档存储或列存储之间进行选择.(这些是NoSQL产品的3大类).从那里你可以开始比较各种实现.

[再次更新4/14/2011]

好的,这是实际证明赏金的部分..我刚刚在NoSQL系统上找到了以下120页的白皮书.这非常接近我之前告诉你的"NoSQL圣经"不存在.阅读并高兴:-)

NoSQL数据库,Christof Strauch


Gab*_*abe 5

在许多应用程序中,最终一致性都很好。Twitter 就是一个相当著名的例子。您的“推文”没有理由必须立即发送给所有“关注者”。如果您的“推文”需要几秒钟(甚至几分钟?)才能发布,谁会注意到?

如果您想要非 Web 示例,任何存储转发服务(如电子邮件和 USENET)都需要最终一致性。