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

Question

[Дмитрий]

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

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

В идеале, я мог бы писать в файлы, но нужна масштабируемость. Данных будет очень много.

Comments

[Дмитрий]

Василий Банников, будут храниться события окружающей среды:
- дверь открылась
- муравей пробежал
- и т.д.
В нём json есть?

[Slava Rozhnev]

Блок-чейн

[alexalexes]

Первый пункт тоже доставил удовольствие. Если вы не хотите разбираться в инструменте разработчика, то вы - не разработчик, вы только заказчик системы.
По второму. Решается разграничением ролей пользователей. Администратор/разработчик/архитектор, естественно, может все менять. Рядовой пользователь - только в рамкам выделенных функций.
Если речь идет об административном ограничении. То администратор/разработчик/архитектор - должны работать в одной фирме, а рядовой пользователь - в другой. Соответственно, получать зарплату из разных бухгалтерий. И деловые отношения должны сформированы так, чтобы они друг другу волки были - друг друга контролировали.

[Василий Банников]

Дмитрий, ну тут tigerbeetle уже не подходит. Чем постгрес не устроил?

[Roman K]

монструозность (никаких postgres)

хаха

[Дмитрий]

Василий Банников, потреблением ресурсов. Нам нужен 1% от функионала pg.

[Василий Банников]

Дмитрий, ну раз будешь использовать 1% функций, то и нагрузка от него будет 1% от потенциальной)
Там достаточно много всего настраивается и можно, чтобы снизить нагрузку. У меня он вполне успешно на слабеньком SBC работал.

[Сергей delphinpro]

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

В идеале, я мог бы писать в файлы,

=)

Answer 1

[Василий Банников]

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

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

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

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

Из требований не вижу никаких проблем использовать постгрес, кроме хотелки "как можно проще"

Answer 2

[mayton2019]

- Минимальный функционал, малое потребление ресурсов (никаких postgres)

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

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

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

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

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

Вот такие у тебя варианты. Думай.

Answer 3

[nnn Xion]

посмотри в сторону Cassandra

Answer 4

[hx510b]

Можно взять MYSQL и зарезать пользователю права на удаление записей )), либо написать к нему REST сервис, который будет принимать данные и не удалять. А можно и то и другое - будет двойная устойчивость.