Redis SCAN - возможности оптимизации? - PullRequest
0 голосов
/ 24 марта 2020

Я довольно новичок в Redis и первоначально использовал KEYS для итераций по моему набору данных, но из того, что я могу прочитать в документах Redis худшие практики , на самом деле это не рекомендуется - особенно в больших наборах данных, содержащих много ключи, поскольку KEYS выполняет итерацию по всему набору данных, блокируя на long время, в то время как SCAN выполняет итерацию по фрагментам данных из набора данных и, таким образом, блокирует только на меньше времени, чем KEYS. Если это правильно понято, я задаюсь вопросом , есть ли способ оптимизировать итерацию SCAN , чтобы вместо случайной итерации (скажем, 10 000 данных) она повторялась бы из заданной точки.

Пример:

a1
a2
a3
b1 < --- start iterating from here instead of from a1
b2
b3

и таким образом сохранить "нас" много производительности?

1 Ответ

0 голосов
/ 25 марта 2020

Команды SCAN просматривают базу данных ha sh таблицу карт, упорядоченную по значению ha sh.

Вы контролируете, где SCAN начинается с аргумента курсора, но в лучшем случае вы можете контролировать, где это происходит. начать в ха-таблице с упорядочением ha sh. См. Redis `SCAN`: как сохранить баланс между новыми ключами, которые могут совпадать, и обеспечить конечный результат за разумное время? .

Но это довольно непрактично, поскольку хеши для Ключи можно считать псевдослучайным по отношению к самому ключу. Не похоже, что они следуют лексикографическому порядку или любому логически полезному порядку любого рода. Цель ha sh состоит в том, чтобы точно распределить ключи в хеш-таблице точно.

Так что, даже если вы попробуете SCAN 0 MATCH b1 *, реализация все равно должна go пройти через все записи ha sh таблица, чтобы выполнить полное сканирование, и, следовательно, вам нужно вызывать SCAN несколько раз, пока возвращаемый курсор не вернется к нулю.

...