Перейти к содержимому
Все статьи
Комментарии

Redis 8.12 RC: что проверять у сжатых битовых карт

·27 октября 2026 г.· 5 мин чтения
Сколько будет стоить ваш проект?Рассчитать стоимость

В Redis 8.12 RC добавлена интеграция сжатых битовых карт Roaring. Проверять её пользу нужно по диапазону индексов, плотности данных и операциям приложения, а не по одному обещанию экономии памяти. На дату разбора официальная страница описывает RC1 как предварительный выпуск, непригодный для production; это материал для ограниченной проверки, а не совет заменить рабочий Redis.

Статус выпуска и новая возможность — разные сведения

Release notes Redis 8.12 относят RC1 к октябрю 2026 года, сообщают об интеграции redis-roaring и указывают, что bitmap-default-roaring выключен по умолчанию. Точной даты RC по дате слияния кода мы не вычисляем.

Daniel Lemire 15 октября описал собственную проверку Roaring в Redis. Его объяснение различает обычную битовую строку, занимающую диапазон до старшего смещения, и сжатое представление, учитывающее форму множества. Приведённые там измерения принадлежат автору; они не становятся замерами нашего приложения или универсальным коэффициентом ускорения.

Одинаковое количество элементов не означает одинаковый диапазон

Наш небольшой арифметический пример: множества {1, 7} и {1, 79} содержат по два индекса. Для обычного плотного представления с нумерацией от нуля полезная битовая область до старшего индекса занимает соответственно 8 и 80 бит, то есть 1 и 10 байт. Это только модель полезной области без метаданных, выделения памяти и накладных расходов Redis.

Расчёт не предсказывает размер Roaring и не требует создавать карту в Redis. Он показывает, почему число установленных битов не описывает задачу полностью. Если реальные идентификаторы далеко разнесены, запишите диапазон; если они образуют длинные участки, запишите и эту форму.

Четыре маленьких набора для смысловой проверки

Собственный учебный наборЧто в нём меняетсяНужная проверкаЧто измерять отдельно
{1, 7}Небольшой диапазон и разрывыЧтение и число установленных индексовНакладные расходы небольшого объекта
{1, 79}Та же мощность, больший старший индексТот же смысл при другом диапазонеПамять, не выводя её из числа элементов
{20, 21, 22, 23}Последовательный участокГраницы и изменение одного элементаСтоимость используемой операции
A={1,7}, B={7,79}Два пересекающихся множестваПересечение {7}, объединение {1,7,79}Ресурсы операции и размер результата

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

Сначала эквивалентность, затем ресурсы

Опишите операции, которые действительно использует сервис: проверить присутствие индекса, посчитать множество, найти пересечение или изменить значение. Для каждой нужны известный исходный набор и ожидаемый итог. Если ответы расходятся, сравнение времени ещё не отвечает на задачу перехода.

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

Почему «меньше объект» не равно «меньше весь процесс»

Приложение хранит не одну карту, а набор данных и служебное состояние. Изменение размера отдельного объекта не доказывает такой же процент снижения памяти процесса. Записывайте, какой показатель получен, при каком количестве объектов и с какой нагрузкой. Если метрика не измерялась, оставьте её неизвестной.

  1. Зафиксируйте текущий статус выпуска и документацию выбранной реализации.
  2. Опишите диапазон, плотность и характер индексов проекта.
  3. Проверьте смысл операций на маленьких известных множествах.
  4. Выберите ограниченный представительный набор без клиентских секретов.
  5. Задайте одинаковые условия и предел ресурсов сравнения.
  6. Сохраните результаты, непроверенные операции и ограничения предварительной версии.

Для веб-приложения с множествами данных такой протокол помогает оценить нужную структуру. При автоматизации отчётов сначала согласуйте смысл подсчёта, а в сопровождении сервера учитывайте общий предел памяти. В этой статье выполнена только арифметика маленького примера; Redis и нагрузочные процессы не запускались.

Вопросы и ответы

От чего зависит Redis bitmap size?

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

Redis Roaring bitmap всегда быстрее обычного?

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

Что проверять у Redis bitmap operations перед переходом?

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

Нужна помощь с проектом?

Обсудим задачу и предложим решение — от сайта до SaaS и защиты.

Связаться