具有地理信息的数据模型设计指南

Question

我们很快就要开始关于参考数据的GEODE了。我想要一些同样的指南。

如您所知，在金融参考数据世界中，各种参考数据实体(如工具、帐户、客户等)之间存在着复杂的关系，可以在数据库中作为3NF使用。

如果我的查询大多是读取密集型的，需要跨表连接(2-5个表)，那么在内存网格中处理相同问题的最佳方法是什么？

Case 1：为数据库中的所有表分离区域，然后使用OQL进行类似的连接，就像在数据库中一样？

即使你这样做了，你也必须小心地设计它，相关的实体总是在同一个分区中。

用对象图来建模1对多和多-多的关系？

Case 2：如果您知道join查询的样子，那么在每个具有equi特性的join查询中创建一个视图模型。

混淆：

(1)我有一个join查询需要员工，部门使用emp.deptId = dept.deptId OK荒诞1区域存在这样的视图模型

(2)我有另一个连接查询要求:员工、部门、薪资、地址联接以满足不同的要求。

因此，我必须再次创建一个视图模型来处理(2)，该模型将包含类似于(1)的员工和部门数据。这可能很快就会达到记忆阈值。

数据库中的更改仍然可以由事件侦听器来管理，但是有什么建议呢？

谢谢，达兰

Answer 1

我认为您的一般性问题相当广泛，并且不只是一种推荐的方法来涵盖所有的UC(主要是您的应用程序所要求的所有分析视图/数据模型)。

这些问题涉及许多因素，如单个数据元素的大小、数据量、源自应用程序的访问或访问模式的频率、信息的及时传递、数据需要有多精确、集群的大小、每个(虚拟)机器的物理资源等等。因此，任何给定的方法无疑都需要应用程序调优、相应地调优GemFire和JVM调优，而不管您的数据模型如何。不过，精心编制的数据模型可以确定这种调优的范围。

特别是在GemFire中，这种调优将涉及不同的配置，例如(但不限于)：数据管理策略、逐出 (溢出)和过期 (LRU，或者可能是自定义)设置以及不同的驱逐/过期阈值，可能会将数据存储在无堆内存中，使用不同的分区策略(PartitionResolver)等等。

例如，如果您的地址信息是相对静态的、不变的(即实际的“引用”数据)，那么您可以考虑在REPLICATE区域中存储地址数据。经常写入的数据(通常是“事务性”数据)在PARTITION区域中更好。

当然，如您所知，在查询(使用OQL)中“加入”的任何PARTITION数据(在单独的区域中管理)都必须并置。GemFire/Geode目前不支持分布式连接。

此外，某些节点可以承载某些区域，从而将集群划分为“事务性”节点和“分析性”节点，其中基于分析的节点是从事务性节点中的区域(小心CacheListeners )上更新的，或者更好的是异步使用带AsyncEventListeners的情商。AEQ可以单独提供高可用性和耐用性。这种事务性与分析性的方法是CQRS的基础。

数据的大小也会受到其存储形式的影响，即序列化和非序列化，而GemFire的专有序列化格式(PDX)与Java序列化相比是非常理想的。这都取决于您的数据需要如何“可移植”，以及您是否可以将数据保持在序列化的形式。

此外，您可能会考虑加入数据的费用是多么昂贵。这意味着，如果您能够相对便宜地聚合、转换和丰富运行时的数据(计算与内存/存储)，那么您可以考虑使用GemFire的功能执行服务，将您的逻辑带到数据而不是数据到您的逻辑(MapReduce的基本基础)。

您应该知道，我相信您也知道，GemFire是一个键值存储，因此将一个复杂的对象图映射到不同的区域并不是一个简单的问题。将对象按照引用(特别是多对多)划分，并准确地知道什么时候应该急切地加载它们，这是一个重载的问题，特别是在存在一致性和可用性权衡的分布式复制数据存储(如GemFire )中。

有不同的API和框架来简化持久化和使用GemFire查询。更值得注意的方法之一是Spring的抽象的扩展。

它也可能是一个问题，使用正确的数据模型的工作。如果您有非常复杂的数据关系，那么使用图形数据库(如Neo4j)创建分析模型可能是一个更简单的选择。Spring还为由支持团队领导的Neo4j提供了很好的Neo4j。

毫无疑问，您所做的任何设计选择都将毫无疑问地涉及到一种混合方法。通常情况下，路径是不明确的，因为它确实“依赖”(即取决于应用程序和数据访问模式，加载，所有这些)。

但有一件事是肯定的，确保您对底层数据存储及其数据管理功能有很好的粗略了解和理解，特别是在一致性和可用性方面，从这开始。

注意，还有一个GemFire松弛信道和一个Apache DEV邮件列表，您可以使用它们来联系(高级) GemFire/Geode用户的GemFire专家和社区，如果您在进行这个架构设计过程中有更具体的问题的话。