通常，数据库服务器是我们必须购买的最大、最昂贵的机器，因为垂直扩展是唯一的选择。是否有任何数据库可以很好地横向扩展（即跨多台商品机器）？这种方法有哪些限制？
【问题讨论】：
标签： database performance scalability
Oracle RAC 根本无法横向扩展，因为所有 Oracle 实例共享相同的数据存储。是的，使用 SAN 的东西你可以获得一个大尺寸的数据库，但它根本不可扩展。换句话说，Oracle RAC 仍然是一种向上扩展的方法。因此，对于横向扩展或横向扩展，您必须按功能对数据进行分区，这意味着将不同的表组放在不同的数据库中；或对每个表的数据进行分区，这意味着将一个表分区为具有相同架构但存储在不同数据库中的多个子表。通过这种方式，您可以获得横向扩展的解决方案。这方面有很多资源。 Sharding 在 web 2.0 网站架构博客领域已经流行了一段时间。 由于数据库本身不直接支持 Sharding，因此您必须构建自己的解决方案。但正如我所说，已经有很多教训了。对于 oracle，分区表是可能的。对于mysql，检查this question
【讨论】：
Oracle RAC -- 真正的应用集群
这很好用，您只需将框添加到集群中。您可以从一个盒子故障转移到另一个盒子。这不是复制，所有的盒子都是同一个逻辑单元的一部分。
当然，这很花钱。
【讨论】：
别担心，好的解决方案来了！
Couchdb 和 Hypertable 是开源的，仍处于 alpha 阶段，但它们显然旨在简化商品软件的扩展。它们工作得很好，并且可能会改变您对数据库的看法。
此外，如果可以让其他人为您分发，Google AppEngine 和 Amazon SimpleDB 是非常便宜的分布式数据库服务，尽管它们现在都处于测试阶段，因此施加了严格的限制。
【讨论】：
有一些存储技术，如 JavaSpaces（或 Gigaspaces 等商业实现），可提供高度可扩展、快速且安全的对象访问。
还有一些分布式缓存系统，例如 memcached，提供了类似的方法。
当然，这些都不是真正的数据库，但它们可以与数据库结合使用，从而在合适的架构下提供大量的水平可扩展性。真正的问题是，如果您想要数据库附带的所有 ACID 优点，就会有某些不可避免的性能损失。唯一的出路是找出不需要 ACID 的位，并使用其他技术来维护这些位。
【讨论】：
Oracle RAC 是数据库的劳斯莱斯，允许相对容易地添加额外的硬件节点和硬件故障转移。
但是，您的商品硬件成本与许可成本相比相形见绌。
为什么你觉得你需要水平缩放。具有 40GB RAM 和 SAN 存储的多 CPU 核心服务器可以支持非常大的数据库安装。
您能否提供任何规模和预期活动信息，以便更好地了解您的问题？
【讨论】：
如果您确实采用 RAC 路线，请记住它不会永远水平扩展。甚至销售人员也承认 90% 的 rac 客户是 4 个节点或更少。一旦你走得更多，你就会得到递减的回报。所以 rac 可能对你有用，但不能保证是答案。
【讨论】：
MySQL：http://www.mysql.com/why-mysql/scaleout.html
限制是它最适合以读取为主的工作负载。您通常有一个接收所有写入的“主”，以及复制写入的许多“从”。然后将读取分配到所有数据库。
MySQL 复制是异步的，因此您可能必须处理时间延迟问题（您写入主服务器，然后在复制写入之前从从服务器读取）。
【讨论】：
Netezza 和其他数据仓库设备以这种方式扩展，但它们不适合 OLTP 和 Web 应用工作负载。
【讨论】：
跨多台机器扩展的 Oracle 路由称为真正应用程序集群 (Oracle RAC)。其他地方的文档没有尽头。您可以尝试从http://www.oracle.com/database/rac_home.html 开始。
【讨论】：
MongoDB 是水平扩展的最佳数据库之一。
【讨论】：
Oracle 真正应用集群。如果你想要最好的，那就看看吧。
【讨论】：
如果您认真地认为您将扩展一个体面的多核“Big Iron”机器，那么您可以考虑对数据进行分区。这是一种很好的、与数据库无关的横向扩展方式。
所有横向的数据库都会付出巨大的代价。
除非您有大量的 $$ 来解决这个问题，否则请忘记 RAC。虽然它非常好，但一旦扩展到超过 2 个节点，它就非常昂贵。
【讨论】：
您可能会查看 DashDB for OLAP -- IBM 将它与 Cloudant for OLTP 配对。 https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en
【讨论】：