我已经阅读了一些关于使用NoSQL的小书，例如CouchDB或MongoDB（后者我更熟悉）。
在性能方面更合适 - 尤其是缩放：
我遗漏了SQL扩展技术，例如master-slave（我理解的是你用扩展服务器的应用程序扩展SQL的方式）。
我的应用程序中的每个“帐户”仅供个人使用，不会变得疯狂的大小或访问。所以我认为我可以将应用程序托管在一台或几台服务器上，并根据需要将数据分布在一台或多台服务器上。当一个SQL出来时，我会将数据库的一半（按比例说使用）重新定位到另一个服务器（远程或非远程）。从理论上讲，这应该可以提供一些性能提升，让我可以毫不费力地进行扩展。
或者在NoSQL解决方案中共享听起来非常简单 - 唯一的副作用是我需要将所有记录保存在单个数据库中 - 从理论上减少个人安全性？
您对此事有何经验/意见？
此致 亚历
答案 0 :(得分：3)
这个问题有点令人困惑。您正在询问两种不同可伸缩性方法的性能特征......这使得两种可伸缩性方法的假设非常相同，而它们并非如此。
这里有两种不同的方法;我将使用标准术语来描述它们。这些不是NoSQL特有的，适用于任何技术。
垂直缩放，这是一个非常大的单个服务器。
水平扩展，这是许多较小的服务器聚集在一起。
这两种解决方案与它们不同。水平扩展使得能够以一致的小成本逐步增加容量。垂直扩展需要预先支付非常大的成本，并且每次单个服务器的容量已满时再次需要。抛开所有其他事情，通常是因为这个因素，水平缩放是建筑师用来扩展的方法。 Google在90年代后期证明了这种方法的可行性。
MongoDB和其他NoSQL解决方案使用这种方法来实现可伸缩性。在MongoDB中，它被称为分片。现在来解决性能特征。在垂直方法中，最终发生容量增长的是这台单机本身实际上是一系列集群组件。巨型硬盘阵列，主板阵列和cpus和ram。这两者之间的对比是不可能的，因为其中很大一部分取决于所使用的实际硬件和环境。但有一点很清楚。为了达到类似的性能水平，水平方法将更便宜，更简单。
水平方法也有一些好处。在一台机器上会出现一些自然限制，可以通过在多台机器上分配负载来避免这种限制。
最后，在旁注中，Master / Slave不用于扩展。它为了提供更多的读取容量而倍增所有写入。这意味着每个附加节点提供的益处越来越少。虽然它可以略微增加读取容量，但它旨在实现高可用性，而非规模。