我认为一个好的解决方案是使用虚拟分片。您可以从一台服务器开始，并将所有虚拟分片指向一台服务器。在增量 id 上使用模块在虚拟分片中均匀分布行。使用 Amazon RDS，您可以选择将一个从属变为主控，因此在您更改分片配置（将更多虚拟分片指向新服务器）之前，您应该将一个从属设置为主控，然后更新您的配置文件，然后删除使用模数的新主服务器上的所有记录不符合您用于新实例的分片范围。
您还需要从原始服务器中删除行，但现在所有具有基于新虚拟分片范围模数的 ID 的新数据都将指向新服务器。因此，您实际上不需要移动数据，而是利用 Amazon RDS 服务器升级功能。
然后，您可以从原始服务器制作副本。您创建的唯一 ID 为：分片 ID + 表类型 ID + 增量编号。因此，当您查询数据库时，您知道从哪个分片获取数据。
我不知道如何使用 RavenDB 做到这一点，但它可以很好地与 Amazon RDS 一起使用，因为 Amazon 已经为您提供了复制和服务器升级功能。
我同意他们应该是一个从一开始就提供无缝社交的解决方案，而不是告诉开发人员在问题发生时解决问题。此外，我发现许多在分片之间均匀分布数据的 NoSQL 解决方案需要在低延迟的集群中工作。所以你必须考虑到这一点。我尝试将 Couchbase 与两台不同的 EC2 机器（不在专用的 Amazon 集群中）一起使用，并且数据平衡非常缓慢。这也增加了总成本。
我还想补充一点，pinterest 使用 4096 个虚拟分片解决了他们的可扩展性问题。
您还应该研究许多 NoSQL 数据库的分页问题。使用这种方法，您可以很容易地对数据进行分页，但可能不是最有效的方式，因为您可能需要查询多个数据库。另一个问题是改变模式。Pinterest 通过将所有数据放在 MySQL 中的 JSON Blob 中解决了这个问题。当您想添加一个新列时，您可以使用新列数据 + 键创建一个新表，并且可以在该列上使用索引。如果您需要查询数据，例如通过电子邮件，您可以创建另一个带有电子邮件+ ID 的表，并在电子邮件列上放置一个索引。计数器是另一个问题，我的意思是原子计数器。因此，最好从 JSON 中取出这些计数器并将它们放在一个列中，这样您就可以增加计数器值。
那里有很多很好的解决方案，但最终你会发现它们可能非常昂贵。我更喜欢花时间构建自己的分片解决方案，以免以后让自己头疼。如果你选择另一条路，那么有很多公司等着你去惹麻烦，并要一大笔钱来解决你的问题。因为在您需要他们的那一刻，他们知道您将付出一切以使您的项目再次工作。那是根据我自己的经验，这就是为什么我要使用您的方法来构建自己的分片解决方案，这也便宜得多。
另一种选择是使用 MySQL 的中间件解决方案，如 ScaleBase 或 DBshards。所以你可以继续使用 MySQL，但在你需要扩展的时候，他们有很好的解决方案。而且成本可能比替代方案低得多。
另一个提示：当你为分片创建配置时，放置一个接受 false 或 true 的 write_lock 属性。因此，当它为 false 时，数据将不会写入该分片，因此当您获取特定表类型（即用户）的分片列表时，它将仅写入相同类型的其他分片。这也有利于备份，因此当您希望在备份所有数据时锁定所有分片以获得所有分片的时间点快照时，您可以向访问者显示一个友好的错误。尽管我认为您可以发送全局请求，以使用 Amazon RDS 为所有数据库创建快照并使用时间点备份。
问题是大多数公司不会花时间使用 DIY 分片解决方案，他们更愿意为 ScaleBase 付费。这些解决方案来自单个开发人员，他们从一开始就可以负担得起可扩展解决方案的费用，但希望放心，当他们达到他们需要的程度时，他们就有了解决方案。只要看看那里的价格，你就会发现它会花费你很多。完成后，我很乐意与您分享我的代码。在我看来，你走的是最好的道路，这完全取决于你的应用程序逻辑。我将我的数据库建模为简单、无连接、不复杂的聚合查询——这解决了我的许多问题。将来您可以使用 Map Reduce 来解决那些大数据查询需求。