Привет, Хабр! Создание небольшой системы управления базами данных — это всегда прекрасный опыт и способ почерпнуть новые знания или же, закрепить уже существующие навыки. В этом цикле статей мы попробуем собрать нашу небольшую СУБД с использованием стандартной библиотеки Go 😛

Требования

Начнем с определения требований, которые мы хотим выдвинуть к нашей будущей СУБД (далее для позерства удобства будем называть ее 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

Описание структуры модулей в отдельности, мы будем рассматривать в соответствующих статьях посвященных тому или иному модулю.

Заключение

На этом пока все. Это моя первая статья из цикла создания СУБД в которой я разобрал кратко создание требований к проекту и также кратко определил его структуру. Если есть замечания или вы хотите поделиться идеями? Буду рад почитать! Более подробно и с примерами кода можно будет ознакомиться позже.