🧠 MemifyDB: прежде всего — видение (vision).
Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим?
Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision).
Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.
Поехали!
📚 Типы in-memory баз данных
1. Key-Value хранилища
Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.
Примеры: Redis, Memcached, DragonflyDB.
Сценарии: кэширование, сессии пользователей, счётчики, очереди задач.
Плюсы: максимальная скорость, минимальный оверхед, простота масштабирования (шардирование по ключу).
Минусы: ограниченная модель данных — нет сложных запросов, только операции по ключу.
2. Документо-ориентированные БД
Значение — структурированный документ (JSON, BSON, XML). Внутри документа можно индексировать поля и выполнять запросы по содержимому.
Примеры: MongoDB (in-memory storage engine), Couchbase.
Сценарии: хранение сложных объектов (профили, каталоги), где важна гибкость схемы.
Плюсы: удобство для разработчика, естественное представление данных, возможность частичного обновления.
Минусы: чуть более высокий оверхед по сравнению с key-value (парсинг, индексация).
3. Колоночные (Columnar) in-memory БД
Данные хранятся не по строкам, а по колонкам. Это даёт огромное преимущество при аналитических запросах (суммы, средние, группировки).
Примеры: SAP HANA, MemSQL (SingleStore) в колоночном режиме, Apache Arrow (формат, но не БД).
Сценарии: аналитика реального времени, отчёты, BI.
Плюсы: сверхбыстрая агрегация, высокая степень сжатия.
Минусы: медленные точечные обновления (OLTP-нагрузка), сложность реализации.
4. Графовые БД
Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.
Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).
Сценарии: социальные сети, рекомендательные системы, сети связей.
Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.
Минусы: узкая ниша, сложность шардирования.
5. Time-series БД
Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.
Примеры: InfluxDB, TimescaleDB (in-memory части).
Сценарии: мониторинг, IoT, финансовые тикеры.
Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.
Минусы: слабо подходят для произвольных данных.
…## 🧭 Наш курс: от Key-Value к документам
Для MemifyDB я выбрал путь, который кажется самым прагматичным:
Создаём ядро Key-Value
Это фундамент. Мы реализуем:потокобезопасное in-memory хранилище;
поддержку разных типов значений (строки, списки, хеши, числа);
механизмы TTL и эвикшена (LRU);
бинарный протокол, близкий к внутреннему представлению.
Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).
Надстраиваем документный слой
Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:индексация по полям;
поддержка частичного обновления;
запросы с фильтрацией по содержимому.
При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.
Такая двухслойная архитектура даёт:
гибкость — можно работать и как с обычным кэшем, и как с документной БД;
производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;
расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.
