MySQL 分片方法？

Question

分片 MySQL 表的最佳方法是什么。
我能想到的方法是:

应用级分片？

在 MySQL 代理层分片？

用于分片的中央查找服务器？

你知道这方面有什么有趣的项目或工具吗？

Answer 1

除非完全不可避免，否则最好不要将 MySQL 表分片。

在编写应用程序时，您通常希望以最大限度提高速度和开发人员速度的方式进行编写。仅在必要时优化延迟(答案准备好之前的时间)或吞吐量(每个时间单位的答案数)。

只有当所有这些分区的总和不再适合单个数据库服务器实例时，您才进行分区，然后将分区分配给不同的主机(= 分片) - 原因是写入或读取。

写入情况是 a) 写入频率使服务器磁盘永久过载或 b) 写入过多，因此复制在此复制层次结构中永久滞后。

分片的读取情况是当数据的大小如此之大以至于它的工作集不再适合内存并且数据读取开始命中磁盘而不是大部分时间从内存中提供服务时。

只有当您有 分片你做。

分片的那一刻，您将通过多种方式为此付出代价:

您的大部分 SQL 不再是声明性的。

通常，在 SQL 中，您会告诉数据库您想要什么数据，然后让优化器将其转换为数据访问程序。这是一件好事，因为它很灵活，而且因为编写这些数据访问程序是一件会损害速度的无聊工作。

在分片环境中，您可能会根据节点 B 上的数据加入节点 A 上的表，或者您在节点 A 和 B 上有一个比节点大的表，并且正在根据节点 B 和 C 上的数据连接来自该节点的数据。您开始手动编写应用程序端基于哈希的连接解析以解决该问题(或者您正在重新发明 MySQL 集群)，这意味着您最终会得到许多不再声明的 SQL，而是以程序方式表达 SQL 功能(例如，您在循环中使用 SELECT 语句)。

您正在招致大量网络延迟。

通常，SQL 查询可以在本地解析，优化器知道与本地磁盘访问相关的成本，并以最小化成本的方式解析查询。

在分片环境中，通过在网络上对多个节点运行键值访问来解决查询(希望使用批量键访问而不是每次往返的单独键查找)或通过推送 WHERE 的部分内容来解决查询。子句到可以应用它们的节点(称为“条件下推”)，或两者兼而有之。

但即使在最好的情况下，这也涉及比本地情况更多的网络往返行程，并且更复杂。特别是因为 MySQL 优化器对网络延迟一无所知(好吧，MySQL 集群在这方面正在慢慢变得更好，但对于集群外的 vanilla MySQL 仍然如此)。

您正在失去 SQL 的许多表达能力。

好吧，这可能不太重要，但是外键约束和其他用于数据完整性的 SQL 机制无法跨越多个分片。

MySQL 没有允许异步查询正常工作的 API。

当同一类型的数据驻留在多个节点上时(例如节点 A、B 和 C 上的用户数据)，通常需要针对所有这些节点解决横向查询(“查找所有 90 天未登录的用户帐户或更多”)。数据访问时间随节点数量线性增长，除非可以并行询问多个节点并在它们进来时聚合结果(“Map-Reduce”)。

这样做的前提是异步通信 API，它不存在于 MySQL 的良好工作状态。另一种选择是在子进程中进行大量 fork 和连接，这是在季票上访问吮吸世界。

一旦您开始分片，数据结构和网络拓扑就会随着性能指向您的应用程序而变得可见。为了合理地执行，您的应用程序需要了解这些事情，这意味着实际上只有应用程序级分片才有意义。

如果您想自动分片(例如，通过散列主键来确定哪一行进入哪个节点)，或者如果您想以手动方式进行功能拆分(“与 xyz 用户故事相关的表转到这个主，而 abc 和 def 相关的表去那个主")。

功能分片的优点是，如果做得好，大多数开发人员大部分时间都看不到它，因为与他们的用户故事相关的所有表都将在本地可用。这使他们仍然可以尽可能长时间地从声明式 SQL 中受益，并且由于跨网络传输的数量保持最少，因此网络延迟也会更少。

功能分片的缺点是不允许任何单个表大于一个实例，并且需要设计人员手动注意。

功能分片的优势在于它相对容易地对现有代码库进行，但更改数量不会太大。 http://Booking.com在过去的几年里已经做过多次，而且对他们来说效果很好。

说了这么多，看着你的问题，我确实相信你问错了问题，或者我完全误解了你的问题陈述。