高级别的 DB 分片的概念是有道理的，将 DB 节点分开，这样就没有一个单独的节点负责所有的持久数据。但是，我对什么构成“碎片”有点困惑。它是跨分片复制整个表，还是通常只复制一个？
例如，如果我们以 twitter 为例，在最基本的层面上，我们需要一个 users 和一个 tweets 表。如果我们根据用户 ID 分片，有 10 个分片，那么分片函数就是userID mod 10 === shard location。然而，这对 tweets 表意味着什么？是单独的（单个数据库表）还是每条推文都根据创建推文的用户 ID 在 10 个表之间划分？
如果是后者，假设我们在用户 ID 以外的其他东西上进行分片，例如，推文创建了时间戳，我们如何知道在哪里查找与 用户相关的信息 如果所有表都根据推文创建时间（用户没有概念）进行分片？
【问题讨论】：
分片是将数据拆分到多个服务器上。如何拆分的选择非常关键，可能是显而易见的。
乍一看，按用户 ID 拆分推文听起来是正确的。但是还有什么其他的东西吗？是否有任何“分组”或您关心谁“接收”每条推文？
照片共享网站可能最好在用户 ID 上进行拆分，用户照片的元信息也与用户在同一台服务器上。 （实际的照片在哪里是另一个讨论。）但是你如何处理一个设法上传一百万张照片的人？希望这不会炸毁他所在的任何分片上的磁盘。
一个乱七八糟的案例是电影。你应该分开看电影吗？评论？写评论的用户？流派？
当然，“mod 10”可以方便地说明用户在哪个分片上。也就是说，直到您需要第 11 个分片！我更喜欢“散列”和“字典”之间的折衷。首先执行 mod 4096，然后在将 4096 值映射到 10 个分片的“字典”中查找。然后，编写一个强大的工具来将一组用户（都具有相同的 mod-4096 值）从一个分片移动到另一个分片。从长远来看，这个工具将非常方便地处理硬件升级、软件升级、王牌大小的高音扬声器，或者让其他人让开等等。
如果您想进一步讨论分片推文，请提供所涉及的主表。此外，我对如何为推文发布唯一 ID（如果需要）有强烈的意见。 （有一些惨败的方法。）
【讨论】：
Photos 应该有PRIMARY KEY(userid, photoid)。最好从单个分片获取一个请求的所有信息。跨分片JOINs 太糟糕了。