Можно ли использовать Kafka как хранилище?

Kafka как хранилище: возможности и ограничения

Красивый вопрос, требующий нюансированного ответа. Формально — да, Kafka может хранить данные, но это не основное её предназначение, и использование требует очень осторожного подхода.

Архитектура Kafka

Как работает хранение в Kafka

• Сообщения записываются в log-структуру (append-only log)
• Каждый partition — это упорядоченный файл на диске
• Данные хранятся на всех replicas для отказоустойчивости
• Retention policy определяет, как долго хранятся сообщения

Параметры хранения:

• log.retention.hours — сколько часов хранить (по умолчанию 7 дней)
• log.retention.bytes — максимальный размер partition'а
• log.segment.bytes — размер одного сегмента log'а

Технически это возможно, но...

Достоинства как хранилища

• Высокая пропускная способность (миллионы сообщений в секунду)
• Надёжность через replication
• Упорядоченность данных в partition'е
• Полнота истории для event sourcing
• Дешевизна дискового пространства

Существенные ограничения

• Отсутствие индексирования — поиск требует линейного сканирования
• Отсутствие запросов — нет SQL, нет агрегаций, фильтраций
• Сложность транзакций — нет ACID гарантий
• Невозможность обновлений — append-only log не позволяет изменять данные
• Отсутствие удаления — на практике физическое удаление — это tombstoning
• Отсутствие join операций — невозможно соединить две коллекции
• Ограниченный доступ — требуется специальный code для чтения
• Сложность миграции — переход с Kafka трудоёмкий

Сценарии, где можно использовать Kafka как хранилище

Event Sourcing архитектура

• Основная идея: система состоит из последовательности событий
• Kafka идеально подходит для хранения events
• Состояние можно восстановить, переиграв события (replay)
• Пример: заказы в e-commerce (события: создание, оплата, отправка, доставка)

Stream processing

• Kafka Streams или Flink обрабатывают события в реальном времени
• Готовые снимки состояния хранятся в state store (RocksDB)
• Kafka хранит исходные события

Immutable audit log

• Неизменяемый журнал для соответствия compliance требованиям
• Все изменения в системе логируются как события
• Audit trail в Kafka, а текущее состояние в БД

Real-time analytics

• Потоковый анализ данных (Kafka + Spark)
• Исходные данные в Kafka, результаты в хранилище аналитики

Когда Kafka НЕ подходит как основное хранилище

Online transaction processing (OLTP)

• Banking systems — нужны ACID транзакции
• E-commerce заказы — нужно обновлять статус доставки
• CRM — нужна поиск по полям и агрегации

Online analytical processing (OLAP)

• Business intelligence — нужны сложные запросы
• Data warehouse — нужны агрегации и join'ы
• Reporting — нужна SQL

Когда требуется

• Быстрый поиск по ID
• Обновление существующих записей
• Комплексные queries
• Гибкая схема

Практический подход: Lambda Architecture

Источники данных
        |
        v
    Kafka (streaming)
       /  \
      /    \
 Speed layer   Batch layer
 (Kafka Streams)  (Spark, Hadoop)
     |              |
     v              v
Speed view      Batch view
     |              |
     \____________v_____________/
              |
        Serving Layer
       (Database, Cache)

• Kafka хранит raw events
• Speed layer обрабатывает в реальном времени
• Batch layer обрабатывает полный набор для корректности
• Результаты в БД для быстрого доступа

Best practices

Если вы решили использовать Kafka как хранилище:

1. Выбирайте event sourcing — стройте архитектуру на событиях
2. Добавляйте БД для состояния — CQRS pattern (Command Query Responsibility Segregation)
3. Проектируйте события правильно — неизменяемые, с достаточно информации для replay
4. Планируйте масштабирование — Kafka отлично масштабируется горизонтально
5. Документируйте схему — используйте Avro или Protobuf
6. Проверяйте retention — убедитесь, что данные не исчезают раньше времени

Альтернативы

Если вам нужно хранилище с сохранением истории:

• PostgreSQL с audit tables или pgAudit
• MongoDB с change streams
• DynamoDB Streams в AWS
• Firestore с истории версий
• ClickHouse для аналитики

Вывод

Да, Kafka можно использовать как хранилище в контексте event sourcing и stream processing. Но это специализированное использование для определённых архитектурных паттернов. Для традиционных OLTP и OLAP систем Kafka не подходит. Правильный подход — использовать Kafka для потокового обработки события, а состояние системы хранить в traditionalBD базах данных через CQRS pattern.