search

iu7og / bongodb

🌋 Database with real smoking stuff
GNU General Public License v2.0
5 stars 0 forks source link

Придумать архитектуру проекта #7

Closed mRrvz closed 2 years ago

mRrvz commented 2 years ago

Необходимо немножечко подумать и придумать:

Justarone commented 2 years ago

Первая версия, не является конечным и неизменяемым, замечания, предложения приветствуются. Делю на 3 комментария для простоты обсуждения.

Важные архитектурные решения :building_construction:

Размер ключа

Одним из наиболее важных решений, которые нам нужно принять на начальном этапе, является решение об ограничениях на ключ. Есть несколько вариантов:

  1. ключ имеет фиксированный размер в байтах, возможно еще ограничение сверху, задается для кластера (например 4 байта, в случае uint32_t ключей, максимум uint128_t - 16 байтовые ключи).
  2. ключ имеет произвольный размер в байтах (то есть разные ключи могут быть разного размера), имеет ограничение сверху на размер.
  3. ключ имеет произвольный размер и не имеет ограничения (в рамках разумного, какое-то ограничение все равно будет, наверное).
  4. ключ может быть составным, содержать в себе несколько идентификаторов (экзотика, но есть плюсы), некоторая многоуровневая схема
    • пример: ("{UserID: 1, CountryID: 2}", "Petya") - и в дальнейшем можно накрутить функционал выборки по какой-то части ключа, но это уже не совсем про key-value, конечно.

Взаимодействие

Интерфейс СУБД: Скорее всего это будет gRPC, потому что на сегодняшний день это наиболее популярный способ HTTP API, но можно попробовать и REST API.

Метрики: Предлагаю начать с graphite и его paintext или pickle протоколов. Оба очень простые:

Логи: Вижу 2 варианта с наименьшим сопротивлением:

  1. собирать локально в определенный файл, а клиентское приложение с помощью магических devo :dog: ских технологий соберет эти файлики (netfs и прочие хаки)
  2. клиент дает ручку нодам и собирает в реальном времени (но лучше конечно еще файлик накрутить, чтобы можно было и прошлые логи посмотреть)
Justarone commented 2 years ago

Инфраструктура :factory_worker:

Клиентское приложение

Ответственный: @hackfeed

думаю, что CLI будет наиболее удобным и простым вариантом (можно обсудить)

Предполагается, что это будет что-то вроде:

> bongodb_cli --cluster cluster.yaml --trash-talk
Oh, bruh, you're ready to smoke, sheeeesh :smoking: 
> put [(12, "gangsta"), (23, "smoke")]
Sheeeeesh.
> get [12, 23, 34]
[(12, "gangsta"), (23, "smoke")].
> delete [12]
Sheeeeesh.
> get [12, 23, 34]
[(23, "smoke")].

Приложение мониторинга

Ответственный: @hackfeed

Думаю, что тоже можно CLI.

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

Для сбора логов @hackfeed нужно придумать формат взаимодействия (желательно наиболее простой для цпп еще...), здесь есть пространство для креатива. Полагаю, что сама программа должна форматированно показывать логи кластера, например (формат тоже можно обсудить):

# [LEVEL][host][shard:replica] message
[DEBUG][127.0.0.1:3001][3:1] write key 12
[DEBUG][127.0.0.1:3002][3:2] write key 12

Возможно стоит это объединить во что-то одно более целостное.

Justarone commented 2 years ago

База данных :beach_umbrella:

Я спать, выйдет попозже :sleeping:

hackfeed commented 2 years ago

В дополнение к словам Паши.

Собираемые метрики

Для оценки состояния кластера стоит собирать:

Способ сбора метрик

Метрики будут поставляться в модели Prometheus. Для этой модели есть C++ инструмент для экспорта метрик + можно бдуте подружить Prometheus с Grafana для мониторинга.

Способ сбора логов

Для логирования будем использовать C++ spdlog. Логи будут записываться локально в файл и syslog по каждой ноде, CLI тулза будет заниматься организацией и выводом логов.

hackfeed commented 2 years ago

Решаем в рамках отдельных задач оставшиеся вопросы