Question

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

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

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

我的困惑是：

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

Answer 1

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

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

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

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

Answer 2

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

ACID vs BASE - NoSQL通常会遗漏SQL的一些ACID功能，通过将这一抽象层留给程序员来“欺骗”它以获得更高的性能。以前的海报已经涵盖了这一点。
水平缩放 - 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

为什么 NoSQL 数据库比 SQL 数据库更容易横向扩展？我一直在试图弄清楚为什么人们总是这么说。我遇到了许多文章，这些文章只是让我对它们非行业熟悉的术语和模糊的假设感到困惑。我建议您阅读 Martin Kleppman 的《设计数据密集型应用程序》。另外，我将分享我对这个主题的一些理解。

JOINS - 在多对一或多对多关系的情况下，迄今为止发明的任何数据库都无法将数据保存在一个表或文档中，因此如果数据被分片（或分区），无论是 SQL 还是 NoSQL，延迟都是一样的，数据库必须查找这两个文档。 NoSQL 似乎只在一对多关系的情况下占主导地位。例如：

NoSql

学生

{
  "name": "manvendra",
  "education": [
    {
      "id": 1,
      "Degree": "High School"
    },
    {
      "id": 2,
      "Degree": "B.Tech"
    }
  ]
}

教育学院合集

[
  {
    "id": "1",
    "name": "army public school"
  },
  {
    "id": "2",
    "name": "ABES Engineering College"
  }
]

Sql

学生桌

id | name        
1  | Manvendra

教育学院

id | Name
1  | Army public school
2  | ABES Engineering college

学习表

student  | education institute | degree
1        | 1                   | high school
1        | 2                   | B.tech

现在假设在 NoSql 的情况下，如果两个集合的数据都在不同的节点上，那么解析教育机构的 id 需要一些额外的时间，这种情况与 SQL 数据库的情况类似，那么好处在哪里？我想不出任何。

此外，您一定在想为什么我们不能将教育机构信息也存储在同一个学生集合中，那么它会像：

{
  "name": "manvendra",
  "education": [
    {
      "name": "Army public school",
      "Degree": "High School"
    },
    {
      "name": "ABES Engineering College",
      "Degree": "B.Tech"
    }
  ]
}

这真的是一个糟糕的设计，因为学生和教育机构之间是多对多的关系，很多学生可能是从同一所学校学习的，所以明天如果学校的名称或任何信息发生变化它在所有地方都将是一个非常艰难的挑战。

但是，在一对多关系的情况下，我们可以将所有信息放在一起，例如：考虑一个客户和一个订单的关系

{
  "name": "manvendra",
  "order": [
    {
      "item": "kindle",
      "price": "7999"
    },
    {
      "item":"iphone 12",
      "price":"too much"
    }
  ]
}

由于订单只属于一个客户，因此将订单信息存储在一个地方是有意义的，但是无论如何存储项目 ID 或名称是另一种选择，如果我们在这里使用 SQL 数据库，将会有两个包含订单和客户的表如果数据没有存储在同一节点中，则查询结果不会很好。

因此在争论中说为什么 NoSql 数据库更容易横向扩展是没有意义的。

交易

SQL（Postgres、MySQL 等）和 NoSQL（MongoDB、Amazon 的 DynamoDB 等）都支持事务，因此无需讨论。

酸

ACID 就像 CAP 一样被过度使用，实际上它只是向客户端显示单个数据副本，而不是实际上可能有多个数据副本（以提高可用性、容错性等）以及数据库使用什么策略去做。例如，在 Postgres 的主从分布式系统的情况下，可以选择同步或异步复制，并且可以使用 WAL（预写日志）进行复制，MongoDB 也是如此，只是代替了 WAL 它有 oplog(Operations Log)，都支持流式复制和故障转移。那么区别在哪里呢？实际上，我找不到一个非常有力的理由来说明为什么 NoSql 数据库可以轻松扩展。我可以说的是，NoSql 是最新的，因此数据库具有现成的水平扩展支持，例如考虑 MongoDB 中的 Mongos，它们完成了所有脏的工作，如分片文档、将请求路由到特定分片等。所以明天如果 Postgres或者 MySQL 提出了一些智能分表的机制，这样所有相关的数据大部分都保存在一个节点中，那么它可能会结束这场争论，因为关系数据库中没有任何内在的东西可以阻止它的水平扩展。

乐观地说，我相信在不久的将来，一切都将与策略有关。您计划如何扩展以及这些策略将与您在表格或文档中存储数据的方式无关。例如，在 Amazon 的 DocumentDB 中，有一个自动伸缩的概念，但如果您想通过分片实现这一点，每次伸缩时都复制数据将是一种负担。在 DocumentDB 中，这是作为共享集群卷（数据存储与计算分离）来处理的，它只是所有实例（主或辅助）的共享磁盘，并避免共享磁盘故障的风险 DocumentDB 复制数据共享磁盘到不同可用区中的其他六个磁盘。所以这里需要注意的一点是DocumentDB混合了共享磁盘的概念和标准的复制策略来实现它的目标。所以这完全取决于您在数据库中使用的策略，这才是最重要的

Answer 5

在RDBMS中，当数据变得庞大时，表可能会散布在多个系统上，在这种情况下，执行JOIN之类的操作非常慢。

在使用NoSQL的情况下，通常将相关数据存储在同一台计算机上（在单个文档中-面向文档的数据库中，或者在宽列数据存储的情况下，相关列在同一台计算机上）。因此，它很容易在许多低端机器上进行横向扩展，显然，在这种情况下，在多个位置将存在重复数据，而在RDBMS中则不是这种情况

Answer 6

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

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

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

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

6 个答案: