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

Posted 2021-05-03

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

或者我们应该构建课程粒度域对象并将它们直接存储在网格和我们刚刚用于持久性的实体上。

编辑：我认为这个问题还没有完全回答。到目前为止，我们收到了Hazelcast，Gemfire和Ignite的评论。我们缺少Infinispan，Coherence ....这是为了完成的缘故:)

答案

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

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

另一答案

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

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

另一答案

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

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

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

我们遇到的一个经验是使用Java Serialization进行长期数据存储的缺点。我们现在避免它，因为对象兼容性导致的所有问题随着时间的推移而变化。更不用说.NET客户端阅读对象会让人头疼。 :)