English version: README.md.
GEBODIKBD — учебный проект: минимальная реляционная СУБД с клиент‑серверной архитектурой, собственным SQL‑пайплайном и дисковым хранением (heap pages + buffer pool). Основная цель — пройти полный путь обработки запроса: от SQL‑строки до чтения/записи страниц и использования индексов.
Проект намеренно упрощён и не предназначен для production. Он фокусируется на базовых идеях СУБД и читаемости реализации.
Проект возник из интереса, который появился после прохождения курса по базам данных в НИУ ВШЭ. Теория и обзор классических компонентов СУБД дали мне хорошие знания, но в какой-то момент захотелось разобраться, как именно эти компоненты работают “под капотом”. Мне было важно понять, как устроены механизмы, форматы данных, код и инженерные компромиссы, которые стояли за каждым решением.
Таким образом, учебный интерес перерос в более глубокую исследовательскую задачу: я создал минималистичную, но функциональную модель реляционной базы данных, которая позволяла проследить полный путь запроса — начиная с его обработки на уровне SQL-строки и построения планов, заканчивая чтением и записью страниц в хранилище и работой с индексами. В рамках этого проекта я изучил и проанализировал несколько ключевых областей, чтобы понять, как каждый элемент СУБД влияет на производительность и архитектуру системы.
Вот основные области, на которых я сосредоточился в проекте:
-
SQL pipeline: я глубже понял все этапы обработки SQL-запросов, начиная с лексического анализа, затем работы парсера, семантической проверки и построения плана выполнения, а также оптимизации и самого выполнения запроса. Я исследовал, как запросы преобразуются и выполняются на разных уровнях системы.
-
Хранилище данных: важной частью проекта стало изучение реализации хранилища. Я сосредоточился на heap-страницах, структуре идентификаторов кортежей (TID), механизмах сериализации данных, буферном пуле (buffer pool) и алгоритмах вытеснения. Механизмы работы с памятью и хранением данных играли ключевую роль в производительности СУБД.
-
Индексы и выбор плана выполнения: я разобрался, как эффективно строятся индексы и как правильно выбирать стратегию выполнения запроса — например, выбор между последовательным сканированием таблицы (seq scan) или использованием индекса (index scan). Я исследовал различные подходы к выбору оптимального плана и их влияние на скорость выполнения запросов.
-
Инженерные аспекты: помимо теоретических знаний, проект включал практическую часть, где я разработал API, спроектировал модули для работы с базой данных, а также протестировал систему с помощью unit- и e2e-тестов. Важной частью работы было использование Java для реализации I/O и сетевых операций.
В целом, цель проекта заключалась не просто в создании теоретической модели базы данных, но и в том, чтобы увидеть, как все эти элементы взаимодействуют в реальной жизни, и какие инженерные решения принимались для обеспечения эффективности и производительности системы.
- Java 17+
- Gradle Wrapper (в репозитории)
./run-server.shПараметры через переменные окружения:
PORT=15432 DATA_DIR=data BUFFER_POOL=10 ./run-server.sh./run-cli.shПараметры:
HOST=127.0.0.1 PORT=15432 ./run-cli.sh- Клиент–сервер: TCP framed protocol, JSON‑ответы, CLI клиент.
- SQL‑диалект:
CREATE TABLE,INSERT,SELECT,CREATE INDEX. - Выражения в
SELECTиWHERE: арифметика, сравнения,AND/OR, алиасыAS. - Компиляция запросов:
LexerImpl,ParserImpl,SemanticAnalyzerImpl,PlannerImpl,OptimizerImpl. - Исполнение запросов: Volcano‑style executors (scan/filter/project/insert/create).
- Дисковое хранение: heap pages 8KB, page file manager, tuple serializer.
- Buffer pool: кэш страниц, dirty pages, стратегии вытеснения LRU/Clock.
- Системный каталог: метаданные таблиц/колонок/типов/индексов в
data/. - Индексы:
-
HASH— персистентный, используется для точечного поиска (=). -
BTREE(B+Tree) — поддержка range‑scan; на текущем этапе пересобирается при старте (см. ограничения).
-
- Набор тестов: lexer/parser/semantic, storage, индексы, end‑to‑end по TCP.
- Персистентность BTREE (сохранение на диск + восстановление без пересборки).
-
DELETE/UPDATE. -
DROP TABLE/DROP INDEX. - Транзакции и конкурентный доступ (убрать глобальную блокировку, добавить модель изоляции).
- Улучшение оптимизатора (статистика, cost‑based выбор плана).
- Расширение SQL (JOIN, ORDER BY, LIMIT).
Полный список и приоритизация: docs/ru/ROADMAP.md.
Детали и мотивация архитектурных решений: docs/ru/ARCHITECTURE.md.
Больше сценариев: docs/ru/EXAMPLES.md.
Оглавление: docs/ru/README.md.