java - 如何在 Redis 中对复杂对象进行建模

Question

我希望使用 Redis 作为复杂数据的缓存。考虑这个例子，我想存储和检索 AssetType 数据。一个 AssetType 可以有多个 AspectType。所以，AspectType 本身是另一个实体。这些将具有多对多的关系。

当我想将 AssetType 存储在缓存中时，我希望 AspectType 存储在新的缓存中并以某种方式携带引用。因此，每个 AssetType 中都不会存储 AspectType 的重复项。基本上，结构应该是:

Cache1: AssetType
key: at1, value: {at1, sameple description, [referenceTo-asp1, referenceTo-asp2]}
key: at2, value: {at2, sameple description, [referenceTo-asp2, referenceTo-asp3]}

Cache2: AspectType
key: asp1, value: {asp1, sample description}
key: asp2, value: {asp2, sample description}
key: asp3, value: {asp3, sample description}

当我使用 JPA 通过数据库完成此操作时，这非常容易。但是，在 Redis 中是否有有效的方法来做到这一点？

Answer 1

在 Redis 中，有很多有效的方法可以做到这一点。不过，您需要做出一些设计决策。

首先，您可以为每个 AssetType 拥有一个哈希类型的 key ，或者为所有 AssetType 拥有一个哈希类型。

每个 Assets 类型一个 key :

HSET AssetType:at1 name at1 desc "sample description" aspects "asp1,asp2,asp3"
HSET AssetType:at2 name at2 desc "sample description" aspects "asp1,asp2"

您始终可以使用 SCAN 0 MATCH AssetType:* 循环访问您的 AssetType。

所有 AssetType 的一个哈希，序列化每个 AssetType，例如使用 JSON:

HSET AssetTypes at1 "{'name':'at1','desc':'sample description','aspects':['asp1','asp2','asp3']}"
HSET AssetTypes at2 "{'name':'at2','desc':'sample description','aspects':['asp1','asp2']}"

同样的决定也适用于 AspectType。这里的主要权衡是，如果您可能想要一次检索/更新一项的给定字段，或者您总是检索/更新整个项目。

然后，您使用引用的 AspectType id 来检索详细信息。

另一个设计决策是您是否将引用与主项一起存储，或者将引用存储在单独的键中。例如，您可以使用集合来存储对方面的引用:

HSET AssetType:at1 name at1 desc "sample description"
SADD AspectsPerAsset:at1 asp1 asp2 asp3

集合在这里很有用，因为它们只维护唯一的成员，从而简化了您的 CRUD 操作。

例如，这允许您获取两个或多个 AssetType 的共同点:

SINTER AspectsPerAsset:at1 AspectsPerAsset:at2 AspectsPerAsset:at3

请注意，到目前为止我们已经建立了一对多关系。这是一个article on many-to-many 。在这种情况下，您还需要维护对每个方面的 AssetType 的引用:

HSET AssetType:at2 name at2 desc "sample description"
SADD AspectsPerAsset:at2 asp1 asp2
SADD AssetsPerAspect:asp1 at2
SADD AssetsPerAspect:asp2 at2

这允许您获取给定 AspectType 的所有 AssetType、与 SINTER 共享一些方面的 AssetType，或者说具有一个或多个给定 AspectType 集的 AssetType:

SUNION AssetsPerAspect:asp1 AssetsPerAspect:asp2 at2

我试图为您说明一些模式。根据您的用例的具体情况，可能还有其他更好的选择。