RavenDB - 规划可伸缩性

时间:2011-05-16 06:33:28

标签: scalability sharding 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.然后当第三台服务器联机,您可以选择另一系列的存储桶并进行调整。

在我看来,这使您能够分割成最初创建桶的碎片,在数量和年龄方面均匀分布负载。无需更改密钥。

思想?

2 个答案:

答案 0 :(得分:4)

这是可能的,但实际上是不必要的。您可以开始使用一个实例,然后在必要时通过稍后设置分片进行缩放。

另见:

http://ravendb.net/documentation/docs-sharding

http://ayende.com/blog/4830/ravendb-auto-sharding-bundle-design-early-thoughts

http://ravendb.net/documentation/replication/sharding

答案 1 :(得分:1)

我认为一个好的解决方案是使用虚拟分片。您可以从一台服务器开始,并将所有虚拟分片指向单个服务器。在增量ID上使用模块可以在虚拟分片中均匀分布行。使用Amazon RDS,您可以选择将从属设备变为主设备,因此在更改分片配置(将更多虚拟分片指向新服务器)之前,您应该将从属设备设为主设备,然后更新配置文件,然后删除使用modulu的新主服务器上的所有记录都不符合您用于新实​​例的分片范围。

您还需要从原始服务器中删除行,但到目前为止,所有具有基于新虚拟分片范围的模块ID的新数据都将指向新服务器。因此,您实际上不需要移动数据,而是利用Amazon RDS服务器升级功能。

然后,您可以从原始服务器上复制副本。您可以创建唯一ID:Shard ID +表类型ID +增量编号。因此,当您查询数据库时,您知道要去哪个分片并从中获取数据。

我不知道如何使用RavenDB,但它可以与Amazon RDS很好地协作,因为亚马逊已经为您提供了复制和服务器推广功能。

我同意他们应该是一个解决方案,从一开始就提供无缝的社交性,而不是告诉开发人员在问题发生时对问题进行排序。此外,我发现许多在分片上均匀分布数据的NoSQL解决方案需要在低延迟的群集中工作。所以你必须考虑到这一点。我尝试将Couchbase与两台不同的EC2机器(不在专用的Amazon集群中)一起使用,数据平衡非常慢。这也增加了整体成本。

我还想补充一点,即使用4096个虚拟分片,pinterest已采取了哪些措施来解决其可扩展性问题。

您还应该查看许多NoSQL数据库的分页问题。使用这种方法,您可以非常轻松地分页数据,但可能不是以最有效的方式,因为您可能需要查询多个数据库。另一个问题是改变架构。 Pinterest通过将所有数据放入MySQL中的JSON Blob来解决这个问题。如果要添加新列,可以使用新列数据+键创建新表,并可以使用该列上的索引。如果您需要查询数据(例如,通过电子邮件),则可以使用电子邮件+ ID创建另一个表,并在电子邮件列中添加索引。计数器是另一个问题,我的意思是原子计数器。因此,最好从JSON中取出这些计数器并将它们放在一列中,这样就可以增加计数器值。

那里有很好的解决方案,但在一天结束时你会发现它们非常昂贵。我更喜欢花时间建立自己的分片解决方案,以防止自己后来头疼。如果你选择其他路径,有很多公司在等你惹麻烦,并要求相当多的钱来解决你的问题。因为在您需要它们的那一刻,他们知道您将支付所有费用以使您的项目再次运作。这是我自己的经验,这就是为什么我要用你的方法来制造我自己的分片解决方案,这也便宜得多。

另一个选择是使用MySQL的中间件解决方案,如ScaleBase或DBshards。因此,您可以继续使用MySQL,但在您需要扩展时,它们已经得到了充分证明。并且成本可能远低于替代方案。

另一个提示:当您为分片创建配置时,请设置一个接受false或true的write_lock属性。因此,当它为false时,数据将不会写入该分片,因此当您获取特定表类型(即用户)的分片列表时,它将仅写入同一类型的其他分片。这对备份也很有用,因此当您想要在备份所有数据时锁定所有分片以获取所有分片的时间点快照时,可以为访问者显示友好错误。虽然我认为您可以使用Amazon RDS发送全局请求来创建所有数据库并使用时间点备份。

事实上,大多数公司都不会花时间使用DIY分片解决方案,他们更愿意为ScaleBase付费。这些解决方案来自单一开发人员,他们可以从一开始就支付可扩展的解决方案,但是他们希望放心,当他们达到他们需要的时候,他们就有了解决方案。只要看看那里的价格,你就可以发现它会花费你很多。一旦我完成,我很乐意与你分享我的代码。在我看来,你走的是最好的路径,这完全取决于你的应用逻辑。我建模我的数据库很简单,没有连接,没有复杂的聚合查询 - 这解决了我的许多问题。将来,您可以使用Map Reduce来解决那些大数据查询需求。

相关问题