Skip to content

TECHNICAL_ASSIGNMENT.md

Latest commit

 

History

History
151 lines (101 loc) · 6.02 KB

TECHNICAL_ASSIGNMENT.md

File metadata and controls

151 lines (101 loc) · 6.02 KB

Техническое задание (учебный проект “мини‑СУБД”)

Ниже приведён пример ТЗ/чек‑листа, по которому удобно строить учебную СУБД “с нуля”. Его можно использовать как ориентир для собственного проекта или как основу для курсовой/пет‑проекта.

Документ специально написан в “инженерном” стиле: требования + критерии готовности.

1. Цель и область работ

1.1. Цель

Реализовать учебную реляционную СУБД, демонстрирующую полный путь обработки запроса:

  1. приём SQL (клиент/сервер),
  2. разбор и анализ,
  3. построение плана,
  4. исполнение,
  5. чтение/запись данных в страницах на диске,
  6. применение индексов для ускорения выборок.

1.2. Область (scope)

В рамках проекта допускается сознательная упрощённость:

  • без полноценной транзакционной модели,
  • без сложной оптимизации и полноты SQL‑стандарта,
  • с фокусом на читаемости кода и тестируемости.

2. Функциональные требования

2.1. Клиент–сервер

  • Сервер принимает соединения по TCP.
  • Протокол обмена: framed (length‑prefixed).
  • Запрос: SQL‑строка в UTF‑8.
  • Ответ: JSON (успех/ошибка).

Критерии готовности:

  • Сервер запускается, принимает подключения, корректно закрывает ресурсы.
  • Клиент может отправить запрос и получить ответ.
  • Ошибки возвращаются в едином формате с указанием стадии (lexer/parser/semantic/...).

2.2. CLI клиент

  • Интерактивный режим.
  • Команда выхода.
  • Печать результатов в табличном виде.
  • Опционально: режим вывода raw JSON.

2.3. SQL‑диалект (минимальный)

Обязательные команды:

  • CREATE TABLE
  • INSERT INTO … VALUES …
  • SELECT … FROM … [WHERE …]
  • CREATE INDEX … USING …

Поддерживаемые типы:

  • INT64
  • VARCHAR

Поддерживаемые выражения:

  • арифметика (+, -, *, /) для чисел,
  • сравнения (=, !=, <, >, <=, >=),
  • логика AND/OR.

Критерии готовности:

  • парсер принимает корректные запросы диалекта и отклоняет некорректные,
  • семантический анализ валидирует таблицы/колонки/типы,
  • SELECT возвращает корректный результат, INSERT изменяет данные.

2.4. SQL pipeline и планы

Требования к стадиям:

  • Lexer: токенизация.
  • Parser: AST.
  • Semantic: типизация и проверка имён.
  • Planner: логический план.
  • Optimizer: физический план (правила выбора scan/index scan).
  • Execution: исполнители (Volcano).

Критерии готовности:

  • стадии отделены, тестируются по отдельности,
  • можно отследить “на каком этапе упал запрос”.

2.5. Storage engine

Требования:

  • дисковое хранение в виде heap‑страниц фиксированного размера,
  • наличие TID (pageId + slotId),
  • сериализация строк в байты и обратно,
  • менеджер страниц (read/write fixed‑size page),
  • buffer pool с политикой вытеснения (например, LRU/Clock),
  • flush dirty pages.

Критерии готовности:

  • данные сохраняются на диск и доступны после перезапуска,
  • есть тесты на чтение/запись страниц и сериализацию.

2.6. Индексы

Минимум два типа:

  • HASH для точечного поиска,
  • BTREE (B+Tree) для диапазонов.

Требования:

  • индекс хранит (key → список TID),
  • оптимизатор умеет выбирать индексный скан,
  • executor умеет извлекать строки по TID.

Критерии готовности:

  • есть unit‑тесты на индекс,
  • есть интеграционный тест “создать индекс → запросы начали выполняться через index scan”.

3. Нефункциональные требования

  • Язык: Java 17.
  • Сборка: Gradle (wrapper).
  • Код должен быть разделён на модули/пакеты по ответственности.
  • Покрытие тестами: unit + хотя бы один end‑to‑end сценарий (по TCP).
  • Документация: README + архитектура + примеры.

4. Артефакты проекта

В репозитории ожидаются:

  • исходный код,
  • автосборка (Gradle wrapper),
  • тесты,
  • документация (README.md + docs/…),
  • скрипты запуска (опционально).

5. Развитие (необязательно, но полезно)

  • UPDATE/DELETE, DROP.
  • JOIN.
  • Транзакции (WAL, блокировки, MVCC).
  • Cost‑based оптимизатор.