为什么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
ACID就像CAP一样被过度使用，实际上它是关于向客户端展示单个数据副本而不是实际存在多个数据副本（以增强可用性、容错等为目的），以及数据库用于执行此操作的策略。例如，在Postgres中，在主从分布式系统的情况下，可以选择同步或异步复制，并且使用WAL（Write ahead logs）实现复制，MongoDB也是同样的情况，只是用oplog（Operations Log）替代了WAL，两者都支持流式复制和故障切换。那么差异在哪里？实际上，我找不到NoSql数据库为什么可以轻松扩展的非常强有力的原因。我能说的是NoSql是最新的，所以数据库带有现成的支持水平扩展的功能，例如考虑MongoDB中的Mongos，它们完成所有肮脏的工作，如分片文档，将请求路由到特定的分片等。因此，如果Postgres或MySQL明天推出一些智能分片表的机制，以便大多数相关数据都保存在一个节点中，则可能会结束这场辩论，因为关系型数据库本质上没有任何防止其横向扩展的特性。
乐观地说，我相信在不久的将来，一切都将取决于策略。你如何计划进行扩展，而这些策略将独立于你如何存储数据，无论是在表中还是在文档中。例如，在Amazon的DocumentDB中，存在自动缩放的概念，但如果要通过分片实现这一点，则每次缩放时都需要复制数据，这将是一个负担。在DocumentDB中，共享群集卷（数据存储与计算分离）负责处理这个问题，这只是所有实例（主要或次要）的共享磁盘，并且为了避免共享磁盘故障的风险，DocumentDB将共享磁盘的数据复制到其他6个不同可用区的磁盘上。因此，这里需要注意的是，DocumentDB混合了共享磁盘和标准复制策略的概念，以实现其目标。因此，重要的是您在数据库中使用的策略。
