Там в 4 версии даже аналог foreign keys есть, мы его попробовали в новом пилотном проекте - и оказалось, что без него скорее лучше, потому что появляются непредсказуемые краевые эффекты у агрегирующих запросов к репликасету.

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

Я сделал просто materialized view и всякий раз при синхронизации с внешним сервисом оно само собой пересчитывается. В nosql это вроде есть, но в Кассандре, про монгу не знаю. Если бы я стал это запихивать в DynamoDB, то пришлось бы пересчитывать всё руками.

это в какой базе matview сам пересчитывается? )

В ms sql

Да и в постгре тоже, вроде

я только про оракл слышал.
а там инкрементально или целиком?

неа

Инкрементально, я думаю

CREATE VIEW [dbo].[SurveyByServiceProvider] WITH SCHEMABINDING
AS
SELECT SUM(reviewRating) AS SumRating, COUNT_BIG(*) as Cnt, ServiceProviderEmail
FROM         dbo.SocialSurvey
GROUP BY serviceProviderEmail
GO

CREATE UNIQUE CLUSTERED INDEX idx_SurveyByServiceProvider
   ON [dbo].[SurveyByServiceProvider] (ServiceProviderEmail);

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

А, не, ServiceProviderEmail в конце просмотрел ) тогда может и даст

Вообще забавно - всю жизнь пишу поля для группировки вначале.  Чтобы group by 1,2,3,4 можно было написать (не повторяйте это дома)

Это наверное хорошая практика.

+ одно правило про порядок агрегатов в анализатор )))

Это один способ решения проблемы. Можно придумать другие: например организовать отправку новых отзывов в очередь с exactly once delivery (AWS SQS или RabbitMQ) и агрегировать эту очередь, переводя её в простые инкременты. Это драматически снизит нагрузку на систему, имхо.

>exactly once delivery (AWS SQS)

Нет там exactly once delivery, только в FIFO. И это экстремально глупо, из-за сотни новых записей поднимать очередь сообщений.

А чем плохо FIFO? Оно ещё и порядок гарантирует, полезно, если, например, отзывы можно редактировать.

Зависит, опять же. Ну если вы например уже в AWS, то сервисом больше, сервисом меньше. Если у вас уже есть где-то RabbitMQ - просто ещё один топик в нём будет.

Кстати, про exactly once delivery в RabbitMQ я тоже слышу впервые. Возможно это и работает при одной ноде RabbitMQ, но что делать, если получатель умер?

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

Там есть механизм ack, если получатель взял сообщение и не ackнул его за заданное время - оно возвращается.

Это называется at least once