RavenDB-规划可伸缩性

如何解决RavenDB-规划可伸缩性

| 我最近一直在学习RavendB，并且想使用它。 我想知道人们对以一种可扩展的方式构建系统有什么建议或意见，特别是在服务器之间分拆数据，但是可以在单个服务器上启动并且只能根据需要增长。 是否建议甚至可能在单个实例上创建多个数据库并在它们之间实施分片。那么要扩展，仅仅是将这些数据库分布在机器上就可以了吗？ 我的第一印象是这种方法行得通，但是我很想听听别人的意见和经验。 更新1： 我一直在考虑这个话题。我认为“以后再整理”方法的问题在于，在这种情况下，我似乎很难在服务器之间平均分配数据。我将没有一个可以在（A-E，F-M ..）范围内使用的字符串键，它将使用数字来完成。 这留下了两个我可以看到的选择。要么在边界上打破它，所以1-50000在分片1上，50001-100000在分片2上，但是如果站点老化，例如这样，您原来的分片将做的工作要少得多。另外，如果需要将文档移动到新的分片，则轮循分片并将分片ID放入密钥的策略将受到影响，这将更改密钥并破坏使用该密钥的URL。 因此，我的新想法（我再次将其发布以发表评论）将是从第一天开始创建一个存储系统。就像将分片ID填充到密钥中一样，但是您从一个大数字开始，比如说1000，您将在它们之间平均分配。然后，当需要将负载拆分为一个分片时，可以说将存储桶501-1000移至新服务器，并编写分片逻辑，即1-500进入分片1，而501-1000进入分片2。第三台服务器联机时，您需要选择其他范围的存储桶并进行调整。 在我看来，这使您能够拆分为最初创建的铲斗一样多的碎片，从而在数量和寿命方面均等地分散负荷。无需更改键。 有什么想法吗？     

解决方法

可能，但实际上没有必要。您可以开始使用一个实例，然后在需要时通过稍后设置分片进行扩展。 另请参阅： http://ravendb.net/documentation/docs-sharding http://ayende.com/blog/4830/ravendb-auto-sharding-bundle-design-early-thoughts http://ravendb.net/documentation/replication/sharding     ,我认为一个好的解决方案是使用虚拟分片。您可以从一台服务器开始，然后将所有虚拟分片指向一台服务器。使用增量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中取出，并将它们放在一列中，以便您可以增加计数器的值。 那里有很棒的解决方案，但是最终，您发现它们可能非常昂贵。我更愿意花时间来构建自己的分片解决方案，以免日后头痛。如果您选择其他方法，那么很多公司都在等着您遇到麻烦，并要求大量资金来解决您的问题。因为在您目前需要他们的时候，他们知道您将付出一切以使您的项目再次正常工作。那是从我自己的经验中得出的，这就是为什么我不愿意使用您的方法来构建自己的分片解决方案的原因，这也要便宜得多。 另一个选择是为ScaleBase或DBshards使用MySQL中间件解决方案。因此，您可以继续使用MySQL，但在需要扩展时，它们具有成熟的解决方案。而且成本可能比其他方法低得多。 另一个提示：为分片创建配置时，请放置一个接受false或true的write_lock属性。因此，如果它为false，则不会将数据写入该分片，因此，当您获取特定表类型（例如，用户）的分片列表时，该数据将仅被写入该相同类型的其他分片。这也有利于备份，因此在备份所有数据以获取所有分片的时间点快照时，如果您想要锁定所有分片，可以向访问者显示友好错误。尽管我认为您可以发送全局请求，以使用Amazon RDS快照所有数据库并使用时间点备份。 事实是，大多数公司不会花时间使用DIY分片解决方案，他们会更愿意为ScaleBase付费。这些解决方案来自单一开发人员，这些开发人员从一开始就可以为可扩展的解决方案付费，但是要放心，当他们到达需要的点时，他们就拥有了一个解决方案。只要看一下那里的价格，您就会发现这将花费您很多。完成后，我将很乐意与您分享我的代码。在我看来，您所走的路是最好的，这完全取决于您的应用程序逻辑。我将数据库建模为简单，没有连接，没有复杂的聚合查询-这解决了很多问题。将来，您可以使用Map Reduce解决这些大数据查询需求。