使用NoSQL对非分布式系统有意义吗？(试图理解最终的一致性)

Question

在过去的两天里,我一直在阅读和学习NoSQL和MongoDB,CouchDB等,但我仍然无法判断这是否适合我.

让我担心的是最终的一致性.在使用集群时,这种一致性是否只会起作用？(我在一个专用服务器上托管我的网站,所以我不知道我是否可以从NoSQL中受益)对于哪种应用程序可以最终保持一致(而不是ACID),以及哪些应用程序不是T' 你能举个例子吗？在应用程序中可能发生的最糟糕的事情是什么,以确保最终的一致性？

我读到的另一件事是MongoDB在内存中保留了很多东西.在文档中,它描述了一些有2GB数据限制的32位系统.那是因为32位系统的ram限制吗？

Answer 1

我只能说CouchDB,但没有必要在最终一致性和ACID之间做出选择,它们不属于同一类别.

CouchDB完全是ACID.文档更新是原子的,一致的,隔离的和持久的(使用CouchDB建议的delayed_commits = false的生产设置,在返回201成功代码之前,您的更新将刷新到磁盘).CouchDB 没有提供的是多项交易(因为当项目存储在不同的服务器中时,这些交易非常难以扩展)."交易"和"ACID"之间的混淆是令人遗憾的,但由于典型的RDBMS通常同时支持这两者,因此是可以原谅的.

最终的一致性是关于数据库副本如何聚合在同一数据集上.考虑传统RDBMS中的主从设置.该关系的一些配置将使用分布式事务机制,使得主服务器和从服务器始终处于锁定步骤.但是,出于性能原因,通常会放松它.主设备可以在本地进行交易,然后通过交易日志将它们懒洋洋地转发给奴隶.这也是"最终一致性",当日志完全耗尽时,两台服务器将汇聚在同一数据集上.CouchDB更进一步,消除了主设备和从设备之间的区别.也就是说,CouchDB服务器可以被视为相等的对等体,任何主机上的更改都可以正确地复制到其他主机.

最终一致性的技巧是如何处理不同主机上相同项目的更新.在CouchDB中,这些单独的更新在同一项上被检测为"冲突",并且复制可确保所有主机上都存在所有冲突更新.然后CouchDB选择其中一个作为当前版本.可以通过删除不想保留的冲突来修改此选择.