问内存数据网格中的细粒度和粗粒度域模型

EN

我同意Valentin的观点，它主要取决于您想要使用的系统。通常，我会考虑直接存储增强的域对象，不管怎么说，如果只有很少的对象，但是它们的大小很大，那么节点上的分布就会很差，内存的使用也会不一样。如果您的域对象是“正常”大小的，并且您有足够的空间，那么您不应该担心。

在Hazelcast中，最好直接存储这些对象，但是要注意使用一个好的序列化系统，因为Java序列化比较慢。如果要查询域对象中的属性，还应考虑添加索引。

我相信不同的数据网格会有所不同。我更熟悉Apache，在这种情况下，细粒度方法工作得更好，因为它更灵活，在许多情况下提供了更好的数据分发，因此更好的可伸缩性。rich还提供丰富的SQL功能1，允许连接不同实体并执行索引搜索。这样，您就不会失去细粒度模型的性能。

1

粗粒度对象的一个优点是数据一致性。该对象中的所有内容都以原子方式保存。但是，如果将该对象拆分为4个小对象，则可能导致3个对象保存，而1个对象失败(无论出于何种原因)。

我们使用GemFire，并且倾向于在某种程度上支持粗粒度的objects...up。例如，我们的Customer对象包含一个地址列表。另一种设计是为“客户”创建一个GemFire区域，为"CustomerAddresses“创建一个单独的GemFire区域，然后希望您能够保持这些区域的同步。

缺点是，每次有人更新一个地址，我们都会重写整个客户对象。这并不是很有效，但我们的流量模式表明地址更改非常罕见(与所有其他活动相比)，所以这很好。

不过，我们的一个经验是，将Java序列化用于长期数据存储的缺点。我们现在避免了它，因为随着时间的推移，对象的兼容性导致了所有的问题。更别提.NET客户端读取对象的麻烦了。:)