Size: a a a

Software Design/Architecture/Zen

2021 June 28

SP

Sergey Protko in Software Design/Architecture/Zen
ну то есть это не вопрос СУБД. 140 гигов или даже там 1 терайбат это не сказать что прям оч много что какой-нибудь постгрес не выдерживает. Индексы в память помещаются? ну и ладненько. Но в целом от разбиения можно выйграть сильно за счет более специализированных моделей данных
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
и вряд ли дебит-кредит занимает в базе большую часть
источник

DK

Dmitriy Knyaginin in Software Design/Architecture/Zen
ораклина держит это всё сейчас в принципе... отчёты на больших промежутках дат притормаживают 😂
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну прикол в том что для репортов микросервисы всегда будут "притормаживать" (если конечно не увеличивать стоимость сильно и вводить какие-то ETL/ELT). Тут ты упираешься в "достать данные". А представь насколько это будет дороже если за данными надо по сети ходить (даже если мы говорим про какие-нибудь фичи типа федерации и т.д,)
источник

DK

Dmitriy Knyaginin in Software Design/Architecture/Zen
самая большая таблица по количеству строк... это таблица с платежками, её можно секционировать или шардировать в принципе, по ней и аналитика должна быть... типа сколько ещё должны заплатить.... за остальные таблички волноваться нет смысла, так как мне видно что больше 80% времени работы субд приходится на эту таблицу
источник

АГ

Алексей Гевондян... in Software Design/Architecture/Zen
а как на счет архивации?
источник

DK

Dmitriy Knyaginin in Software Design/Architecture/Zen
есть тут хорошая новость... вся аналитика на предыдущий день... и передыдущий день уже не поменяется... низя документы "провести" задним числом...
источник

ST

Serguei Tarassov in Software Design/Architecture/Zen
Похоже на типовой биллинг. "Платежка" - это документ, по нему вообще не должно быть никаких расчетов. Документы генерируют операции прихода-расхода с пристыкованными разрезами аналитики, вот по ним все считается
источник

DK

Dmitriy Knyaginin in Software Design/Architecture/Zen
похоже, но тут своя мультивселенная с бизнес процессом... скажем так кто-то боится заплатить лишнее, или заплатить не вовремя, поэтому и расчеты такие есть...  и бизнес процесс менять никто не будет, так как там куча нормативки...
источник
2021 June 29

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Как вы выбираете сущности из репозитория, создаёте на каждый случай свой метод?
источник

EE

Evgenii Evgenivich in Software Design/Architecture/Zen
Рид / райт модели

Репозиторий или агрегат стор - > только получение по id и запись.
источник

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
То есть в том же ApplicationService мы запрашиваем данные из "рид модели" и дальше дергаем по id из репозитория?
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
а можно чуть подробнее кейс? Зачем рид модель вообще?
источник

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Для отображения данных
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
а зачем тогда дергать репозиторий по ид?
источник

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Это был вопрос к Евгению, как он это понимает
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
к Евгению у меня вопросов нет, я согласен с тем, что он написал. Я не понимаю как у вас в одном сообщение получилось app service, read model, repository дергает по id
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
что это за операция такая
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
обычно, если вы меняете агрегат, то вы знаете его id и соответственно из репозитория берете агрегат по айдишке, если у вас необычный кейс, то попробуйте его описать
источник

СМ

Сергей Моисеев... in Software Design/Architecture/Zen
Операция обновить статус сущности по определённому критерию (дата, например). То есть множественное обновление.
источник