Базы данных 2/simpledb — различия между версиями

Версия 09:13, 28 февраля 2017

Задания

Задание 1

• В СУБД есть чтение доступных таблиц (схем) при старте сервера.
• При выполнении запроса создается (на данном шаге можно не парсить запрос, а забить предустановленные значения) QueryPlan с операцией чтения из таблицы. QueryPlan содержит операцию full_scan.
• BufferManager, получив QueryPlan, начинает считывать поблочно из файла с данными и формировать список кортежей для результата.

Замечания:

• В QueryResult атрибут schema указан как список, но на самом деле в результате выполнения запроса нужно иметь только одну схему.
• Для перехода к следующему блоку можно также использовать и смещение в текущем файле данных.
• Так как схема отношения уже определена, дополнительно не нужно хранить ее в блоках или картежах данных. Минимально достаточные данные в блоке: указатель/смещение на следующий блок, внутренняя таблица смещения кортежей, кортежи. В кортежах только данные. Для данных переменной длины (VARCHAR) допустимо использовать любой из методов хранения: указание в первом байте размера поля или указание управляющего символа в конце записи.

Задание до 14 февраля.

Если есть вопросы, то пишите на почту преподавателю: acccko@gmail.com

Для сдачи задания используйте форму: https://goo.gl/forms/81yE6BcY7tZP3wVm2

Задание 2

• Реализовать вставку кортежей (формирование страниц) и запись страниц на диск. Для операции добавления нового кортежа достаточно считать в память последний страницу отношения (или реализовать поиск достаточного свободного места в страницах), добавить в него кортеж и записать страницу на диск.
• Реализовать поддержку В-дерева: операции добавление, удаление, поиск по дереву.
• Реализовать поддержку некластерного индекса (кластерного опционально)

Замечания:

• Для вставки достаточно брать случайные данные, не парсить запрос. Например, исходя из того, встречается ли в запросе слово insert или select, выполнять операции добавления или выборки.

Информацию об индексах можно хранить в отдельном файле или файлах.

Задание до 1 марта.

Задание 3

Парсинг запроса, составление плана. Возможно, будет пропущено.

Задание 4

Добавить менеджеров транзакций, журнала и восстановления. Реализация поддержки транзакций.

• Запись журнала в режиме undo/redo
• Алгоритм восстановления по журналу

Задание до TBA

Задание 5

Параллельная обработка запросов.

• Реализация пранировщика блокирования

Задание до TBA

Описание

Описание пока что может отличаться от реального кода (какие-то взаимодействия еще не дописаны), но концепция скорее всего менять не будет.

Есть Server (SocketServer), который может принять и обработать запрос (RequestHandler), затем отправить клиенту ответ. Запрос предварительно парсится на: управляюдище команды, DDL, DML.

Если управляющая команда, то запрос уходит в ControlManager (там можно завершить соединение с клиентом exit)

Если DDL, то запрос отправляется в SchemaManager (там можно запросить список отношений с колонками и индексами, а в будущем создавать и удалять их).

Если запрос DML, то отправляется в QueryManager, который парсит запрос (с помощью QueryParser) и возвращает QueryPlan (список операций, типы операций и отношения, над которыми нужно их делать). Пример операции: table1, full_scan, condition. Результат работы QueryParser QueryManager отправляет в BufferManager, в котором происходят все операции. Если BufferManager нужны данные, которых нет в оперативной памяти, он используя SchemaManager отправляет запросы в DiskManager, который возвращает блоки с диска. Получив блоки (и записи в них) в BufferManager, тот считывает записи оттуда с помощью Row и отправляет наверх к QueryParser, тот в свою очередь отправляет результаты назад к CommandManager, который интерпретирует их и выводит в виде строки пользователю.

При старте Server говорит SchemaManager, чтобы тот запустил свою инициализацию, по умолчанию это значит попросит BufferManager записать в оперативную мапять доступные схемы из файлов.

SchemaManager работает с Schema, который состоит из Column, у которых есть название, тип и размер.

Код

• Стартовый код расположен в git-репозитории: https://bitbucket.org/qs/simpledb

Описание взаимодействия

На данном этапе нужно реализовать подгрузку схемы отношения и взаимодействие менеджера памяти с диском.

Предлагается использовать следующую структуру файловой системы:

   Корень базы
     --- table.data - файл со страницами с данными
     --- table.meta - файл со схемой отношения

Формат схемы отношений

Можно ограничиться читабельным форматом, например, перечислить через точку с запятой имя поля, тип и размер (если он есть):

   id;int
   name;varchar;10
   dt;datetime

Можно также хранить тип в виде числа объявленного в Const.

Для данного задания точкой входа является BufferManager.executeQuery, который принимает queryPlan - список из операций (Операция определяется как отношение, тип операции (на данном этапе это full_scan) и предикат).

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

   table1.data:32

executeQuery запрашивает у SchemaManager файл с данными. Так как нужно выполнить операцию full_scan, то первоначальный адрес страницы, которую нужно загрузить в память будет table1.data:0, нужно проверить, загружена ли она в таблицу трансляции, и если нет, то с помощью DiskManager считать ее.

Также нужно, чтобы у страницы (Page) была ссылка на следующую страницу.

1. BufferManager должен использовать свое адресное пространство при загрузке данных с диска (строить таблицу трансляции). Физический адрес - путь к файлу и смещение для перехода к нужному блоку.

2. Добавить команду добавления записей в таблицу. При этом расположение записей на блоке должно быть оптимальным для схемы.

Как только блок заполнен, его нужно сохранить на диск. Если блок изменен, то через несколько операций (или по таймеру) он также долже быть сохранен на диск.

Блок должен относиться к одному отношению. В блоке должны быть: ссылка на схему отношения, ссылка на следующий блок, бит переполнения (используется, если запись не поместилась в блок целиком)

Схема отношения должна содержать адрес файла, в котором находятся блоки с записями.