为什么NoSQL比RDBMS更好地“扩展”？

Question

我在technical blog中阅读了以下文本，讨论了NoSQL的优点和缺点

“多年来，为了提高数据库服务器的性能，数据库管理员不得不在数据库负载增加（扩展）时购买更大的服务器，而不是随着负载的增加（扩展）将数据库分布在多个”主机“上.RDBMS通常不会轻易扩展，但较新的NoSQL数据库实际上旨在轻松扩展以利用新节点，并且通常在设计时考虑到低成本的商用硬件。“

我对RDBMS和NoSQL的可扩展性感到困惑。

我的困惑是：

1. 为什么RDBMS不能扩展？而购买更大的服务器而不是购买更便宜的服务器的原因。
2. 为什么NoSQL更能扩展？

Answer 1

RDBMS具有ACID（http://en.wikipedia.org/wiki/ACID）并支持事务。由于这些概念，使用RDBMS扩展“out”更难实现。

NoSQL解决方案通常提供记录级别的原子性，但不能保证一系列操作会成功（事务）。

它归结为：为了保持数据完整性和支持事务，多服务器RDBMS需要有一个快速的后端通信通道来同步所有可能的事务和写入，同时防止/处理死锁。

这就是为什么你通常只看到1个主（作者）和多个奴隶（读者）。

Answer 2

所以我一直试图找出真正的底线，当谈到NoSQL vs RDBMS时，我总是得到一个并没有完全削减它的响应。在我的搜索中，NoSQL和SQL之间确实存在两个主要区别，只有1个是真正的优势。

1. ACID vs BASE - NoSQL通常会遗漏SQL的一些ACID功能，通过将这一抽象层留给程序员来“欺骗”它以获得更高的性能。以前的海报已经涵盖了这一点。
2. 水平缩放 - NoSQL的真正优势是水平缩放，即分片。考虑到NoSQL'文档'是一种“自包含”对象，对象可以位于不同的服务器上，而不必担心从多个服务器加入行，就像关系模型的情况一样。

假设我们想要返回一个这样的对象：

post {
    id: 1
    title: 'My post'
    content: 'The content'
    comments: {
      comment: {
        id: 1
      }
      comment: {
        id: 2
      }
      ...

    views: {
      view: {
        user: 1
      }
      view: {
        user: 2
      }
      ...
    }
}

在NoSQL中，该对象基本上将按原样存储，因此可以作为一种自包含对象驻留在单个服务器上，而无需与可能驻留在其他数据库服务器上的其他表的数据连接。

但是，对于Relational DB，帖子需要加入来自comments表的注释，以及来自views表的视图。这在SQL中不会成为问题~UNTIL~将数据库分解为分片，在这种情况下，“注释1”可以在一个数据库服务器上，而“注释2”在另一个数据库服务器上。这使得在水平扩展的RDBMS中创建与NoSQL DB中相同的对象变得更加困难。

是否有任何数据库专家确认或争论这些观点？

Answer 3

典型的RDBMS对一致性提出了强有力的保证。这需要在每个事务的节点之间进行一些扩展通信。这限制了向外扩展的能力，因为更多节点意味着更多的通信

NoSql系统做出了不同的权衡。例如，他们不保证第二个会话将立即看到第一个会话提交的数据。从而将存储一些数据的事务与使每个用户可用的数据的过程分离。谷歌“最终一致”。因此，单个事务不需要等待任何（或更少）节点间通信。因此，他们能够更容易地利用大量节点。

Answer 4

在RDBMS中，当数据变得庞大时，可能会发生表分布在多个系统中，在这种情况下，执行JOIN等操作非常慢。

在NoSQL的情况下，通常相关数据一起存储在同一台机器上（在单个文档中 - 在面向文档的数据库中或在宽列数据存储的情况下，相关列在同一台机器上）。因此很容易在许多低端机器上扩展，显然在这种情况下会在多个地方出现重复数据，而RDBMS则不然。

Answer 5

对于NO SQL，1。与集合相关的所有子节点位于同一位置，因此在同一服务器上，并且没有连接操作来从另一个服务器查找数据。

2.没有架构，因此任何服务器上都不需要锁，并且事务处理留给客户端。

以上2节省了大量的NO-SQL扩展开销。