AD
Хотя бы порядок
Size: a a a
2020 August 25
ΑZ
до тысячи компаний у юзера, до 100к активных заказов суммарно
ΑZ
каунтеры выглядят как эвентс сорсинг пришло-ушло
ΑZ
вопрос как их грамотно саггрегировать
С
вопрос как их грамотно саггрегировать
А можно это просто сложить в обыкновенный Постгрес, и посмотреть, будет ли оно тормозить? И добавить в него materialized view, если будет
ΑZ
если считать по каждой компании отдельно (не считать комбинаторику) то нельзя обойтись одним счетчиком, нужно множество заказов держать чтобы юнион работал
Но держать множество заказов для каждой компании и каждый раз искать пересечения дорого
Но держать множество заказов для каждой компании и каждый раз искать пересечения дорого
AD
Не надо каждый раз. Посчитай один раз при старте значения счетчиков и лови сообщения пришёл-ушел.
AD
Я бы микросервис для этого сделал, и в редисе данные обновлял
ΑZ
ну сервис понятно
ΑZ
Не надо каждый раз. Посчитай один раз при старте значения счетчиков и лови сообщения пришёл-ушел.
это и есть каждый раз)
ΑZ
причем непонятно что делать если у заказа добавляется/теряетяс компания
ΑZ
например, компания-перевозчик сменилась
ΑZ
ладно
ΑZ
пара мыслей появилась, спасибо
AD
Можно пересчитать пользователя
AD
Зависит от того как данные лежат
ΑZ
Можно пересчитать пользователя
пользователей много. На каждого напересчитываешься
С
Вы переизобретаете БД
AD
Одного только. Это ведь не супер частая операция
AD
Вы переизобретаете БД
В данном случае olap