python - 使用流水线 hgetall 进行 Redis 慢速查询

Question

所以我有一个小而简单的 Redis 数据库。它包含 136689 个键，其值是包含 27 个字段的哈希映射。我通过服务器节点上的 Python 接口(interface)访问表，每次调用需要加载大约 1000-1500 个值(最终我会看到每秒大约 10 个请求)。一个简单的调用如下所示:

# below keys is a list of approximately 1000 integers, 
# not all of which are in the table

import redis
db = redis.StrictRedis(
  host='127.0.0.1',
  port=6379,
  db=0,
  socket_timeout=1,
  socket_connection_timeout=1,
  decode_responses=True
)

with db.pipeline() as pipe:
  for key in keys: 
    pipe.hgetall(key)
  results = zip(keys,pipe.execute())

总时间约为 328 毫秒，每个请求的平均时间约为 0.25 毫秒。

Question: This is very slow for a small database and relatively few queries per second. Is there something wrong with my configuration or the way I'm calling the server? Can something be done to make this faster? I don't expect the table to get much bigger so I'm perfectly happy sacrificing disk space for speed.

附加信息

调用 hget每个键(没有管道)上的速度较慢(如预期的那样)并显示时间分布是双峰的。较小的峰值对应于不在表中的键，较大的峰值对应于表中的键。



我的conf文件如下:

port 6379
daemonize yes 
save ""
bind 127.0.0.1
tcp-keepalive 300 
dbfilename mytable.rdb
dir .
rdbcompression yes 

appendfsync no
no-appendfsync-on-rewrite yes 
loglevel notice

我启动服务器:

> echo never > /sys/kernel/mm/transparent_hugepage/enabled
> redis-server myconf.conf

我还用 redis-cli --intrinsic-latency 100 测量了内在延迟。这使:

Max latency so far: 1 microseconds.
Max latency so far: 10 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 12 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 32 microseconds.
Max latency so far: 34 microseconds.
Max latency so far: 38 microseconds.
Max latency so far: 48 microseconds.
Max latency so far: 52 microseconds.
Max latency so far: 60 microseconds.
Max latency so far: 75 microseconds.
Max latency so far: 94 microseconds.
Max latency so far: 120 microseconds.
Max latency so far: 281 microseconds.
Max latency so far: 413 microseconds.
Max latency so far: 618 microseconds.

1719069639 total runs (avg latency: 0.0582 microseconds / 58.17 nanoseconds per run).
Worst run took 10624x longer than the average latency.

这表明我应该能够获得更好的延迟。但是，当我使用以下命令检查服务器延迟时: > redis-cli --latency -h 127.0.0.1 -p 6379我得到 min: 0, max: 2, avg: 0.26 (2475 samples)
这似乎表明 ~0.25ms 是我的服务器的延迟，但这似乎表明我从 Python 看到的每个请求的延迟与 CLI 相同，但这一切似乎都非常缓慢。

与每个键关联的哈希图(解码后)的大小约为 1200 字节。所以我运行了以下基准

redis-benchmark -h 127.0.0.1 -p 6379 -d 1500 hmset hgetall myhash rand_int rand_string
====== hmset hgetall myhash rand_int rand_string ======
  100000 requests completed in 1.45 seconds
  50 parallel clients
  1500 bytes payload
  keep alive: 1

100.00% <= 1 milliseconds
100.00% <= 1 milliseconds
69060.77 requests per second

这似乎支持我的延迟非常高，但并没有真正告诉我原因。

Answer 1

我从使用 Redis 的方式中得出的一个结论是，我们不应该将每个事务存储在一个哈希中。就像在一个交易中一样，一个哈希。

对于每个 hget 请求，我们都有一个网络连接会减慢查询速度。

我认为 Redis 的设计方式是将所有内容存储在一个哈希中会更快，就像在同一哈希下的所有事务一样。

此外，粒度数据可以作为 JSON 存储在每个 key:values 中。

我检索所有散列的时间与检索存储在一个散列中的所有值的时间是 140mb 的数据:

3 秒迭代每个哈希并获取其键:值
对比

0,008 秒获取一个散列然后在该散列中搜索一个键:值，
对比

0,008 秒获取存储在一个哈希下的所有数据。

而不是在您的 for 迭代中进行 1 000 000 000 次迭代(如果您有 1 000 000 000 个哈希值)，在这里使用建议的解决方案您只有 1 次(如果您可以根据内在值(value)分离数据，则更多)，因此显着减少查询时间。