В новом Valkey (открытый аналог Redis) версии 9.0 появилась возможность выставлять TTL на конкретное поле в hashmap. Раньше можно было выставлять только на весь ключ, что на практике приводило к неудобным компромиссам: либо все поля одного hash разделяют один TTL, либо приходилось разбивать данные на отдельные ключи, что увеличивало overhead.

Давайте разберем, как этот механизм устроен изнутри. У команды Valkey были несколько вариантов решения:

• secondary hashtable - рядом с каждым hashmap объектом положить еще одну hashmap для полей с TTL. Плюсы: простота, минусы: неэффективное сканирование при поиске истекших полей
• radix tree индекс - быстрый доступ к отсортированным данным, но overhead в 54 байта на поле 🙁
• sorted skip-list - эффективное сканирование истекших полей, но сложность доступа O(log N) вместо ожидаемого для hashmap O(1)

Чтобы понять итоговое решение, нужно разобраться, как Redis/Valkey работает с TTL для ключей. Используются 2 стратегии:

В Redis есть два вида персистентного хранения данных:

• RDB
• AOF

Разберём каждый из них.

RDB

Суть режима проста - через определённое количество времени или выполненных команд Redis делает снапшот всех своих данных в файл с расширением .rdb. Всё :) Вот такой простой режим работы.

Тот, кто немного знаком с Redis, знает, что он однопоточный. Получается, пока делается снапшот, Redis недоступен? Например, снапшот 200 миллионов ключей (в зависимости от диска, конечно) будет происходить порядка 150 секунд. И что, получается, все эти 150 секунд мы будем ждать?

Привет. Недавно поступил вот такой вопрос от читателей:

Никита, привет! А ты слышал про язык Hare? https://harelang.org

Если да, можешь мыслями поделиться пожалуйста)

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

Что нужно для успешности языка

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

Предлагаю сегодня поговорить о тестах производительности баз данных.

В чем собственно проблема

Мне нравятся бенчмарки. Я люблю сравнивать один подход с другим в своем коде. Стараюсь делать какие-то выводы из чужих бенчмарков. Короче бенчмарки это круто. Особенно для сложных, наукоемких или инфраструктурных вещей. Как писать бенчмарки на код все плюс-минус понимают, конечно там есть свои подводные камни о которых стоит рассказать отдельно, а вот как бенчмаркать базы данных большой вопрос. Особенно сложно становится, когда в наш уютный мир программирования влезает бизнес и маркетинг. Есть даже термин – benchmarketing. Когда компания берет своего конкурента, сравнивает свое творение с его и удивительным образом выигрывает это сравнение.

Мы в Lamoda плотно используем kafka. Такая активная работа не могла обойтись без написания своего врапера над каким-то из драйвров. Необходимо это для упрощения API, скрытие некоторых сложностей, покрытие метриками и т.п. Текущая обертка была построена на sarama и sarama-cluster, но время идет, создаются новые библиотеки, sarama-cluster уже не поддерживается и возник вопрос с переходом на что-то другое. Только вот для того, чтобы перейти на это “что-то другое” стоит сначала понять даст ли положительный эффект этот переход. Так и пришла идея сравнить производительность драйверов.