@pls-kick-me

Какую БД выбрать?

Подскажите, пожалуйста, стоит вопрос выбора базы данных для хранения событий окружающей среды. Вот критерии:

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

В идеале, я мог бы писать в файлы, но нужна масштабируемость. Данных будет очень много.
  • Вопрос задан
  • 179 просмотров
Пригласить эксперта
Ответы на вопрос 4
- В идеале невозможность удаления записи даже тем, у кого есть к ней доступ. Событие произошло, оно не может исчезнуть (скорее всего, такого фунционала не существует и такой механизм достигается другими способами? Например, односвязный список хешей. Но его злоумышленник тоже может переписать. Может по этому пункту есть готовые механизмы?)

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

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

Что вообще за данные храниться будут?
Если это какие-то финансовые транзакции, то можно посмотреть на tigerbeetle, тк он в общем-то на это и нацелен: append only, оптимизирован для финансов (Используется концепция счетов, где с одного уходят деньги, а на другой приходят), масштабируемый, имеет огромную пропускную способностью (под миллион TPS).
Из преимуществ - главный минус: абсолютно никакая гибкость.

Из требований не вижу никаких проблем использовать постгрес, кроме хотелки "как можно проще"
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
- Минимальный функционал, малое потребление ресурсов (никаких postgres)

Насколько минимальный? Тут по идее подходит key-value система (Mongo, CouchDb, Tarantool). Но если ты захочешь сделать join то тебя ждет облом. Такая операция обычно не заложена в архитектуры key-value.

А какой-то промежуточный гибрид между SQL и key-value скорее всего не существует в природе.
Если уж вводить join - то это реляция. А реляция - это RDBMS.

- В идеале невозможность удаления записи даже тем, у кого есть к ней доступ.

Здесь подходит определение event-store. Сам продукт тоже так и называется https://db-engines.com/en/system/EventStoreDB

Вот попробуй его. Но для делания запросов по такой БД там надо создавать материализованные
представления. А это означает что надо просто глубже обсуждать твою архитектуру. Просто
так... поплевав в потолок тут невозможно выбрать продукт.

Вот такие у тебя варианты. Думай.
Ответ написан
Комментировать
nnnLik
@nnnLik
Capybara god
посмотри в сторону Cassandra
Ответ написан
Комментировать
@hx510b
"Я знаю, что ничего не знаю"
Можно взять MYSQL и зарезать пользователю права на удаление записей )), либо написать к нему REST сервис, который будет принимать данные и не удалять. А можно и то и другое - будет двойная устойчивость.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы