具有键别名或按值搜索的键值数据库答案

【问题标题】：Key-Value database with key aliasing or searching by value具有键别名或按值搜索的键值数据库
【发布时间】：2022-01-20 17:33:42
【问题描述】：

是否有现有的内存中生产就绪的 KV 存储允许我通过多个键中的任何一个检索单个值？

假设我有数百万个具有关联主键的不可变实体。这个实体中的任何一个都可以有多个别名，最常见的情况是通过这样的别名检索实体（所有请求的 90%）。第二种常见情况是能够通过主键检索实体，然后放入新的别名记录（最后 10%）。关于这一步的一个特别之处 - 它总是由别名搜索前置，并且只有在别名搜索不成功时才会发生。整个数据集确实适合 RAM，但如果整个记录数据将跨所有别名复制，则可能不适合。我非常关心数据检索延迟，不太关心写入速度。

这可以使用 Redis 在两个顺序查找中完成，也可以通过任何 SQL/Mongodb 完成。我认为这两种方式都不是最理想的。第一个显然是因为每次搜索尝试都需要两次往返，第二个是因为延迟问题。

有什么建议吗？

【问题讨论】：

你检查Redis模块RediSearch了吗？
@GuyKorland 不，我肯定会尝试的。感谢您的建议。您知道模块是否具有与 Redis 查找相当的性能吗？
这是一个高度优化的模块，但显然如果你要运行复杂的查询，它就会有它的开销

标签： database redis key-value key-value-store

【解决方案1】：

你能做两个哈希图吗？一个去pk -> record data，另一个去alias -> pk？

另一种选择是使用某种确定性别名，这样您就可以直接在代码中从别名转到主键，而无需在数据存储中进行查找

【讨论】：

这行不通，因为在代码中检索PK是一项昂贵的操作（数百毫秒）并且需要网络往返，所以它仅用作通过别名搜索后的后备。
如何在内存中的 hashmap 中进行键查找代价高昂的操作？不涉及网络旅行？
键查找不是昂贵的操作。 PK 检索本身是昂贵的。我们手头总是有别名，但有时没有与该别名关联的此类记录，它对系统来说可能是全新的。另一方面，通过 PK 搜索总是成功的，但我们手头没有它，需要进行网络操作 + 一些昂贵的计算才能进行查找。
所以我们总是在回退到通过 PK 搜索之前通过别名进行查找。只是为了说清楚-我使用术语 PK 仅用于说明目的，因为它不是 sql 模式，所以没有 PK 之类的东西。如果您对数据是什么感到好奇：别名用于文件 url，PK 用于文件 md5 哈希。很抱歉没有在问题中描述这一点。