GraphDB

В корне проекта находится .env.example. Вы можете его отредактировать по своему усмотрению и переименовать его в .env для запуска приложения.

Важно: в корне проекта всегда должен находиться файл .env, иначе проект не запустится.

Для запуска выполните команду

make run

Для сборки исполняемого файла выполните команду

make build

Принцип работы

Этот проект - реализация распределенной графовой СУБД. Поддерживает операции на модификацию и на чтение, причем операции на модификацию отправляются исключительно лидеру кластера, а на чтение - любому узлу в кластере.

Достижение консенсуса

Для достижения консенсуса при выполнении операций модификации использован алгоритм Raft. Это позволяет сделать операции модификации надежными и в конце концов выполнимыми на всех узлах. Для записи/удаления/модификации мы отправляем запрос к лидеру, который производит запись в журнал. Далее лидер отправляет эту запись всем последователям, и только после того, как большинство последователей сохранили эту запись, операция считается зафиксированной.

Выполнение DML-операций

Сейчас СУБД позволяет отправлять простейшие запросы извне, например создание/получение узла. Пример таких запросов (cURL):

Создание вершины

curl --request POST \
  --url http://localhost:8080/raft/vertices \
  --header 'content-type: application/json' \
  --data '{
  "table": "main",
  "record": {
    "properties": {
      "money": 100
    }
  }
}'

Получение вершины

curl --request GET \
  --url 'http://localhost:8080/raft/vertices?id=1ed622f0-31e7-4bb0-ad35-a4e6bef2bf9e&table=main'

Потенциал для доработки

Управление таблицами

Сейчас не реализованы операции добавления/удаления таблиц и схем (DDL-операции). При запуске создается таблица main для узлов и схема данных money (src/raft/node.go). Эти операции необходимо реализовать аналогично DML-операциям.

Конфигурация без обязательного файла .env

Сейчас наличие файла .env в корне проекта обязательно. Это поведение можно поменять в src/app/env.go.

Запуск на нескольких машинах

Текущая реализация - демо-вариант, который позволяет быстро запустить несколько узлов на одной машине. При необходимости логику запуска можно поменять в src/app/server.go. В данный момент при запуске мы опираемся на количество адресов в .env, и по количеству адресов мы запускаем соответствующее число узлов.

Внедрение шардирования

Внедрение шардирования для графовой БД - тяжелый процесс, и потребует большого числа доработок. Во первых потребуется некий оркестратор, который будет определять, на какой узел мы должны отправить запрос по содержимому самого запроса. Сейчас уже имеется оркестрация запросов к лидер-узлу для операций модификации в src/delivery/server.go, однако реализация оркестрации по содержимому будет выглядеть сложнее: потребуется определиться, будет ли атрибут, по которому мы шардируемся, динамическим, или же это будет ID вершины/ребра. Возникает так же вопрос: как мы должны хранить ребро между узлами на разных шардах, к какому шарду будет относиться это ребро?