在服务结构集群中存储大量状态

Question

我有一个场景,我们需要存储x*100 GB的数据.在服务结构集群本身中,数据通常是演员(持久分区,仅由特定演员使用)的持久状态的良好候选者.

是否建议将此服务结构持久状态存储用于此规模的数据？(我们的计算负载相当低,因此仅仅为了存储状态而增加虚拟机并不是一个理想的选择.)

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

Answer 1

那么让我们来看看状态如何存储在服务中(这也适用于演员).

将数据存储在服务中的组件称为State Provider.状态提供程序可以是仅内存或本地内存+本地磁盘.使用actor服务获得的默认状态提供程序是内存+本地磁盘,但它只将热数据保存在内存中,因此您的存储要求不受内存限制.与Reliable Collections状态提供程序进行对比,该状态提供程序当前存储内存和本地磁盘上的所有数据,但在将来的版本中,它还可以选择仅将热数据保留在内存中,并将其余数据卸载到本地磁盘.

鉴于您正在使用actor,您可以使用默认的actor状态提供程序,这意味着您的数据容量受到计算机或VM上的本地磁盘存储的限制,这对于存储100 GB是合理的.我们通常不会移动整个分区,但偶尔Service Fabric确实需要重建服务的副本,并且您拥有的数据越多,构建副本所需的时间就越长.但是,这并不会真正影响服务的延迟,因为在有状态服务中有多个副本,并且通常有足够的副本,您无需等待另一个重建.重建副本通常是"偏离一边"的事​​情.

确实,仅仅为了存储状态添加VM是不经济的,但请记住,您可以根据需要将尽可能多的服务打包到VM上.因此,即使您的actor服务没有使用太多计算,您也可以始终在这些VM上打包其他服务​​以使用该计算,这样您就可以最大化VM上的计算和存储,这实际上非常经济.