Redis 8.12 RC: что проверять у сжатых битовых карт
В 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} | Ресурсы операции и размер результата |
Наборы придуманы для этой статьи и не повторяют нагрузочные тесты из блога. Они слишком малы для вывода о производительности. Их назначение — договориться о правильном ответе раньше, чем команда начнёт сравнивать скорость на характерных данных.
Сначала эквивалентность, затем ресурсы
Опишите операции, которые действительно использует сервис: проверить присутствие индекса, посчитать множество, найти пересечение или изменить значение. Для каждой нужны известный исходный набор и ожидаемый итог. Если ответы расходятся, сравнение времени ещё не отвечает на задачу перехода.
Затем выбирайте ограниченный набор, похожий на данные проекта, и заранее задавайте предел ресурсов проверки. Сравнивать следует одинаковое содержание и одинаковую операцию. Не переносите названия команд старого внешнего модуля на нативный выпуск без документации выбранной версии.
Почему «меньше объект» не равно «меньше весь процесс»
Приложение хранит не одну карту, а набор данных и служебное состояние. Изменение размера отдельного объекта не доказывает такой же процент снижения памяти процесса. Записывайте, какой показатель получен, при каком количестве объектов и с какой нагрузкой. Если метрика не измерялась, оставьте её неизвестной.
- Зафиксируйте текущий статус выпуска и документацию выбранной реализации.
- Опишите диапазон, плотность и характер индексов проекта.
- Проверьте смысл операций на маленьких известных множествах.
- Выберите ограниченный представительный набор без клиентских секретов.
- Задайте одинаковые условия и предел ресурсов сравнения.
- Сохраните результаты, непроверенные операции и ограничения предварительной версии.
Для веб-приложения с множествами данных такой протокол помогает оценить нужную структуру. При автоматизации отчётов сначала согласуйте смысл подсчёта, а в сопровождении сервера учитывайте общий предел памяти. В этой статье выполнена только арифметика маленького примера; Redis и нагрузочные процессы не запускались.
Вопросы и ответы
От чего зависит Redis bitmap size?
У обычного плотного представления существенен старший индекс, а не только число установленных битов. Фактическую память объекта и процесса измеряют отдельно от арифметической модели полезной битовой области.
Redis Roaring bitmap всегда быстрее обычного?
Такой гарантии из новости не следует. Нужны одинаковое содержание, характерная операция и измерение в условиях проекта; сначала проверяют правильность результата.
Что проверять у Redis bitmap operations перед переходом?
Начните с известных маленьких множеств и ожидаемых результатов чтения, подсчёта и используемых комбинаций. Затем переходите к ограниченному сравнению ресурсов, учитывая статус выбранного выпуска.
Читайте также
Chrome обновляется раз в две недели: что менять в проверке сайта
КомментарииRust 1.99.1: исправления FFI и проверка готовой программы
КомментарииAstro 7.3: что проверить в собственном Cloudflare Worker
КомментарииВ YDB появился гибридный поиск: как проверить результат
КомментарииSona от Яндекса: что бизнесу проверить в рекомендациях
РазработкаПодпись вебхука: что проверить до изменения заказа