Неделю назад вышла Apache Kafka 4.0, но только сейчас дошли руки разобраться что там нового. И это, надо сказать, весьма значимый релиз!

Самое главное — с версии 3 можно было работать без ZooKeeper в экспериментальном режиме, но теперь это стало поведением по умолчанию. Технология KRaft (Kafka Raft) полностью заменила ZooKeeper, что серьезно упрощает развертывание и управление. Больше не нужно поддерживать отдельный ZooKeeper-кластер, что снижает операционные издержки и улучшает масштабируемость. Прощай, ZooKeeper, ты служил верой и правдой! 👋

Что еще интересного:

Новый протокол групп потребителей (KIP-848)
Наконец-то решена проблема с ребалансировкой! Если раньше при изменении числа потребителей происходила "stop-the-world" ребалансировка, приводящая к задержкам, то теперь процесс происходит гораздо плавнее. Особенно полезно для крупных деплойментов — больше никаких долгих простоев при масштабировании.

Очереди для Kafka (KIP-932, ранний доступ)
Появилась концепция "share group" для организации кооперативного потребления данных из топиков. По сути, это делает возможной реализацию классических очередей, где каждое сообщение обрабатывается только одним потребителем. Теперь Kafka может легко заменить RabbitMQ и другие традиционные брокеры сообщений.

Eligible Leader Replicas (превью)
Введен поднабор допустимых реплик (ELR), которые гарантированно содержат все данные и могут безопасно становиться лидерами без потери данных.

Pre-Vote механизм
Узлы теперь проверяют свою пригодность для лидерства перед запуском выборов, что уменьшает ненужные смены лидера и сокращает перебои при временных сетевых проблемах.

Повышение требований к Java
Kafka Clients и Streams теперь требуют Java 11, а брокеры, Connect и инструменты — Java 17.

Переход на Log4j2
Логирование переведено на Log4j2, что дает больше возможностей и лучшую производительность.

Не забудьте изучить гайд по переходу

А вы уже планируете переход на Kafka 4.0? Делитесь опытом в комментариях!

#kafka #apache #bigdata #streaming #devops #dataengineering #dev

Начался учебный год — у меня ещё нет пар, но в преддверии занятий делюсь полезной заметкой по БД. Часто вижу, как «на всякий случай» выбирают типы побольше — в итоге едим место, замедляем индексы и ловим баги.

❌ Антипаттерны, которые встречаю:
- VARCHAR(255) «для всего подряд», даже если код фиксированной длины (например, 10 символов).
- TEXT для email-адресов.
- BIGINT для счётчика, где максимум — тысяча записей.
- FLOAT для денег (теряется точность).

✅ Как делаю сам:
- Строки — по задаче: VARCHAR(254)`/`VARCHAR(320) для email (под стандарты), CHAR(2) для кода страны.
- Деньги — только NUMERIC(10,2) / DECIMAL(10,2) или целые «копейки/центы» в INT`/`BIGINT.
- Булево — BOOLEAN, а не INT.
- Даты/время — DATE / TIMESTAMP, не строка.
- Автонумерация — INT по умолчанию; BIGINT — только если реально ждёте > 2 млрд строк.

📌 Пример
-- Плохо
price FLOAT;

-- Хорошо
price NUMERIC(10,2);

⚡️ Итог: грамотный выбор типов = меньше места, быстрее запросы, меньше багов.

#БД #SQL #PostgreSQL #Оптимизация #Backend #DataEngineering

В продолжении поста про PostgreSQL, поделюсь про Redis. Чаще всего используют только строку, но он гораздо многообразнее.

🧱 String
— Ключ-значение, базовый кирпич. Кэш, флаги, счётчики, токены.
— Пример: SET key val, GET key, INCR views, SETNX, EXPIRE key 60
— Паттерны: rate-limit (`INCR + EXPIRE`), простые распределённые блокировки (`SET lock val NX PX 10000`)

🧩 Hash
— «Объект» с полями: компактно хранит мелкие атрибуты.
— Пример: HSET user:42 name Lev email lev@..., HGETALL user:42
— Когда: профили пользователей, настройки. Плюс — частичные обновления полей.
— Нюанс: нет TTL на отдельные поля, ставится на весь ключ.

📚 List
— Упорядоченная коллекция. Очереди (FIFO/LIFO), буферы, журналы.
— Пример: LPUSH queue job1, BRPOP queue 0
— Когда: простые очереди, ретраи. Не забывайте LTRIM для ограничения длины.

🏷 Set
— Множества без дубликатов. Теги, интересы, подписки.
— Пример: SADD tags:post:1 go devops, SINTER user:42:tags post:1:tags
— Когда: рекомендации по пересечению множеств, дедупликация.

🏆 Sorted Set (ZSet)
— Множество с весом (score). Рейтинги, приоритизация, «календарь по времени».
— Пример: ZADD leaderboard 1500 user42, ZRANGE leaderboard 0 9 WITHSCORES
— Когда: топ-N, очереди с приоритетом, time-index (`score = timestamp`).
— Хитрость: чистка старых данных — ZREMRANGEBYSCORE.

🧮 Bitmap
— Битовые флаги по смещению. Ультра-дешёвая памятью аналитика по дням.
— Примеры SETBIT active:2025-09-10 42 1, BITCOUNT active:*
— Когда: «приходил ли пользователь в день D», воронки по дням, календари активности.

📏 Bitfield
— Упакованные счётчики/флаги в одном ключе.
— Пример: BITFIELD key INCRBY u8 10 1
— Когда: компактные счётчики для ограниченного диапазона (экономия памяти).

🔢 HyperLogLog
— Приблизительное количество уникальных (distinct).
— Пример: PFADD u:visits user42, PFCOUNT u:visits
— Когда: уникальные посетители/поисковые запросы, где допустима погрешность.

📍 GEO (геоиндексы)
— Геопоиск по радиусу/полигону.
— Пример: GEOADD places 13.405 52.52 berlin, GEOSEARCH places FROMLONLAT 13.4 52.5 BYRADIUS 5 km
— Когда: «что рядом», ближайшие точки интереса.

📨 Streams
— Лог событий с потребительскими группами (Kafka-лайт).
— Пример: XADD events * type=signup user=42, XREADGROUP GROUP g c COUNT 10 STREAMS events >
— Когда: event sourcing, обработка событий с подтверждениями.

📣 Pub/Sub
— Эфемерные сообщения «здесь и сейчас».
— Пример: PUBLISH chan msg, SUBSCRIBE chan
— Когда: оповещения в реальном времени, без хранения истории (не путать со Streams).

🧾 RedisJSON (Redis 8+)
— Хранение JSON как дерево, выборка/патчи по путям.
— Пример: JSON.SET user:42 $ '{"name":"Lev","age":33}', JSON.NUMINCRBY user:42 $.age 1
— Когда: нужны частичные обновления и индексирование полей (с RediSearch).
— Альтернатива: String с сериализацией — просто, но без частичных апдейтов.

🧠 Итог
— В Redis выбор структуры = половина решения. Строка с JSON — ок для простого кэша, но для очередей, рейтингов, счётчиков и аналитики есть куда более точные инструменты.

#Redis #БД #Кэширование #Backend #Шпаргалка #DataEngineering