通常,数据库服务器是我们必须购买的最大、最昂贵的机器,因为垂直扩展是唯一的选择。是否有任何数据库可以很好地水平扩展(即跨多个商品机器)?这种方法有什么限制?
13 回答
Oracle RAC 根本不是水平可扩展的,因为所有 Oracle 实例共享相同的数据存储。是的,使用 SAN 的东西你可以获得一个大尺寸的数据库,但它根本不可扩展。换句话说,Oracle RAC 仍然是一种向上扩展的方法。因此,对于横向扩展或横向扩展,您必须按功能对数据进行分区,这意味着将不同的表组放在不同的数据库中;或者对每个表的数据进行分区,这意味着将一个表分区为具有相同架构但存储在不同数据库中的多个子表。通过这种方式,您可以获得横向扩展的解决方案。这方面有很多资源。分片在 web 2.0 网站架构博客领域已经有一段时间了。由于数据库本身不直接支持 Sharding,因此您必须构建自己的解决方案。但正如我所说,已经有很多教训了。对于 oracle,分区表是可能的。对于mysql,检查这个问题
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 个节点,它就非常昂贵。
您可能会查看用于 OLAP 的 DashDB——IBM 将它与用于 OLTP 的 Cloudant 配对。 https://www.ibm.com/developerworks/community/blogs/5things/entry/5_things_to_know_about_dashdb_placeholder?lang=en