LINUX.ORG.RU

Redis 2.8.0

 


3

6

Спустя почти год с момента предыдущего стабильного релиза наконец-то вышел долгожданный Redis 2.8.0, быстрое и легкое масштабируемое хранилище данных вида ключ:значение с продвинутыми структурами данных (строки, списки, множества, отсортированные множества), методами доступа к ним и внутренним скриптовым движком на Lua.

Основные изменения:

  • Оптимизированный процесс повторной синхронизации между мастером и слейвом после восстановления потерянной связи между ними. Проще говоря, теперь слейву не будет передаваться весь объем данных, как это было раньше, а лишь необходимая их часть.
  • Итерация с возможностью regexp-отбора и заданием максимального количества возвращаемых значений по всему массиву ключей, а также элементов списков, множеств и отсортированных множеств - с помощью команд SCAN, SSCAN, HSCAN, ZSCAN.
  • Оповещения по протоколу Pub/Sub о событиях, происходящих в данном пространстве имен. Например, можно подписаться на уведомление об удалении ключа по событию expire, а также практически на любые из многочисленных событий вокруг операций с данными. Это очень важное, самое обсуждаемое и долгожданное нововведение в Redis за последние годы.
  • Улучшена целостность Redis-кластеров (мастер перестает делать новые записи при обнаружении большого числа запаздывающих на ним слейвов и ждет момента их готовности).
  • Полная поддержка IPv6.
  • Улучшена скорость работы скриптов на Lua.
  • Оптимизирован алгоритм отсчета времени жизни ключей.
  • Полностью переписан и обновлен Redis Sentinel (средство мониторинга redis-кластеров).
  • Из поставки исключен Redis Cluster, который теперь выделен в отдельную ветку разработки и ждет своего собственного релиза. Redis Cluster - это тот же самый Redis, но с большим упором на распределенность и большое число узлов.

Скачивайте обновленные пакеты и тестируйте Redis 2.8.0 для применения в своих системах!

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Ответ на: комментарий от Vit

...скандальными разоблачениями про однопоточность...

Ты выше уже сказал, что Редис - это не база данных. Это именно база данных по функциональной нише, только разработчики стремятся оставить её топорно простой. Память она транжирит. Многопоточность не осилили и переложили проблему на плечи разработчиков.

Свое место в истории у Редиса есть, но свою работу он делает плохо. Просто другие его работу делают еще хуже. Вот такая беда у нас с технологиями.

лучше заниматься без меня

Да, это уже философские вопросы пошли. В чем состоит феномен Редиса?

aist1 ★★★
()
Ответ на: комментарий от aist1

Я вам приводил вагон примеров, где использование редиса радикально снижает disk io, по сравнению с другими решениями. Или заметно упрощает код. А рассуждения про «своя работа делает плёха» - это болтовня ни о чем.

Если удобных альтернатив нет, о чем тогда разговор? Если есть - называйте, и будем говорить о конкретных вещах.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Это тебе кажется, что ты мне вагон примеров привел, а на самом деле ты меня в Гугл послал. Я был там.

Редис не снижает disk io. Он его просто не выполняет. Disk I/O снижает Кассандра за счет того, что использует LSM-дерево, оптимизированное на запись.

Если мы отключим fsync в PostgreSQL, то тоже можем получить очень неплохую производительность на простых запросах и небольших датасетах. Но не на столько впечатляющую, как в Redis (так как оверхед структур данных для внешней памяти будет сказываться). Для любителей даже есть конфигурации MySQL, оптимизированные для такого режима работы. Это к вопросу об альтернативах.

Но не в них дело. Феномен Редиса, как я понимаю, в соотношении функционала и сложности. Редис прост как три копейки, а поэтому понятен даже новичку. Отсюда и кажущееся упрощение кода.

PS. Альтернативы, кому интересно.

PPS. Немного удивляюсь, почему еще не сделали обертку типа Редиса над вот этой STL-подобной библиотекой структур данных для внешней памяти.

aist1 ★★★
()
Ответ на: комментарий от aist1

Вы невнимательно читали. Я вам приводил вполне конкретные кейзы тут Redis 2.8.0 (комментарий) и тут Redis 2.8.0 (комментарий)

Прикиньте сами, во что обойдется их реализация на других базах. Плюс в нагруженных проектах, если данные нормально ложатся на редисовские структуры, получаются RPS от 100К на одной машине. Мне такие большие RPS не нужны, зато я редисом заметно упрощаю часть кода и снижаю нагрузку на диск. В итоге можно на одном сервере обслуживать весьма большие форумы и не напрягаться при разработке. И при этом все неплохо шардится. Другие решения потребовали бы либо больше серверов либо заметно больше возни с софтом (и по установке/поддержке, и по программированию).

Единственной адекватной альтернативой редису пока является только tarantool db. Но он пока слишком слабо раскручен, и совершенно непонятно, какие подводные камни всплывут в продакшене.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Вы невнимательно читали.

Это была пара примеров, но никак не тонна :)

Прикиньте сами, во что обойдется их реализация на других базах.

Совершенно верно, годный аргумент. Редис просто есть и просто делает своё дело, дешево и сердито. Реализация на других базах может оказаться не такой уж и геморройной, но её придется делать. Т.е. это трудозатраты. И сопровождать. Это тоже трудозатраты.

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

Не самим Редисом, а тем фактом, что можно пренебречь надежностью хранения данных. Редис просто в это допущение вписывается идеально.

Единственной адекватной альтернативой редису пока является только tarantool db. Но он пока слишком слабо раскручен...

Вот-вот, раскрутка. Могут быть и другие решения, только о них мало кто знает.

aist1 ★★★
()
Ответ на: комментарий от aist1

Память она транжирит.

В этой версии как раз по этому поводу оптимизации.

Многопоточность не осилили

Выкинута сознательно. Почитайте, что это им дало.
Спорить тоже не охота.

Redis не нужно рассматривать как классическую БД или классический кэш.

Это инструмент, заточенный для определенных кейсов (счетчики, спец. схемы данных, огромное количество записей с конкурентным чтением, гарантированное по времени выполнение операций). На сайте разработчиков все хорошо расписано.

Korwin ★★★
()
Ответ на: комментарий от Korwin

Ребята, мне серьезно не нравится роль адвоката дьявола в отношении Редис, но так уж получилось. Давайте проясним ситуацию.

Многопоточность не осилили

Выкинута сознательно. Почитайте, что это им дало.

Не нашел именно этого места, но могу предположить, исходя из косвенных данных. Итак, давайте по порядку...

1. Редис внутри использует простейшие списковые структуры данных образца 70-х годов прошлого века. Именно этим объясняется большая избыточность по памяти и, как считается, это должно обеспечить максимальную производительность. Но для современных архитектур это не так, b-tree оказывается быстрее rb-tree, когда размер датасета на много больше размера кэш-памяти. Т.е. «сложнее» сейчас вовсе не значит «медленнее».

2. Простоты ради не стали делать даже поддержку журналирования для внутренних структур данных. Типа нехватки памяти не может случиться. Даже из-за фрагментации памяти. Пусть они уверены, что структуры данных из их скудного набора не рассыпятся при нехватке памяти, но для более сложных структур, когда они понадобятся, это не так. Замучаются разрабатывать. Журналирование не от хорошей жизни придумали, оно сильно упрощает обработку ошибок при дизайне сложных структур данных.

3. То же самое с многопоточностью. То, что проблема эта не решена в общем виде не значит, что нет частных решений.

3а) Если бы они использовали структуры данных для внешней памяти, то ДА, они плохо параллелятся без сложных надстроек типа журналирования и MVCC. И эти надстройки (особенно MVCC) вносят довольно большой оверхед, что отрицательно скажется на однопоточной производительности.

3б) Но они используют структуры данных для основной памяти. Здесь есть решения типа lock-free и для множеств, и для списков. И даже на блокировках можно было бы что-нибудь хитрое придумать. libcds всё умеет.

3в) Но даже если не хочется иметь дело с lock-free, можно сделать внутренний шардинг и уже поверх него уже организовать логический уровень пользовательских структур данных. Не так уж это и сложно. Да, это внесет дополнительный уровень, снизит скорость, но...

4. Они говорят, что во многих конфигурациях узким местом является сеть. В сети не получить больше нескольких десятков тысяч подтвержденных запросов без пайплайнинга. Так зачем все эти танцы вокруг «простых, но очень быстрых структур данных», если бутылочное горлышко всё равно сеть?

Вот это я и называю плохо согласованной архитектурой, возникшей из-за преждевременных оптимизаций.

Да, своя ниша у Редиса есть, и в ней он себя чувствует очень неплохо. Все довольны. Пока довольны.

aist1 ★★★
()
Ответ на: комментарий от aist1

Aist1, вы даёте много предложений «что должно быть в Redis», но не отвечаете на главный вопрос - «Зачем?» Например, зачем ему параллельность?

3а) Если бы они использовали структуры данных для внешней памяти, то ДА, они плохо параллелятся без сложных надстроек типа журналирования и MVCC. И эти надстройки (особенно MVCC) вносят довольно большой оверхед, что отрицательно скажется на однопоточной производительности.

Зачем? Особенно если ценой производительности :)

3в) Но даже если не хочется иметь дело с lock-free, можно сделать внутренний шардинг и уже поверх него уже организовать логический уровень пользовательских структур данных. Не так уж это и сложно. Да, это внесет дополнительный уровень, снизит скорость, но...

Но... что? Чтобы в результате получить что?

Если прикрутить к нему всё вышеперечисленное, многопоточность, журналирование, гарантии сохранности данных и возможности сложных запросов (ну тоже ведь прикольно), то получим ещё одну самую обычную и не быструю реализацию аналога SQL, которая никому не нужна.

Подобные проекты - предназначены для своих ниш, где и живут припеваючи.

DarkFlame ★★
()
Ответ на: комментарий от DarkFlame

Например, зачем ему параллельность?

А зачем вообще параллельность? Зачем вытесняющая многозадачность? Тут Korwin выше говорил о реальном времени. Вот для него вытесняющая многозадачность и нужна, чтобы гарантировать среднее время выполнения запроса. Redis же оптимизирован на минимальное время выполнения запроса, тогда как один долгоиграющий запрос заставит всех ждать. Это никакой не real time. Матчасть негодует.

Зачем? Особенно если ценой производительности :)

Затем, чтобы экономить дорогущую основную память. Кроме того, производительность при использовании компактных структур данных не так уж и падает. Я подробно исследовал этот вопрос. Компактные структуры данных часто быстрее на больших датасетах. А это как раз случай для хранилищ типа in-memory. Вот моё исследование. Я в итоге получил 300K/150K для произвольного чтения/записи для своего аналога K/V-хранилища. Полностью журналированного и с внутренней блочной архитектурой, оптимизированной для внешней памяти. Как в лучших домах Парыжа.

Но... что? Чтобы в результате получить что?

Там шел переход к пункту 4. Потенциал скорости Редиса ограничен и так ограничен сетью. Он оптимизирован под режим встроенного хранилища, а используется только в сетевом режиме.

Если прикрутить к нему всё вышеперечисленное, многопоточность, журналирование, гарантии сохранности данных и возможности сложных запросов (ну тоже ведь прикольно), то получим ещё одну самую обычную и не быструю реализацию аналога SQL, которая никому не нужна.

... самую обычную и не быструю реализацию аналога SQL, которая никому не нужна.

Ну не то, чтобы не нужна. Гугл наигрался со своими nosql-хранилищами и вернулся к старой доброй истине, что надежность важнее чистой скорости.

Тут выше Анонимус дал ссылку на moot.it и на их блог, где они описывают свой опыт организации кластеризованного хранилища на Redis. Судя по числам латентности операций, которые они дают для своего API, у них микросекунды Редиса превратились в кластере в миллисекунды. Вполне ожидаемо. Чтобы использовать Редис как полноценное распределенное хранилище, нужна довольно тяжеловесная надстройка. В результате чего почти все его преимущества испарятся. Не бывает простых решений сложных проблем.

aist1 ★★★
()
Ответ на: комментарий от aist1

aist, я ведь не о том, что SQL не нужен или не нужно память экономить, или не нужна никому и нигде многопоточность :)

Redis - это такая удобная штуковина, которая делает то, что умеет. Во многих применениях этого достаточно, у него своя ниша. Если лезть в другие - вырастет сложность, как его кода, так и использования.

Вы сейчас смотрите на него как на продукт другого класса. Но это не бульдозер, это лопата :)

DarkFlame ★★
()
Ответ на: комментарий от DarkFlame

Да, я понимаю это, DarkFlame. Я сам обеими руками за Редис там, где это обосновано. Т.е, как кэш над более медленным, но более структурированным хранилищем. Например, кэшировать результаты Join'ов. Просто так получилось, что в этом треде я выступаю адвокатом дьявола.

Если у меня и есть какие-то претензии к Редису, то только к тому, как разработчики позиционируют очевидные косяки его архитектуры, как очевидные достоинства.

aist1 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.