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 ()

Суки, кластер всё-таки выпилили, нафиг редис тогда нужен вообще без горизонтального масштабирования?

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

Суки, кластер всё-таки выпилили, нафиг редис тогда нужен вообще без горизонтального масштабирования?

Может прощупывают почву на тему Redis Enterprise Edition с кластеризацией и прочими нишняками? Ну а бесплатно только птички поют. И то с оговорками.

rtvd ★★★★★ ()

Наконец-то! вот он! долгожданный релиз!

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

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

menangen ★★★★★ ()

Я вот у них в доке так и не понял как работает мастер-слейв репликация. К примеру, есть один сервак с мастером и куча серваков-слейвов. Может ли приложение работающее на серваке со слейвом отправлять запросы на запись именно локальному слейву? А тот, в свою очередь, будет их кешировать и отправлять на мастер после чего данные расползутся по всем слейвам. Т.е., прозрачна ли работа с хранилищем с точки зрения приложения, либо нужно «учить» приложение читать со слейва а писать только в мастер?

По сабжу, годно!

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

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

trashymichael ★★★ ()

Ждем пакетный менеджер для lua-библиотек и встроенный вебсервер

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

А для чего встроенный вер-сервер? Какие операции это может улучшить?

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

можно будет выкинуть node.js, очевидно же.

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

пакетный менеджер для lua-библиотек

luarocks

встроенный вебсервер

openresty

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

Это-то понятно, что путь к данным станет короче. Мне интересно, на сколько это оправдано с точки зрения конечной производительности? Ведь при такой схеме, когда 1 БД приходится на 1 ВебСервер, у нас гораздо меньше свободы в выборе схемы масштабирования.

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

Да не, я прикалываюсь. Щаз народ имеет свойство шизовать на ровном месте и делать свой проект пупом вселенной :)

Предлагаю устроить срач на тему redis vs tarantul. Вроде тарантул весьма годен, но маркетинга нет, пробовать сцыкотно.

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

Ну многие редиску юзают как продвинутый мемкеш

интересное мнение. скажите, а что именно при таком подходе обычно хотят от редиса, чего нету в мемкешд?

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

От него за много лет уже понятно чего ожидать. А новые продукты - всегда кот в мешке.

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

В основном, предсказуемого времени хранения данных и немного логики.
Сессии, очереди, счетчики, блокировки, фильтры leaky-buckets и т.п.

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

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

Сессии, очереди, счетчики, блокировки, фильтры leaky-buckets и т.п.

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

Иными словами, хочется иметь структуры данных a-la STL, но в «персистентном» и разделяемом варианте?

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

Я не свосем вкурсе - я сам работаю только с редис, но не с мемкеш. Думаю, основа в том, что редис - полноценное хранилище, пишет инфу на диск, делает это быстро. А мемкеш (именно мемкеш, а не мемкешдб) юзают только для кешей из бд.

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

т.е. если нужно полноценное хранилище, а не просто кеш? соответственно, сравнение с мемкеш в корне неуместно?

val-amart ★★★★★ ()
Ответ на: комментарий от menangen

иными словами, его НЕ используют как мемкеш, просто для кеширование и персистентности и поэтому говорить что его используют как продвинутый мемкеш некорректно?

val-amart ★★★★★ ()

А он наконец-то научился масштабироваться или всё так же однопоточный?

kkk ★★ ()
Ответ на: комментарий от val-amart

Ну его под кеш тоже используют, «чтобы два раза не бегать». Удобно же. Уместность сравнения оценивайте сами.

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

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

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

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

За юзкейзами редиса лучше на их сайт прогуляться. Нужно ли это лично вам - сами смотрите.

Лично мне нужно такое, что Redis и в кошмарном сне не снилось :) Мне просто интересно, что понимают под «data structure server», люди которые пытаются это решение использовать на практике.

PS. Я Redis не критикую, я просто хочу разобраться.

aist1 ★★ ()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

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

Если задача не затачивается под дикие хайлоады, то обычно редиску втыкают как шареную хранилку состояний, счетчики, кеш, task queue и message bus. Пока проект не распух до уровня фейсбука, обходится одной редиской практичнее и для программирования и для поддержки.

Например, я делаю сраненький опенсорный форум :) . Если в требованиях будет указано, что надо поднять кассандру, мемкешед, ampq, зоокипер и т.п., то его вообще никто не попытается поставить. А если ноджежс, монго и редиска - то всё чодка и панятна.

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

Спасибо за разъяснение)

Например, я делаю сраненький опенсорный форум :)
А если ноджежс, монго и редиска - то всё чодка и панятна.

Кстати, если не влом, для чего здесь будет монго, а для чего редиска?

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

Монга для хранения «всего», вместо мускуля - просто поразвлекаться захотелось, как и с нодой. Редиска - для того что перечислял выше. Несмотря на персистентность редиски, ее данные рассматриваются как те, которые не критично потерять. Бакапиться проще и т.п.

Ну и есть специфичные штуки вроде «кто просматривает эту страницу». Там и персистентность пофик, и апдейты дикие. На монге такое делать очень грустно, а сиквелы вообще колом встанут. В редиске - обычный ZSET + EXPIRE.

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

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

Интересно, на сколько это удобно в приложениях уровня «сраного форума» (когда в случае частичной потери данных с последнего снэпшота никто душу вынимать не придет) обойтись только Редисом?

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

Это хранилища с абсолютно разными структурами данных, под разные задачи. Их нельзя так сравнивать. Поэтому у меня стоит и то и другое, для сбалансированного потребления ресурсов.

Форум теоретически на редисе запилить можно, если сильно произвращаться, но зачем? Во-первых, наверняка некоторые сортировки по статусам постов и тредов накроются. Во-вторых, частые обращения актуальны только для свежих данных, а остальные будут просто занимать память. В третих, мне удобно аттачменты в монге хранить, а тут ни какой памяти не хватит. Но если я начну в монгу напрямую апдейты всех счетчиков лепить - диск же треснет.

Заменять носкули и сиквели редиской целиком есть смысл только диком количестве запросов, если данные на сеты и kv хорошо ложатся. Например, в reddit вроде целиком все в редиску засунули. Но им деваться уже некуда.

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

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

Ага, Redis ведь только in-memory. Это я упустил из виду.

Т.е. все эти in-memory хранилища нужны лишь как продвинутые версии кэшей? Я близок к истине?

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

«навернутый кеш» - слишком мутный термин. При желании можно и обычную базу навернутым дисковым кешем обозвать. in-memory хранилища нужны для задач, где частые обращения к диску не приемлимы. Никто не мешает там данные целиком хранить, если надо. Наберите в гугле «redis usage patterns», примеров же навалом.

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

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

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

«навернутый кеш» - слишком мутный термин. При желании можно и обычную базу навернутым дисковым кешем обозвать.

Я имел в виду именно кэширование в памяти. Под навернутостью понимается возможность исполнять скрипты на стороне хранения данных.

Я покурил мануалы, Redis на мой взгляд выглядит плохо сбалансированным решением. Однопоточный, снэпшоты через fork(), огромный оверхед по данным в отнюдь не бесплатной памяти. То, что при всём при этом народ вышеозначенными проблемами ни сколько не заморачивается, ставит вопрос о том, что людям вообще реально нужно?

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

Ну это вполне разумно, если размер рабочего множества примерно равен размеру всего датасета. Вполне реалистичный сценарий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Korwin ★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от Korwin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кстати чем боретесь колбеками? Я сейчас частенько использую async, но может есть ещё какие, более кошерные вещи, какие-нибудь обертки над fiber.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DarkFlame ★★ ()

moot.it

читайте в их блоге про технологии которые они использовали при построении своего сервиса, там в том числе и про redis. Вообще я впечатлен интерактивностью сервиса.

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

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

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

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

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

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

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

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

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

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

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

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