Привет, Хабр! Создание небольшой системы управления базами данных - это всегда прекрасный опыт и способ почерпнуть новые знания или же, закрепить уже существующие навыки. В этом цикле статей мы попробуем собрать нашу небольшую СУБД с использованием стандартной библиотеки Go :P
Требования
Начнем с определения требований, которые мы хотим выдвинуть к нашей будущей СУБД (далее для позерства удобства будем называть ее repaDB). Здесь выделяют множество этапов, но если кратко это буквально несколько вопросов:
Зачем будем над этим работать?
Что будем делать?
Как это будем делать?
Какие у нас сроки?
Пойдем по порядку. Зачем мы будем над этим работать? Конечно же ради three hundred bucks бесценного опыта или школьного/студенческого проекта, но естественно, у больших дядечек, это будет "решить какую-то бизнес-задачу и, если получится, пополнить свой кошелек парой тройкой миллионов".
В общем и целом, на этом этапе обычно определяют нужно ли вообще заниматься проектом и тратить на него ресурсы, а также анализируют - можно ли обойтись существующими альтернативами. Так вот, ниже ответ на прозвучавший буквами вопрос:
Проанализировав рынок и осознав, что, о боже, таких проектов
очень многоеще не существует на рынке, нам необходимо создать свою открытую базу данных, хранящую информацию по принципу ключ-значение, которая в срочном порядке заполнит существующую нишу и получит 100500 звезд на GitHub.
А теперь к следующему вопросу - Что будем делать? Здесь нужно понять, что именно мы (или наш big boss) хотим видеть в итоге от проекта. Наша цель - это хранить данные, в памяти, по принципу ключ-значение с неким TTL (ak Time to Live, ak время жизни). Любую цель можно достичь разными путями и наш случай не исключение. Так например, мы можем использовать уже готовое решение, либо же попросить кого-то написать за пачку дошика или *тут синоним к слову стащить*. Но мы с вами люди интеллигентные, поэтому будем писать своё собственное решение. Таким образом ответ на второй вопрос будет:
Создание собственной БД является наилучшим и самым оптимальным решением, т.к. это позволит нам укрепить сообщество вокруг наших продуктов и иметь гибкий, и легкий инструмент,
а также потенциально, когда-нибудь, получить оффер в крутую компанию
Определившись с тем что и зачем, перейдем к основополагающему вопросу - как это вообще сделать? Вопрос по истине уникальный и содержит в себе много подразделов, но мы с вами сделаем все на легке и не будем глубоко заходить в дебри проектирования. Перейдем сразу к примеру:
Наша СУБД должна уметь следующее: позволять подключаться по TCP, сохранять данные в память, безопасно их читать, обновлять, удалять данные и проверять существование некоторых ключей, а также иметь собственную библиотеку для удобства разработки (так как без этого будет сложно взаимодействовать с нашей базой данных, если вообще возможно). Все выше перечисленное - это бизнес требования.
Из бизнес требований вытекает то, что у пользователей должны быть все выше перечисленные возможности, что и является пользовательским требованием (т.е. требования описывающие действия пользователя).
Выходит, наша ИТ система должна иметь весь выше перечисленный функционал, а это уже функциональное требование, т.е. требование описывающее поведение системы.
Так же, все данные мы будем хранить в формате JSON на диске в виде файла, а также общаться с базой данных по TCP при помощи клиента, либо библиотеки для Go - это все уже не функциональные требования.
Ну и как итог, нам нет необходимости хранить сложные структуры такие как массивы, map'ы и т.д., и поэтому в качестве значения к ключу могут быть только типы данных string, bool и int. Это ограничения нашей системы.
Конечно, есть и последний вопрос - какие сроки? Но все мы понимаем, что это будет необходимость все сделать до "вчера" и отрефакторить когда-то потом. Так что мы не будем тут останавливаться надолго и перейдем к следующему разделу.
Структура проекта
Закончив с определением требований к нашему будущему must have решению, и потеряв по пути где-то этап с созданием ТЗ, мы переходим к структуре нашего будущего проекта. Это будет несколько репозиторием, т.е. все части проекта будут находиться в разных папках - модулях (а вы думали? у нас тут все по взрослому!). Каждый из модулей, будет основываться на стандартных принципах построения структуры go-приложения описанных вот тут.
Ниже список с описанием каждого модуля:
repa-db - здесь находится основной код нашей базы данных
repa-cli - а тут находится код cli-клиента к нашей repaDB
repa-client - ну, а тут соответственно код библиотеки для Golang
Описание структуры модулей в отдельности, мы будем рассматривать в соответствующих статьях посвященных тому или иному модулю.
Заключение
На этом пока все. Это моя первая статья из цикла создания СУБД в которой я разобрал кратко создание требований к проекту и также кратко определил его структуру. Если есть замечания или вы хотите поделиться идеями? Буду рад почитать! Более подробно и с примерами кода можно будет ознакомиться позже.
SiGGthror
Крайне холиварная формулировка.
https://github.com/golang-standards/project-layout/issues/117
Не совсем ясно что конкретно имеется в виду, хотя на мой взгляд в БД именно хранение и доступ к данным - самая интересная часть.
kanelecake Автор
Согласен, но так называется данный шаблон. Мы его не будем брать как икону, а будем использовать своё, поглядывая туда
Об этом подробнее поговорим, когда приступим к написанию базы данных)
slisli
Из за названия репозитория стандартом он всё равно не становится.
kanelecake Автор
Это да, но его не совсем удобно называть как шаблон проекта (звучит еще хуже), да и тем более на многих курсах его дают в пример) Но на мой взгляд, не очень удобный.