мы когда говорим про пол петабайта данных то критично знать что ты с ними делать будешь что бы рекомендовать что-то.

Я не скажу что нагрузка адская, но примерно 10000 в день через систему проходит. В системе сейчас 50000 пользователей, одновременно работают думаю 5000. У системы большой техдолг и спираль смерти, толстый клиент. Поэтому с ней уже надо что-то делать.

Давай переформулируем есть ли готовые тесты монги и постгреса на хранение/обработку json/jsonb?

а сложно написать свои тесты?

в целом 10К в день это... тип... ну мало оч 10К в секунду еще можно обсуждать какие проблемы будут. А там до сотни в секунду вообще пофигу

не сложно... скорее всего так и поступим... написать код для меня лично не проблема... просто скорее всего надо ещё конфиги самой СУБД крутить... а там думается мне много сюрпризов... ладно заставим крутить эти ручки ещё кого нить

У нас на проекте сейчас пул и мы уже столько раз проебывались что туши свет. Возможно всё ещё висят баги что где то чужие данные светятся.

На пет проекте silo, мне прям очень нравится. Правда я какое то время назад зарефакторил по сути в коробочное решение, будет время буду разрефакторивать взад

А проводился ли основной тест "если перенести данные в нормализованные таблицы, то объем БД уменьшается в 10 раз"?

Оно как раз в нормализованных и хранится... Дело в том что там зоопарк костылей из всего что можно придумать... Там и триггеры и хранимки в бд и даже свой язык а-ля 1с.

А  то есть исходник уже в реляционке? Я неправильно понял значит. Ну тогда нужно аккуратное перепроектирование. Для OLTP таких объемов не бывает, да и в OLAP нужно четко разделять хранилища и витрины.
Вообще нужно сильно постараться, чтобы негенерить такой объем. Реальные данные по медстрахованию 15 млн клиентов за 5 лет в 20+ разрезах - единицы терабайт.

основная база сейчас 164ГБ... нормализованных данных... к ней ещё есть одна база с файлами там и док и эксель и пдф и подписанные эцп xml... всё в одной куче... за год там накапливается 5ТБ... недавно встал вопрос о новых интеграциях и новом функционале... началась короче торговля...  короче надо переделывать по последней моде на микросервисы распиливать... в связи с тем что там есть дебит-кредит от реляционки не избавится полностью... короче сложная задача 😂 которую кинули на меня... вот ищу баланс 😂

может файлы не в базе хранить, а в базе оставлять только референсы на эти файлы?

Да, ситуация непростая. Оптимизировать имеющуюся БД можно, но мне кажется, принципиальный момент - решить нужны ли здесь микросервисы, точнее, чем они будут лучше просто сервисов, без приставки "микро". Судя по написанному, нужна поддержка целостности, иначе дебет с кредитом не будут сходиться постоянно.

eventual consistency. И будет у тебя целостность. Просто в какие-то моменты не будет.

да вопрос нужно ли им в конкретной системе это или не нужно

ну из того что было озвучено проблем которые микросервисы решают я не наблюдаю. Так что не оч понятно что мы обсуждаем

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

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

ну вот да, если смысл разбить данные на разные сторы тупо по бизнес капабилитис - то норм че

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

сложность же "разбить по капабилитись" что бы при этом вопросы целостности/локальности данных не нарушались