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

Question

我想知道哪种方法更好。 我们是否应该在网格上使用细粒度的实体，然后再从细粒度的实体中构造功能丰富的领域对象。

或者，我们应该构造过程粒度域对象，并将其直接存储在网格和我们仅用于持久性的实体上。

编辑：我认为这个问题尚未完全回答。 到目前为止，我们有来自Hazelcast，Gemfire和Ignite的评论。 我们缺少Infinispan，连贯性....那是为了完整起见:)

Answer 1

我相信，从一个数据网格到另一个数据网格，它可能有所不同。 我对Apache Ignite更加熟悉，在这种情况下，细粒度方法的效果要好得多，因为它更灵活，并且在许多情况下提供了更好的数据分发，因此具有更好的可伸缩性。 Ignite还提供了丰富的SQL功能[1]，可以连接不同的实体并执行索引搜索。 这样，您将不会失去细粒度模型的性能。

[1] https://apacheignite.readme.io/docs/sql-queries

Answer 2

我同意Valentin，它主要取决于您要使用的系统。 通常，我会考虑直接存储增强的域对象，无论如何，如果您只有很少的对象，但是它们的大小很大，则会导致节点上的分布不均和内存使用不均。 如果您的域对象是“正常”大小的并且有足够的空间，则不必担心。

在Hazelcast中，最好直接存储这些对象，但要注意使用良好的序列化系统，因为Java序列化速度很慢。 如果要查询域对象内部的属性，还应该考虑添加索引。

Answer 3

粗粒度对象的一个​​优点是数据一致性。 该对象中的所有内容都会自动保存。 但是，如果将该对象分成4个小对象，则会冒保存3个对象而1个失败的风险（无论出于何种原因）。

我们使用GemFire，并且倾向于使用粗粒度的对象。 例如，我们的客户对象包含一个地址列表。 另一种设计是为“客户”创建一个GemFire区域，为“客户地址”创建一个单独的GemFire区域，然后希望您可以使这些区域保持同步。

缺点是，每当有人更新地址时，我们都会重写整个Customer对象。 这不是很有效，但是我们的流量模式显示，地址更改非常罕见（与其他所有活动相比），因此可以正常工作。

但是，我们获得的一种经验是使用Java序列化进行长期数据存储的弊端。 由于对象兼容性随时间变化而引起的所有问题，我们现在避免这样做。 更不用说.NET客户端读取对象变得头疼。 :)