Как стать автором
Обновить

Комментарии 18

Как-то вообще ни о чем. Да и зачем-то ruby был приплетен.
Руби был «приплетен» по простой причине — все проекты написаны на нем.
И при чем здесь «производительность Redis»?
Поясню. Одна база редис просто не справляется с потоком данных на запись и чтение. Поэтому одно из решение распараллелить данные на несколько баз с помощью кластера. Что даст кластер из нескольких баз редис описано в статье. Так же приведена ссылка на пример простого реализованного кластера.
Спасибо за ссылки
Автор, вы конечно молодец, но есть более правильное решение, чем велосипед, которое разработчик редиса рекомендовал в своем блоге 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
Что мешает завести 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 и все это будет из коробки!
Ну вообще-то я имел ввиду шардирование twemproxy на уровне application (как у Вас, только не напрямую к редисам). Кстати решение шардировать редисы напрямую на уровне application тоже не балансирует нагрузку.
UPD: CPU на twemproxy действительно будет «уходить», это аргумент против него.
>> Кстати решение шардировать редисы напрямую на уровне application тоже не балансирует нагрузку.

Почему не балансирует нагрузку? Если данных много, то мы можем допустить, что они равномерно распределены между базами. И следовательно количество операций чтения-записи увеличивается пропорционально количеству баз в кластере.
В частном случае да, однако, что если десятку машин с редисом уже по 5 лет, а другой десяток установлен вчера? Вот, принцип равномерного распределения нагрузки уже не работает. Не факт правда, что twemproxy это учитывает…
Согласен с вами, но в статье я как раз и обращаю внимание, что кластер удобно запустить для новой базы, а для старой очень сложно мигрировать данные на новые машины в кластере.
> практически в каждой статье ей посвященной, мы встречаем утверждение о том, что эта база невероятно быстро работает.

Подскажите, а «невероятно быстро», это какое самое быстрое время на операцию подключения и получения значения простого скалярного ключа?
Мне не удалось сделать это быстрее, чем 1 миллисекунда. При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее. Тесты проводились на средненьком VDS с 2мя ядрами и 500 МБ оперативной памяти.
Просто не надо тратить время на подключение каждый раз. Один инстанс редиса у нас на бою начинает себя не очень хорошо чувствовать на 50-90 Krps. И, возможно, при использовании файлового хранилища Вы тестировали прямой доступ к локальный памяти (обращаясь в кэш файловой системы).
Смысл использования nosql-решений всегда один — справиться с большими нагрузками. Поэтому справедливо замечание tumbler о том, что не надо каждый раз открывать соединение при запросе значений. Открыли соединение и используем его.

>> При использовании для аналогичных целей простого файлового хранилища на локальной машине это время колеблется в порядке микросекунд, т.е. значительно быстрее.

Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая — данных раздаваемых из файловой системе мало и они закешировались в оперативке. И то в этом случае скорость будет сопоставима, но не быстрее.
> Просто не надо тратить время на подключение каждый раз.

Разумеется, при каждом получении ключа отдельного подключения не происходит, но совсем без подключения к редису не обойтись. Хотя бы одно подключение в одном процессе есть, поэтому оно тоже влияет на время работы и должно рассматриваться.
Или у вас каким-то образом создаётся подключение к redis, расшаренное между процессами? Если да, то научите.

> Либо у вас тестирование было на небольшом количестве данных, либо очень специфическое. Все прекрасно понимают, что файловая система не может отдавать данные быстрее оперативной памяти, за исключением одного случая

Я это тоже понимаю, отчасти поэтому меня и удивляют мои результаты и разочаровывает то, что редис пока не оправдывает ожиданий.
Именно поэтому я и спрашивал — какой скорости удалось добиться другим, чтобы сравнить. И кстати этот вопрос — о скорости получения ключа пока что так и остался без ответа. Зато некто, вероятно, очень мудрый, минуснул. Я что оскорбил чьи-то религиозные чувства, рассказав о своем опыте и задав вопрос? :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.