在NoSQL和RDBMS中扩展？

我试图了解可伸缩性方面的nosql和关系数据库的体系结构差异。

我对可伸缩性（水平）的理解是，随着数据的增长，我们添加了越来越多的服务器来平均分配负载。

在键值NO-SQL数据库中，我们可以添加新机器并拆分键。但是，到目前为止，我所看到的所有示例都是为了理解NO-SQL数据库中的最终一致性，它们都具有主从配置，在该配置中，数据将在所有从属服务器之间复制，而不是在各种机器之间进行拆分以实现可伸缩性。

我的问题是，使用复制整个数据不会破坏No-SQL数据库的可扩展性吗？在RDBMS中也可以使用一个主机（用于写入）和一个从属（用于读取）来完成相同的工作，在这方面，NO-SQL如何更具可伸缩性？

可伸缩性的目标是增加给定应用程序的整体容量，并且可以是垂直的（更大的计算机）或水平的（添加更多的计算机）。关于水平扩展，可以添加更多计算机，但是随着计算机数量的增加，群集中节点发生故障的可能性也要增加，这一点要牢记。

添加更多节点时，您可以做的就是拆分数据（称为分片），也可以复制数据（称为Replication）。

复写

使用复制时，通常的体系结构是主从结构，在该结构中，您只能写入主服务器，而主服务器将数据复制到从属服务器，因此这意味着您无法使用复制将写入的内容拆分到集群，但是可以拆分在一致性级别（并非所有NoSQL技术都提供相同的级别）和集群配置上，读取操作都非常重要。

分片

分片更适合于提供缩放，因为如果可能的话，您将数据集分为多个具有相似大小的部分。显然，这样做的好处是可以将读取和写入拆分到不同的节点。为了使它起作用，需要建立一些机制：

路由：定位数据存储在哪个分片中，或确定要写入哪个分片

平衡：保持数据集不同片段的大小在一段时间内保持相似的大小。

但是通常这些机制是由数据库供应商提供的，因此无需担心会提供它，但是仍然需要了解如何管理集群。

正如我首先提到的，这里的问题是，群集拥有的节点越多，给定节点发生故障的机会就越高，这意味着如果具有部分数据集的节点脱机，则部分数据将不可用，这不是理想的情况。但是幸运的是，分片和复制不是排他的，是否有可能构建分片群集，其中每个分片都是一个已建立复制的群集。

但是为了回答你的问题

使用复制整个数据不会破坏No-SQL数据库的可扩展性吗？

在主从体系结构中，您不能拆分写入，但是可以拆分读取，尽管这主要是为了实现高可用性，但这是一种扩展方式。

无论如何，有一些新的紧急数据库开始提供多主机体系结构，其中所有节点都充当主机，这意味着所有节点都可以接收，写入和读取。

在RDBMS中也可以使用一个主机（用于写入）和一个从属（用于读取）来完成相同的工作，在这方面，NO-SQL如何更具可伸缩性？

在单节点环境中，JOINS涉及到NoSQL（因为它是一项昂贵的操作）或涉及很多完整性检查时，它已经比RDBMS更快。

因此，当您尝试在RDBMS中对数据集进行分片时，除非经过精心设计，否则最可能的情况是位于不同分片中的所需数据。这意味着需要在不同的节点之间执行JOIN和完整性检查，这使得它们比以前更加昂贵的操作。

这意味着RDBMS数据库使用的机制在您打算水平扩展时会充当约束，而NoSQL则不会。是的，您仍然可以水平扩展RDBMS，但是总的来说要比使用NoSQL数据库昂贵。

更新：图数据库的特别提及

在图形数据库中进行分片真的很困难，因为从数学上来说，在不同服务器之间分配大型图形的问题已经解决了。而且，当必须在不同分片之间查询数据时，图的主要特征之一便会丢失，即快速横切。

我已经看到了图形数据库可以水平缩放的两种主要方法：

1）让应用程序/开发人员决定如何对图形进行分区，您可以想象这有多复杂。

2）复制所有节点中的所有图，并使用高速缓存分片，这意味着所有节点都具有完整的数据集，但是每个节点都在内存中保留了最需要对该节点查询的部分图。

我猜想，将来，图形数据库公司将开发更多解决方案来解决此问题。

与您的问题相关的是，由于缺乏RDBMS约束，在水平缩放方面，图数据库在当前状态下仍可以超出RDBMS，但是很难在不同的NoSQL数据库类型之间进行比较。