是否有可能扩大RDB？ 如果可能的话，怎么能实现呢？
我在问这个问题是因为我协助了一个NoSQL事件，在这个事件中，发言者多次说关系数据库的缺点之一就是不可能扩展。 换句话说，我们应该增加更多的内存和更多的存储空间，但是如果我们使用的是NoSQL数据库，我们不能像添加另外一台计算机一样。
是的，在一定程度上。
主 – 主复制 – 从理论上讲，可以进行读写的扩展，但是对于写操作而言，复杂并且需要分布式提交机制，比如两阶段提交。 这限制了它的实用性。
主从复制 – 扩展读取操作，但对写入操作完全没有帮助。 介绍复制滞后。
垂直分区 – 基本上在不同的服务器上查找不相关的表。 可扩展的读取和写入，但缺点是，您不能轻松地从不同的服务器join结果。
水平分区aka分片 – 在每台服务器中均匀分配数据。 数据的位置由分片键确定。 对读取和写入进行扩展，但是通过除分片键以外的其他标准访问数据需要查询所有服务器，在极端情况下需要map-reducetypes的基础结构。
如果将垂直和水平分区调整到极限，那么实际上最终会使用基于SQL后端的NoSQL解决scheme。
经验法则是，你不能水平地保存完整的ACID，你将不得不放弃至less一个特性。 通常在可伸缩系统中最通常只有最终的一致性 （即，整个系统不能保证始终保持一致，而是保证最终达到一致的状态）。
是的，可以使用分片和/或复制来扩展关系数据库。
NoSQL解决scheme通常更易于分片/复制。 他们通过放宽CAP定理中的一致性要求来做到这一点。
是的，例子：Oracle RAC，MySQL Sharding，SQL Server HADRON
并非所有的应用程序都适合NoSQL范例：例如银行业务，交易或会计。
另见http://www.codinghorror.com/blog/2009/06/scaling-up-vs-scaling-out-hidden-costs.html
听起来像是对我的偏见，而且已经做了很多次了
有可能扩展RDBMS，但这并不容易，而且涉及到一些妥协（NoSQL解决scheme经常将其作为其基本devise的一部分称为“特性”）。 例如，出于性能原因，您经常被迫放弃跨服务器交易。 用您select的关系数据库名称search“分片”，您可能会发现许多解决scheme具有不同的权衡。 没有一个是自动的，因为你需要仔细pipe理什么数据进入什么服务器，因为不同表中的数据是相关的 。
值得一提的是，Facebook运行在数以千计的分片MySQL服务器上……所以这是可能的。 所有的Microsoftnetworking属性也在分片的SQL Server数据库上运行。 通常这会涉及大量的应用程序代码更改（NoSQL解决scheme也会强制您进行更改）。