redis optimization
Friday, 12 August 2011 20:04![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Пример раз:
Это довольно медленно, на самом деле, когда ключиков для обработки сотни тысяч. Профайлинг показывает, что половина времени уходит на геты, процентов десять на делит, и остальное - на собственно процессинг и забрасывание в mysql.
А вот пример два:
Получается ощутимо быстрее. На порядки. Доля времени на работу с редисом оказывается где-то в районе погрешности измерений.
Остаётся keys("prefix*"), который довольно медленный. Больше того, его в продакшене использовать категорически не рекомендуют. Ну что ж, в редисе есть отличные дататайпы значений - листы, хэши и сеты.
HKEYS или даже HGETALL будет быстрее keys("prefix*"), потому что последний требует сравнения строк. Или, скажем, LPOP до заполнения массива, а потом всё тот же MGET.
keys = redis.keys("prefix*")
for k in keys:
v = redis.get(k)
process(k, v)
redis.delete(k)
Это довольно медленно, на самом деле, когда ключиков для обработки сотни тысяч. Профайлинг показывает, что половина времени уходит на геты, процентов десять на делит, и остальное - на собственно процессинг и забрасывание в mysql.
А вот пример два:
keys = redis.keys("prefix*")
while keys:
pk = keys[:10000]
keys = keys[10000:]
toprocess = zip(pk, redis.mget(pk))
for (k, v) in toprocess:
process(k,v)
redis.delete(*pk)
Получается ощутимо быстрее. На порядки. Доля времени на работу с редисом оказывается где-то в районе погрешности измерений.
Остаётся keys("prefix*"), который довольно медленный. Больше того, его в продакшене использовать категорически не рекомендуют. Ну что ж, в редисе есть отличные дататайпы значений - листы, хэши и сеты.
HKEYS или даже HGETALL будет быстрее keys("prefix*"), потому что последний требует сравнения строк. Или, скажем, LPOP до заполнения массива, а потом всё тот же MGET.