Skip to content

Latest commit

 

History

History
96 lines (61 loc) · 8.12 KB

File metadata and controls

96 lines (61 loc) · 8.12 KB

GEBODIKBD — учебная реляционная СУБД на Java 17

English version: README.md.

GEBODIKBD — учебный проект: минимальная реляционная СУБД с клиент‑серверной архитектурой, собственным SQL‑пайплайном и дисковым хранением (heap pages + buffer pool). Основная цель — пройти полный путь обработки запроса: от SQL‑строки до чтения/записи страниц и использования индексов.

Проект намеренно упрощён и не предназначен для production. Он фокусируется на базовых идеях СУБД и читаемости реализации.

Цели проекта (учебные)

Проект возник из интереса, который появился после прохождения курса по базам данных в НИУ ВШЭ. Теория и обзор классических компонентов СУБД дали мне хорошие знания, но в какой-то момент захотелось разобраться, как именно эти компоненты работают “под капотом”. Мне было важно понять, как устроены механизмы, форматы данных, код и инженерные компромиссы, которые стояли за каждым решением.

Таким образом, учебный интерес перерос в более глубокую исследовательскую задачу: я создал минималистичную, но функциональную модель реляционной базы данных, которая позволяла проследить полный путь запроса — начиная с его обработки на уровне SQL-строки и построения планов, заканчивая чтением и записью страниц в хранилище и работой с индексами. В рамках этого проекта я изучил и проанализировал несколько ключевых областей, чтобы понять, как каждый элемент СУБД влияет на производительность и архитектуру системы.

Вот основные области, на которых я сосредоточился в проекте:

  1. SQL pipeline: я глубже понял все этапы обработки SQL-запросов, начиная с лексического анализа, затем работы парсера, семантической проверки и построения плана выполнения, а также оптимизации и самого выполнения запроса. Я исследовал, как запросы преобразуются и выполняются на разных уровнях системы.

  2. Хранилище данных: важной частью проекта стало изучение реализации хранилища. Я сосредоточился на heap-страницах, структуре идентификаторов кортежей (TID), механизмах сериализации данных, буферном пуле (buffer pool) и алгоритмах вытеснения. Механизмы работы с памятью и хранением данных играли ключевую роль в производительности СУБД.

  3. Индексы и выбор плана выполнения: я разобрался, как эффективно строятся индексы и как правильно выбирать стратегию выполнения запроса — например, выбор между последовательным сканированием таблицы (seq scan) или использованием индекса (index scan). Я исследовал различные подходы к выбору оптимального плана и их влияние на скорость выполнения запросов.

  4. Инженерные аспекты: помимо теоретических знаний, проект включал практическую часть, где я разработал API, спроектировал модули для работы с базой данных, а также протестировал систему с помощью unit- и e2e-тестов. Важной частью работы было использование Java для реализации I/O и сетевых операций.

В целом, цель проекта заключалась не просто в создании теоретической модели базы данных, но и в том, чтобы увидеть, как все эти элементы взаимодействуют в реальной жизни, и какие инженерные решения принимались для обеспечения эффективности и производительности системы.

Быстрый старт

Требования для запуска проекта

  • Java 17+
  • Gradle Wrapper (в репозитории)

Запуск сервера

./run-server.sh

Параметры через переменные окружения:

PORT=15432 DATA_DIR=data BUFFER_POOL=10 ./run-server.sh

Запуск CLI клиента

./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.

Roadmap / TODO

  • Персистентность 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.