Подготовлен (https://groups.google.com/forum/#!topic/redis-db/l0OXDAlwosU) релиз СУБД Redis 5.0 (http://redis.io/), относящейся к классу NoSQL-систем. Redis предоставляет похожие на Memcached функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества, а также возможностью выполнения на стороне сервера скриптов-обработчиков на языке Lua. Код проекта поставляется (https://github.com/antirez/redis) под лицензией BSD.
В отличие от Memcached, Redis обеспечивает постоянное хранение данных на диске и гарантирует сохранность БД в случае аварийного завершения работы. Исходные тексты проекта распространяются в рамках лицензии BSD. Клиентские библиотеки доступны для большинства популярных языков, включая Perl, Python, PHP, Java, Ruby и Tcl. Redis поддерживает транзакции, позволяющие выполнить за один шаг группу команд, гарантируя непротиворечивость и последовательность (команды от других запросов не могут вклиниться) выполнения заданного набора команд, а в случае проблем позволяя откатить изменения. Все данные в полном объёме кэшируются в оперативной памяти.Для управления данными предоставляются такие команды, как инкремент/декремент, стандартные операции над списками и множествами (объединение, пересечение), переименование ключей, множественные выборки и функции сортировки. Поддерживается два режима хранения: периодическая синхронизация данных на диск и ведение на диске лога изменений. Во втором случае гарантируется полная сохранность всех изменений. Возможна организация master-slave репликации данных на несколько серверов, осуществляемая в неблокирующем режиме. Доступен также режим обмена сообщениями "публикация/подписка", при котором создаётся канал, сообщения из которого распространяются клиентам по подписке.
Ключевые улучшения (https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEA... добавленные в Redis 5.0:
- Представлен новый тип данных Stream (https://redis.io/topics/streams-intro), который можно использовать для хранения данных в форме пополняемого лога. Записи с типом Stream могут открываться только в режиме пополнения, но допускается удаление произвольных элементов из лога и имеется возможность ограничения максимального размера лога, например, можно сохранять не больше N элементов с удалением самых старых записей по мере поступления новых. Предоставляются средства для отслеживания добавления новых элементов, осуществления различных выборок данных и применения Stream в качестве системы обработки сообщений.Для организации совместной обработки разных частей одного потока сообщений реализована концепция Consumer Groups, при которой сообщение может снабжаться идентификатором группы и несмотря на отправку в общий поток, получить это сообщение сможет только клиент с указанным идентификатором (например, через общий поток можно организовать распределение команд среди разных обработчиков);
- Реализованы новые API для модулей: Timers, Cluster и Dictionary;
- В дампах RDB теперь сохраняется информация об алгоритмах замещения элементов LFU (Least-Frequently Used, вытеснение на основе частоты обращения к элементу) и LRU (Least Recently Used, вытеснение на основе времени последнего обращения);
- Код управления кластером переписан с Ruby (redis-trib.rb) на Си и встроен в redis-cli (доступен через команду "--cluster");
- Реализованы новые команды ZPOPMIN (https://redis.io/commands/zpopmin) и ZPOPMAX (https://redis.io/commands/zpopmax), а также их блочные вариаеты BZPOPMIN (https://redis.io/commands/bzpopmin) и BZPOPMAX (https://redis.io/commands/bzpopmax), которые извлекают и возвращают из отсортированного набора указанное число наименьших или наибольших значений;
- Реализована вторая версия системы активной дефрагментации памяти, которая позволяет выполнять дефрагментацию налету без остановки работы, если применяется система распределения памяти Jemalloc (в Linux по умолчанию);
- Улучшена реализация алгоритма HyperLogLog (https://en.wikipedia.org/wiki/HyperLogLog);
- Расширены отчёты о состоянии памяти;- Во многие составные команды, включающие субкоманды, добавлена встроенная подсказка (субкоманда HELP);
- Проведена оптимизация для повышения производительности в условиях частого соединения и отсоединения клиентов;- Менеджер распределения памяти Jemalloc (http://jemalloc.net/) обновлён до версии 5.1;- Добавлены команды: CLIENT UNBLOCK (https://redis.io/commands/client-unblock) для досрочного снятия блокировки с соединения, выставленной при выполнении блокирующих операций (например BRPOP, XREAD, WAIT); CLIENT ID (https://redis.io/commands/client-id) для получения идентификатора текущего соединения;- Добавлена развлекательная команда LOLWUT (http://antirez.com/news/123), с реализацией пасхальных яиц, которые будут меняться в каждой новой версии Redis;
- Проведена оптимизация кода обработки сетевых соединений;
- Выполнена работа по избавлению от терминов "master" и "slave" в коде. Команда "SLAVEOF (https://redis.io/commands/slaveof)" переименована в "REPLICAOF", а настройка "slaveof" в "replicaof" (для обеспечения совместимости поддержка "SLAVEOF" сохранена). Поддержка признака "slave" в командах INFO (https://redis.io/commands/info) и ROLE (https://redis.io/commands/role) пока оставлена, так как связана с большими нарушениями совместимости (в будущем планируется предложить альтернативу INFO и заменить в ROLE "slave" на "replica");
- Расширены возможности по созданию скриптов-обработчиков на языке Lua.
URL: https://groups.google.com/forum/#!topic/redis-db/l0OXDAlwosU
Новость: https://www.opennet.ru/opennews/art.shtml?num=49495
LOLWUT
Дичи со своими слэйво-мастерными комплексами.
Через несколько лет, когда начнется борьба за права репликантов (синтетических людей), придется "REPLICAOF" переименовывать еще во что-то. Недальновидные какие-то разработчики в Redis.
>придется "REPLICAOF" переименовыватьпридется переименовывать, только если репликанты победят. а пока разработчики верят в человечество
ты бот, твое синтетическое мнение тут не у местно
у йди
>Недальновидные какие-то разработчики в Redis.Как раз наоборот, оставили себе задел для несложной работы на будущее. :)
>Выполнена работа по избавлению от терминов "master" и "slave" в коде. Команда "SLAVEOF" переименована в "REPLICAOF", а настройка "slaveof" в "replicaof" (для обеспечения совместимости поддержка "SLAVEOF" сохранена). Поддержка признака "slave" в командах INFO и ROLE пока оставлена, так как связана с большими нарушениями совместимости (в будущем планируется предложить альтернативу INFO и заменить в ROLE "slave" на "replica");Наконец-то, джва года ждал.
>Добавлена развлекательная команда LOLWUT, с реализацией пасхальных яиц, которые будут меняться в каждой новой версии Redis;Вот, чего нам не хватало! Вот, на что стоит распылять силы свободному сообществу! Так победимЪ!
На самом деле, идея-то хорошая сама по себе, просто я вангую, что команда будет выводить просто потрясающее уныние уровня "1 апрелю в мире IT", от которого сблевал бы и Петросян.
а ты собрался уже читать логи вместо вечернего петросяна?
> Добавлена развлекательная команда LOLWUT, с реализацией пасхальных яиц, которые будут меняться в каждой новой версии Redis;остальным проектам стоит поучиться у команды редиса как завоёвывать аудиторию )
В версии 6.0 добавят команду SMUZIHOW, которая будет выдавать рецепты смузей, а в версии 7.0 команду BARBERWHERE, которая используя геолокацию будет сообщать направление к ближайшему барбер шопу, плюс возможность установки Redis на гироскутер.
> Представлен новый тип данных Stream, который можно использовать для хранения данных в форме пополняемого лога.
> Для организации совместной обработки разных частей одного потока сообщений реализована концепция Consumer GroupsПочему они из редиса упорно делают кафку?
Потому что есть такие задачи, когда достаточно легковесного решения.Я вот уже знаю, где мне это пригодится.
Видимо потому что у них не получилось сделать из своей редиски конкурента кролику, а отъесть аудиторию у серьезных и уважаемых проектов, в пользу "легковесного решения" очень хочется. А здоровья придумать что-то свое оригинальное явно (пока?) не хватает.
но вот зачем, очередной троллейбус-из-буханки?решение-то на глазах перестает быть легковесным. Даже рассчет на аудиторию, ниасилившую еще один апи, не поможет, апи-то все равно приходится дополнять.
> А здоровья придумать что-то свое оригинальное явно (пока?) не хватает.
оно и было вполне свое и оригинальное, этакий персистентный мемкэш с человекочитаемым протоколом. А сейчас выросло в такое, что уже с гранатометом добывать ходить надо.
> Видимо потому что у них не получилось сделать из своей редиски конкурента кроликуИ сделать из своих рук конкурента ногам у них не получилось тоже.
Это всё от того, что руки и ноги по своему назначению слегка отличаются. Примерно так же, как rabbit и redis.
>"ведение на диске лога изменений. Во втором случае гарантируется полная сохранность всех изменений."давно ли? fsync для лога делается? прямо точно гарантируют? как такое запустить?
Братишк, ты лось или просто читать разучился?
https://redis.io/topics/persistence
> Выполнена работа по избавлению кода от терминов "master" и "slave". Команда "SLAVEOF" переименована в "REPLICAOF", а настройка "slaveof" в "replicaof" (для обеспечения совместимости поддержка "SLAVEOF" сохранена). Поддержка признака "slave" в командах INFO и ROLE пока оставлена, так как связана с большими нарушениями совместимости (в будущем планируется предложить альтернативу INFO и заменить в ROLE "slave" на "replica");Вот ведь люди напряжённо работают! Как Стаханов!
Кстати, а почему до сих пор не убрали слова black и white? Нужно совсем убрать их из языка. Куда смотрит ПАСЕ и белый(!) дом?
Вопрос знатокам: чем Redis лучше Apache Ignite?
Спасибо.
Сервер есть с 64GB памяти и 32 ядрами, минимум?
Если да, то Ignite лучше.
э... стесняюсь спросить,а редису не нужна ни память ни процессор? ;-)я бы поставил вопрос по другому - база-то уже близка к 64gb, или пока в мегабайтах измеряется?
Давай так… если ты сравниваешь Ignite с Redis, то для твоих задач Ignite не нужен. Вот правда.Ignite для разворачивания всяких кластеров для хранения десятков/сотен терабайт в оперативке, да так, чтобы ещё не тормозило и чтобы с этими данными можно было цивильно работать через SQL/HQL или там Spark.
мы тоже можем в кластер! дададада!
Вот сравнение https://redisson.org/feature-comparison-redis-vs-ignite.html
В свое время было ограничение на количество записей в списке в 2^32 сохранилось или уже побороли. Вообще что посоветуете для хранения больших индексов в Redis?
Сломать руки архитектору приложения, которое требует поддержку 4х МИЛЛИАРДОВ записей в одном списке.
640k should be enough for all!