✉️ Пост 44. Можно ли использовать Kafka как базу данных? Как вообще искать данные в Kafka.
Очень частый вопрос - "А Kafka же хранит сообщения. Можно ли ее юзать как базу данных?"
Короткий ответ: 👉 Kafka - не классическая БД, НО некоторые сценарии хранения и доступа к данным она реально умеет закрывать. И да, данные по ключу оттуда тоже можно доставать. Но работает это вообще не так, как в PostgreSQL или Redis, например.
🧠 Что Kafka хранит на самом деле Kafka хранит не "таблицы", а лог событий. То есть данные лежат как последовательность сообщений: offset 1 → user=1 status=NEW offset 2 → user=2 status=NEW offset 3 → user=1 status=PAID offset 4 → user=1 status=SHIPPED Kafka не обновляет записи. Она работает по принципу: 👉 append-only log - то есть новые события только дописываются в конец.
🔥 Тогда почему Kafka иногда называют БД? Потому что: ⚪️ она хранит данные ⚪️ умеет replication ⚪️ может переживать рестарты ⚪️ может хранить историю событий годами
И самое главное: 👉 Kafka может хранить текущее состояние через compacted topics и KTable. (Подробно об этом в другом посте) ⚙️ Как в Kafka искать данные по ключу Вот тут важный момент. Kafka НЕ предназначена для запросов вида: SELECT * FROM users WHERE id = 123
Она не умеет: 🔺 SQL индексы 🔺 произвольные выборки 🔺 join как в БД 🔺 поиск по колонкам
Kafka оптимизирована для: 👉 последовательного чтения сообщений. То есть consumer обычно читает: offset 1 offset 2 offset 3 offset 4 по порядку.
🧩 Но ключи в Kafka всё-таки есть Сообщение в Kafka выглядит так: key → value Например: user-1 → CREATED user-1 → PAID user-1 → SHIPPED
Ключ нужен для:
- определения партиции
- сохранения порядка внутри ключа
- компактации
🔥 Что такое log compaction Вот это уже очень похоже на БД. Если включить: cleanup.policy=compact (итого по сути мы создали компактный топик) - Kafka начинает хранить только последнее значение для каждого ключа
Было: user-1 → CREATED user-1 → PAID user-1 → SHIPPED После compaction останется: user-1 → SHIPPED То есть Kafka начинает выглядеть как: key → latest state Почти key-value storage.
🚀 И вот тут появляется KTable 🧠 Что такое KTable KTable - это представление над компактным топиком Kafka как таблицы текущего состояния. Не поток событий. А именно: 👉 "последнее значение для каждого ключа".
📦 Пример В топик приходят события: user-1 → CREATED user-1 → PAID user-2 → CREATED user-1 → SHIPPED KTable будет выглядеть так: user-1 → SHIPPED user-2 → CREATED То есть KTable автоматически хранит актуальное состояние.
⚙️ Как это работает внутри Kafka Streams читает топик и строит локальное state store. Обычно это RocksDB внутри приложения
То есть: 1️⃣ события читаются из Kafka 2️⃣ обновляют локальное хранилище 3️⃣ приложение может быстро искать по ключу
🧩 Как получить данные по ключу Например: user-1 → SHIPPED В Kafka Streams можно сделать: table.get("user-1") И получить актуальное состояние. Но это уже не прямой запрос в Kafka-log. Это запрос в локальный state store.
⚡ Что такое State Store Это локальная embedded БД внутри stream-приложения. Обычно RocksDB. Там хранятся: • агрегаты • KTable • промежуточные состояния Kafka при этом остается журналом изменений
