我读过一些关于 NoSQL 使用的迷你书，例如 CouchDB 或 MongoDB（我比较熟悉后者）。
在性能方面更合适 - 特别是缩放：
我省略了诸如主从等 SQL 扩展技术（我的理解是使用超出其服务器增长的应用程序扩展 SQL 的方式）。
我的应用程序中的每个“帐户”都仅供个人使用，不会增长到疯狂的大小或访问权限。因此，我认为我可以将应用程序托管在一台或几台服务器上，并根据需要将数据分布在一台或多台服务器上。当一个 SQL 被挖掘出来时，我会将数据库的一半（按使用比例）重新定位到另一台服务器（远程与否）。这在理论上应该提供一些性能提升，让我可以毫不费力地进行一些扩展？？？
或者，在 NoSQL 解决方案中共享听起来很容易——唯一的副作用是我需要将所有记录保存在单个数据库中——稍微降低个人安全性——理论上？
您对此事有何经验/看法？
问候，亚历克斯
这个问题有点令人困惑。您正在询问两种不同可扩展性方法的性能特征......这假设这两种可扩展性方法相当等效，但事实并非如此。
您在这里询问了两种不同的方法；我将使用标准术语来描述它们。这些不是 NoSQL 特定的，并且适用于任何技术。
垂直扩展，这是一个非常大的单一服务器。
水平扩展，即许多较小的服务器聚集在一起。
这两种解决方案各不相同。水平扩展能够以一致的小成本逐步增加容量。垂直扩展需要非常大的前期成本，并且每次单台服务器的容量都满了。抛开所有其他因素不谈，通常正是因为这个因素，水平扩展是架构师用来扩展的方法。谷歌在 90 年代后期证明了这种方法的可行性。
MongoDB 和其他 NoSQL 解决方案使用这种方法来实现可扩展性。在 MongoDB 中，它被称为分片。现在来解决性能特征。在垂直方法中，最终发生容量增长的是这台机器本身实际上是一系列集群组件。巨大的硬盘阵列、主板阵列和 cpu 和内存。无法将两者进行对比，因为这在很大程度上取决于所使用的实际硬件和环境。不过有一点很清楚。为了达到类似的性能，水平方法将更便宜且更简单。
横向方法也有一些好处。某些自然限制发生在单台机器上，通过将负载分散到多台机器上可以避免这些限制。
最后，在旁注中，主/从不用于扩展。为了提供更多的读取容量，它将所有写入倍增。这意味着每个额外的节点提供的好处越来越少。虽然它可以稍微增加读取容量，但它旨在实现高可用性，而不是扩展。