Здравствуйте. Подскажите плиз, как более корректно разделить доменные данные и

Question

Здравствуйте. Подскажите плиз, как более корректно разделить доменные данные и

аналитку/логи на разные БД и нужно ли.
О чем речь, просто пример. Например есть сущность баланс и история. История атомарно меняется с балансом в одной транзакции, все жестко и это устраивает. Не устраивает то, что история по большей части к работе домена никакого отношения не имеет. Записываем чтобы было и чтобы потом анализировали мы и клиенты через UI. Опять же база разрастается данными, которые там особо и не нужны для корректной работы приложения.
Возникла мысль складывать в какой нить nosql типа эластики, опять же через кибану все это удобно смотреть в случае чего.
При этом все же хотелось бы сохранить имеющуюся жесткость, чтобы история и баланс сохранялись атомарно и не нарушалась консистенция. Как насчет того чтобы сохранять так же в реляционку, но паралельно сохранять в nosql, например через ивенты для скорости обновления на UI, а потом еще периодически досинхронивать периодично по крону какой либо промежуток, для избежания неконсистенции. А в sql хранить только за последний месяц-два.
Норм, не норм вариант или какие есть хорошие практики?

#oop #programming #russian #software #web-design

0

15.07.2023

17 ответов

9 просмотров

Max Grom

Разделять нужно. Но менять формат данных не факт. Если у вас коректно подобраны структуры данных и вы используєте подходящую базу, тогда или не стоит менять это вовсе, или стоить менять с учетом того какого вида аналитика вам нужна. В любом случае, ваше приложение не должно знать ни о какой аналитике. Ваша аналитика должна собираться отдельно посредством подключения к реплике основной базы и/или к шине данных куда ваше приложение ложило бы информацию о своей работе

0

9 месяцев назад

Павел Г. Автор вопроса

Max Grom
Разделять нужно. Но менять формат данных не факт. ...

Ну это не совсем аналитика, это история. И для атамарности сохранения, она не может не знать совсем. Тут скорее идея, чтобы разгрузить а не освободить. И не просто про модель чтения. Задача уменьшить объем информации зранящайся в основной базе. От объёма все же и скорость записи зависит, да и вообще бОльшая часть бд захламлена именно такими "историями"

0

9 месяцев назад

Anton K.

Павел Г.
Ну это не совсем аналитика, это история. И для ата...

Если сделать там партицирование, то скорость будет норм

0

9 месяцев назад

Max Grom

Павел Г.
Ну это не совсем аналитика, это история. И для ата...

Вы просто начали за "аналитику/логи" а теперь это таки данные которые относятся к домену, если я правильно понял. Тогда не понимаю что вам разделять и зачем. Пишите тогда в две базы в место одной - вот и разгрузите

0

9 месяцев назад

Павел Г. Автор вопроса

Anton K.
Если сделать там партицирование, то скорость будет...

Для истории партицирование не и знаю как выйдет. Делать по юзерам - жёстко чёт. Делать по времени - не угадать партицию. Например история заказа. Не разбивать же в ui по месяцам.

0

9 месяцев назад

Павел Г. Автор вопроса

Max Grom
Вы просто начали за "аналитику/логи" а теперь это ...

Ну они как бы домен, но с другой стороны в логике не участвуют, просто пишутся

0

9 месяцев назад

Max Grom

Anton K.
Если сделать там партицирование, то скорость будет...

Так им писать нужно, а не читать, зачем им партицирование? 😊

0

9 месяцев назад

Max Grom

Павел Г.
Ну они как бы домен, но с другой стороны в логике ...

Ну пишите в две базы вместо одной - устраивает вас такой кейс?

0

9 месяцев назад

Андрей Рудин

читать когда анализируешь данные, потом уже.

0

9 месяцев назад

Павел Г. Автор вопроса

Max Grom
Ну пишите в две базы вместо одной - устраивает вас...

В две базы не получится атомарно

0

9 месяцев назад

Max Grom

Андрей Рудин
читать когда анализируешь данные, потом уже.

Ну так потом и будут читать и смотреть устраивает их скорость чтения или нет. В любом случае не вижу причин добавлять туда "партиции для скорости" прям сейчас

0

9 месяцев назад

Max Grom

Павел Г.
В две базы не получится атомарно

Почему не получится?

0

9 месяцев назад

Павел Г. Автор вопроса

Max Grom
Почему не получится?

Распределеные транзакции за счёт бд ?

0

9 месяцев назад

Андрей Рудин

Павел Г.
В две базы не получится атомарно

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

0

9 месяцев назад

Max Grom

Павел Г.
Распределеные транзакции за счёт бд ?

Вы у меня спрашиваете? 😁 Я ж не знаю что там у вас и почему не получится. Потому и задал вопрос. Очевидно что если разделять то разделять нужно будет слегка больше чем просто создать ещё одну базу

0

9 месяцев назад

Павел Г. Автор вопроса

Max Grom
Вы у меня спрашиваете? 😁 Я ж не знаю что там у вас...

Ну может технологии из коробки есть :)

0

9 месяцев назад

Anton K. · Accepted Answer

Эластику не надо рассматривать как надежное хранилище, ибо там потерять индекс проще, чем в rdbms. Я бы оставил как есть сейчас history, разве что порезал ее на партишны, чтобы быстрее данные доставать и проще их удалять целыми порциями по месяцу, допустим. И раз в сутки индексировал в solr/elastic для построения аналитики.

212 похожих чатов

Здравствуйте. Подскажите плиз, как более корректно разделить доменные данные и

17 ответов

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