Redis 集合的替代品

Question

所以要设置这个，我有一家公司，我们有用户和一组标签来描述这些用户。 每个用户最多可以附加 5000 个标签。

我们有一个引擎，允许客户选择某些标签来组成一个标签组。该引擎具有 AND/Or 功能和 Include/Exclude。客户可以创建一个标签组，我们的引擎会找到满足标签组中指定的逻辑要求的用户总数。基本上这只是交集、联合和排除，所以 redis 集已经很完美了。

为了处理这个问题，我存储数据。 标签1：[用户1，用户2，用户3] 标签2：[用户1，用户5，用户6] 等等

从这里开始，所有的布尔逻辑都是使用脚本完成的。

但是，我们的客户群正在迅速扩大。几年之内，我们要么需要几个 64GB redis 服务器，要么需要一个替代方案。

这是我的问题。是否有任何闪电般快速的数据库选项来进行基于磁盘的相交和联合？我尝试过 Postgres，但性能无法接受。例如，对 500k 用户集进行集比较需要 1 秒。在 Postgres 中，我看到大约 30 秒，如果标签组中有很多标签，则更多。

我已经推荐过 DynamoDB 和其他一些人，但我只是想在深入挖掘之前获得一些有根据的意见。

谢谢， 丹

Answer 1

很抱歉对这么老的问题发表评论。

我确信速度不会像 redis 那样低，但我想提一下“标签”和“标签组”的 2 个 postgres 功能

Ltree 是一种用于创建类别层次结构的便捷语法：（支持全文搜索） http://www.postgresql.org/docs/9.1/static/ltree.html

而且（我没用过这个）hstore 是一个标签实现 http://www.postgresql.org/docs/9.0/static/hstore.html

我相信，如果您能巧妙地使用这些工具（并构建正确的索引），您应该能够将查询时间降低到一个合理的值。

Answer 2

“Lightning fast DB”和“disk based”并不真正兼容。最快的存储是内存存储。

除了使用 intset 之外，另一个可能的优化是将集合表示为位图。这完全取决于数据的基数，但假设用户数量的增长速度快于标签数量，那么每个标签都有一个位图可能会很有趣。在位图中，给定的位由用户的数字 ID 索引。

Redis 2.6 正是为此目的支持 SETBIT、BITOP 和 BITCOUNT 操作。

如果每个用户使用一个位，则 500K 用户需要不到 64K，乘以全球标签数。我怀疑你会发现它比使用 intset 更紧凑。

Answer 3

Redis 是获得快速交集和联合的最佳方式。你可以做一些事情来限制 Redis 使用的内存：

使用整数集

在内部，Redis 使用数据结构IntSets。这是一个排序的整数数组。要在这个集合中找到一个整数，复杂度是 O(log N)。 IntSet 有三种风格——16 位、32 位和 64 位。

从内存的角度来看，Int Sets 是非常理想的。如果你使用集合并且关心内存，你应该确保你使用的是 Int Sets。

要利用 Int Sets，您需要做两件事 -

1. 确保集合包含整数。如果您的用户 ID 是字符串，则您必须稍微更改逻辑以使其成为整数。
2. 在 redis.conf 中，将设置set-max-intset-entries 更新为合理的数字。这将是给定标签的最大用户数。请注意，将其增加超过一个点实际上会降低性能。

将用户对象移动到另一个商店

这些集合只需要用户 ID，不需要整个用户对象。因此，如果内存成为限制，您还可以将用户对象移动到另一个数据存储区。也许是另一个 Redis 服务器，甚至是一个关系数据库。这种方法可以让您两全其美。