Comments 18
Как-то вообще ни о чем. Да и зачем-то ruby был приплетен.
Эта проблема давным давно решена — antirez.com/news/44, github.com/sreeix/redis-proxy
Автор, вы конечно молодец, но есть более правильное решение, чем велосипед, которое разработчик редиса рекомендовал в своем блоге github.com/twitter/twemproxy
Честно говоря решение очень спорное. Производительность twemproxy схожа с самим редисом. И в редисе и в twemproxy используется всего 1 event-loop с epoll. И если вы упираетесь по количеству операций в секунду, то однопоточный twemproxy никак не поможет, а только увеличит latency.
twemproxy имеет смысл использовать только если асимптотическая сложность операций больше чем O(1). Ну или имеет смысл использовать когда у вас просто большие базы, которые надо расшардировать, и пока еще ops не является узким местом.
Когда ops достигает значений 150-200Krps, то решать можно только:
a) pipeline
b) application sharding
c) redis cluster
twemproxy имеет смысл использовать только если асимптотическая сложность операций больше чем O(1). Ну или имеет смысл использовать когда у вас просто большие базы, которые надо расшардировать, и пока еще ops не является узким местом.
Когда ops достигает значений 150-200Krps, то решать можно только:
a) pipeline
b) application sharding
c) redis cluster
Что мешает завести N идентичных twemproxy и шардировать на них запросы методом, указанным в статье?
Тем что надо как-то балансировать нагрузку на несколько инстансов twemproxy? Как? IPVS? HAPROXY? И что в итоге получается, сколько прыжков надо делать? Аж 3! haproxy <-> twemproxy <-> redis
И заметьте, в каждом процессе свой eventloop, и фактически на те же 200Krps мы будем тратить уже 3 физических ядра (по каждому на redis/twemproxy/haproxy), вместо одного для redis, если шардирование будет на уровне приложения.
Если упираетесь по ops, и база маленькая, проще на одной тачке поднять N инстансов redis, и шардироваться между ними на уровне application.
Да, нужно потратить некоторое время, и не все можно расшардировать (н-р работу с set/zset/list), но производительность и эффективность решения будет значительно выше.
Впрочем, redis cluster скоро будет stable и все это будет из коробки!
И заметьте, в каждом процессе свой eventloop, и фактически на те же 200Krps мы будем тратить уже 3 физических ядра (по каждому на redis/twemproxy/haproxy), вместо одного для redis, если шардирование будет на уровне приложения.
Если упираетесь по ops, и база маленькая, проще на одной тачке поднять N инстансов redis, и шардироваться между ними на уровне application.
Да, нужно потратить некоторое время, и не все можно расшардировать (н-р работу с set/zset/list), но производительность и эффективность решения будет значительно выше.
Впрочем, redis cluster скоро будет stable и все это будет из коробки!
Ну вообще-то я имел ввиду шардирование twemproxy на уровне application (как у Вас, только не напрямую к редисам). Кстати решение шардировать редисы напрямую на уровне application тоже не балансирует нагрузку.
UPD: CPU на twemproxy действительно будет «уходить», это аргумент против него.
UPD: CPU на twemproxy действительно будет «уходить», это аргумент против него.
>> Кстати решение шардировать редисы напрямую на уровне application тоже не балансирует нагрузку.
Почему не балансирует нагрузку? Если данных много, то мы можем допустить, что они равномерно распределены между базами. И следовательно количество операций чтения-записи увеличивается пропорционально количеству баз в кластере.
Почему не балансирует нагрузку? Если данных много, то мы можем допустить, что они равномерно распределены между базами. И следовательно количество операций чтения-записи увеличивается пропорционально количеству баз в кластере.
> практически в каждой статье ей посвященной, мы встречаем утверждение о том, что эта база невероятно быстро работает.
Подскажите, а «невероятно быстро», это какое самое быстрое время на операцию подключения и получения значения простого скалярного ключа?
Мне не удалось сделать это быстрее, чем 1 миллисекунда. При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее. Тесты проводились на средненьком VDS с 2мя ядрами и 500 МБ оперативной памяти.
Подскажите, а «невероятно быстро», это какое самое быстрое время на операцию подключения и получения значения простого скалярного ключа?
Мне не удалось сделать это быстрее, чем 1 миллисекунда. При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее. Тесты проводились на средненьком VDS с 2мя ядрами и 500 МБ оперативной памяти.
Просто не надо тратить время на подключение каждый раз. Один инстанс редиса у нас на бою начинает себя не очень хорошо чувствовать на 50-90 Krps. И, возможно, при использовании файлового хранилища Вы тестировали прямой доступ к локальный памяти (обращаясь в кэш файловой системы).
Смысл использования nosql-решений всегда один — справиться с большими нагрузками. Поэтому справедливо замечание tumbler о том, что не надо каждый раз открывать соединение при запросе значений. Открыли соединение и используем его.
>> При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее.
Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая — данных раздаваемых из файловой системе мало и они закешировались в оперативке. И то в этом случае скорость будет сопоставима, но не быстрее.
>> При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее.
Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая — данных раздаваемых из файловой системе мало и они закешировались в оперативке. И то в этом случае скорость будет сопоставима, но не быстрее.
> Просто не надо тратить время на подключение каждый раз.
Разумеется, при каждом получении ключа отдельного подключения не происходит, но совсем без подключения к редису не обойтись. Хотя бы одно подключение в одном процессе есть, поэтому оно тоже влияет на время работы и должно рассматриваться.
Или у вас каким-то образом создаётся подключение к redis, расшаренное между процессами? Если да, то научите.
> Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая
Я это тоже понимаю, отчасти поэтому меня и удивляют мои результаты и разочаровывает то, что редис пока не оправдывает ожиданий.
Именно поэтому я и спрашивал — какой скорости удалось добиться другим, чтобы сравнить. И кстати этот вопрос — о скорости получения ключа пока что так и остался без ответа. Зато некто, вероятно, очень мудрый, минуснул. Я что оскорбил чьи-то религиозные чувства, рассказав о своем опыте и задав вопрос? :)
Разумеется, при каждом получении ключа отдельного подключения не происходит, но совсем без подключения к редису не обойтись. Хотя бы одно подключение в одном процессе есть, поэтому оно тоже влияет на время работы и должно рассматриваться.
Или у вас каким-то образом создаётся подключение к redis, расшаренное между процессами? Если да, то научите.
> Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая
Я это тоже понимаю, отчасти поэтому меня и удивляют мои результаты и разочаровывает то, что редис пока не оправдывает ожиданий.
Именно поэтому я и спрашивал — какой скорости удалось добиться другим, чтобы сравнить. И кстати этот вопрос — о скорости получения ключа пока что так и остался без ответа. Зато некто, вероятно, очень мудрый, минуснул. Я что оскорбил чьи-то религиозные чувства, рассказав о своем опыте и задав вопрос? :)
Sign up to leave a comment.
Увеличение производительности Redis с помощью простого кластера