在服务矩阵集群中存储大量状态 [英] Storing a large amount of state in a service fabric cluster

问题描述

我有一个场景，我们需要存储x * 100 GB的数据.一般而言，数据是服务结构群集本身中参与者(划分良好，仅由特定参与者使用的参与者)的持久状态的良好候选者.

是否建议将服务矩阵持久状态存储用于这种规模的数据? (我们的计算负载将相当低，因此仅提高虚拟机存储状态不是一个理想的选择.)

持久状态的数量如何影响集群中节点之间移动分区的延迟?

解决方案

让我们看看状态如何存储在服务中(这也适用于参与者).

将数据存储在服务中的组件称为状态提供者.状态提供程序只能是内存中的，也可以是内存+本地磁盘中的.使用actor服务获得的默认状态提供程序是内存+本地磁盘，但它仅将热数据保留在内存中，因此您的存储需求不受内存的限制.与Reliable Collections状态提供程序相反，该状态提供程序当前将所有数据都存储在内存中和本地磁盘上，尽管在将来的版本中，它还可以选择仅将热数据保留在内存中，并将其余数据卸载到本地磁盘.

鉴于您正在使用actor，则可以使用默认的actor状态提供程序，这意味着您的数据容量受计算机或VM上本地磁盘存储的限制，这对于存储100 GB的存储空间来说应该是合理的.通常，我们不会移动整个分区，但是有时Service Fabric确实需要重建服务的副本，并且您拥有的数据越多，构建副本所花费的时间就越长.但是，这并不会真正影响服务的延迟，因为您在有状态服务中有多个副本，并且通常有足够多的副本，因此您无需等待其他副本被重建.重建副本通常是发生在侧面的事情.

的确，添加VM仅用于存储状态并不经济，但是请记住，您可以根据需要在VM上打包尽可能多的服务.因此，即使您的actor服务使用的计算量不大，您也可以始终在这些VM上打包其他服务​​以用尽该计算量，以便最大化VM上的计算量和存储量，这实际上是非常经济的./p>

I have a scenario where we need to store x*100 GBs of data. The data is in-general a good candidate for persistent state for an actor (well-partitioned, used by the specific actors only) in the service fabric cluster itself.

Is the service fabric persistent state storage recommended for data of this scale? (Our compute load is going to be fairly low, so bumping up VMs just to store the state is not a desirable option.)

How does the amount of persistent state affect the latency of moving partitions between nodes in the cluster?

解决方案

Well let's look at how state is stored in a service (this applies to actors too).

The component that stores your data in your service is called a State Provider. State providers can be in-memory only or in-memory + local disk. The default state provider you get with an actor service is in-memory + local disk but it only keeps hot data in memory so your storage requirements are not memory bound. Contrast with the Reliable Collections state provider which currently stores all data both in-memory and on local disk, although in a future release it will also have an option to only keep hot data in memory and offload the rest to local disk.

Given that you are using actors, you can use the default actor state provider which means your data capacity is limited by local disk storage on your machines or VMs, which should be reasonable for storing 100s of GB. We generally don't move entire partitions around, but occasionally Service Fabric does need to rebuild a replica of your service, and the more data you have the longer it will take to build a replica. However, this doesn't really affect the latency of your service, because you have multiple replicas in a stateful service and you usually have enough replicas up that you don't need to wait for another to be rebuilt. Rebuilding a replica is usually something that happens "off to the side."

It's true that it's not economical to add VMs just for storing state, but keep in mind that you can pack as many services onto your VMs as you want. So even though your actor service isn't using much compute, you can always pack other services on those VMs to use up that compute so that you're maximizing both compute and storage on your VMs, which can in fact be very economical.

这篇关于在服务矩阵集群中存储大量状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！