为什么NoSQL更适合于；“向外扩展”；而不是关系型数据库？

我在一篇讨论NoSQL优缺点的文章中阅读了以下内容

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

我对RDBMS和NoSQL的可伸缩性感到困惑

我的困惑是：

为什么RDBMS不太能够向外扩展？以及购买更大的服务器而不是购买更便宜的服务器的原因

为什么NoSQL更能扩展

RDBMS具有ACID（）并支持事务。由于这些概念，使用RDBMS“向外扩展”更难实现

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

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

---

这就是为什么您通常只看到一个主服务器（writer）和多个从服务器（reader）。

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

---

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

因此，我一直在试图找出NoSQL与RDBMS之间的真正底线，并且总是以一个不太符合要求的响应结束。在我的搜索中，NoSQL和SQL有两个主要区别，只有一个是真正的优势

酸性vs碱性-NoSQL通常会遗漏SQL的一些酸性特性，这是一种“欺骗”，通过将这一抽象层留给程序员来实现更高的性能。之前的海报已经涵盖了这一点

水平缩放-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中，该对象基本上是按原样存储的，因此可以作为一种自包含对象驻留在单个服务器上，而不需要与其他数据库服务器上的其他表中的数据连接

但是，对于关系数据库，post需要与

comments

表中的注释以及

views

表中的视图连接。在SQL~中，这不会是一个问题，直到~数据库被分成碎片，在这种情况下，“注释1”可能位于一台DB服务器上，而“注释2”可能位于另一台DB服务器上。这使得在水平缩放的RDBMS中创建完全相同的对象比在NoSQL DB中要困难得多

有没有DB专家会证实或争论这些观点

对于无SQL， 1.与集合相关的所有子级都位于同一服务器上的同一位置，因此没有从另一服务器查找数据的联接操作

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

---

上述两种方法在NO-SQL中节省了大量的扩展开销。

在RDBMS中，当数据变得巨大时，可能会出现表分布在多个系统中的情况，在这种情况下，执行JOIN等操作的速度非常慢

---

在NoSQL中，通常相关数据存储在同一台机器上（在面向文档的数据库中的单个文档中，或者在宽列数据存储中，相关列存储在同一台机器上）。因此，它很容易在许多低端机器上扩展，显然在这种情况下，在多个位置会有重复的数据，而在RDBMS中不是这样的情况。为什么NoSQL数据库可以比SQL数据库更容易地进行水平扩展？我一直在想人们为什么一直这么说。我看到了许多文章，这些文章只是让我对他们不熟悉的行业术语和模糊的假设感到困惑。我建议您阅读Martin Kleppman的《设计数据密集型应用程序》。此外，我将分享我对这个主题的一些理解

连接-在多对一或多对多关系的情况下，迄今为止发明的任何数据库都无法将数据保存在一个表或文档中，因此，如果数据被切分（或分区），无论是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

{
  "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"
    }
  ]
}