Куда копать(что читать), дабы написать свою СУБД?

Question

[GlebLozhkovoy]

Для личного, учебного проекта хочется написать свою СУБД. Скорее всего реляционную (по большей части). Конечно, можно взять готовое решение, но неинтересно.

Хочется много теории. Готов читать про новые-модные решения, главное - про архитектуру. Жутко интересно как устроенно.

На первых порах требования такие:

• транзакции
• репликации
• хранение в файлах - свой формат, наверное
• http/socket доступ по сети ну это тупо технический аспект

Писать буду на Java. Никаких С/C++ или другого. Да, больше памяти(можно холиварить до конца 2038 года), но больше надежность. Плюс, когда свое и знаешь узкие места, то работает как часики. До чертиков восторгаюсь Hadoop, MongoDB.

Верю, что на хабре есть специалисты в области IR и БД. И как каждый специалист имеет любимую книгу по своему предмету. С каждого по книжке - и багаж знаний для построения есть.

Пока определил для себя: Managing Gigabytes: Compressing and Indexing Documents and Images.

Есть бумажная Introduction to Information Retrieval, на русском, зачитанная до дыр.

Answer 1

[Эдвард]

не книги конечно, а курс, но возможно вам будет интересно, там если я правильно помню как раз цель - создание своей БД
База данных (2012)
База данных (2013)

Comments

[GlebLozhkovoy]

Смотрел. От Ильи Тетерина просто балдею. Спасибо, за вторую ссылку. Посмотрю.

Оффтоп: еще долго ходил и его голосом говорил "И это тоже база данных. Все вокруг базы данных".

Answer 2

[FanatPHP]

Список требований выдаёт голубого мечтателя Манилова с головой.

На первых порах требования должны быть такие:

• хранение в файлах - свой формат, наверное

Вот убей годик на разработку того самого формата, да на освоение тонкостей работы с файловой системой - потом уже (при наличии достаточного количество человеко-лет) можешь начинать задумываться в теории о таких вещах, как транзакции и репликации. И путеводной звездой для тебя должен служить не Хадуп, а Скулита.

А вообще, настоятельно рекомендую начать с key-value хранилища.

Comments

[GlebLozhkovoy]

Держать в массив указателей(в джаве - ссылки[переменные ссылочного типа]) на объекты в heap, которые представляют любое value, по ключу? Разрешение коллизий по-обычному - equals, бакеты представлять хоть деревом, хоть листом. Иногда писать на диск, а при старте прогревать кэш. Разве это сложно? Согласен, могут быть подводные камни. Но пару тройку вечеров и свое локальное key-value хранилище, не боящееся внезапного отключения света уже есть. Позже слушать какой-то порт и выполнять коммандочки, отдавать данные по сети. В джаве есть все для того, чтобы писать отличные штуки быстро и просто.

Хочется услышать не ой какие большие требования, а примеры где посмотреть, что придумали другие ребята. Да и может почитать что-то существенное.

[FanatPHP]

Ключевое (неправильное) слово здесь - "держать". Вы рассматриваете БД как элемент программы. Но БД - это файл на диске. Который, теоретически, может не влезть в память. И даже одни ключи - тоже могут не влезть. В Джаве есть пного прекрасных вещей, но в работе с файлами есть не меньше прекрасного - блокировки, конкурентный доступ. Впрочем, я забыл, что речь идет об учебной подели, и потеря данных при попытке реального использования не рассматривается в качестве проблемы.

[GlebLozhkovoy]

Вот про эти подводные камни и идет речь. Безусловно любая коллекция данных может не поместиться в память. Тогда приходится работать с диском. Придумать варианты обхода таких ситуаций - идея занятная. С файлами реализовать алгоритмы с минимальным количеством бездумных перемещений головки по диску. И далее, по списку. Терять данные никто не хочет. Это проблема и интересны classic/nonclassic способы ее решения.

Пока, к сожалению, наш разговор сравним с киданием камушков в воду. Занятно, а пользы - ноль. На sqlite посмотрю поглубже, слышал много положительных отзывов про пользу изучения ее архитектуры, дескать, годно сделано.

[FanatPHP]

Я просто хочу продемонстрировать неадекватность оценки времени и ресурсов. Этим особенно грешат юные программисты и особенно на джаве.

Answer 3

[Konstantin Osipov]

Посмотрите в сторону Database sytems: the complete book Ульмана & co.
Без Dragon Book поддержку SQL не реализовать.
Для репликации рекомендую книгу Nancy Lynch по распределённым алгоритмам.
Реализация базового функционала реляционной СУБД с поддержкой SQL-92 где-то 400 лет в модели COCOMO.
В мире в данный момент активны более 300 различных баз данных, большинство из которых имеют открытый исходный код.
Удачи вам с вашим проектом!