или еще как.

в нашей сеточки по 10 млрд в месяц показов кртуилось

как-то всё считали...

я ещё раз вопрос повторю: почему возникла ситуация при которой надо табличку на табличку накатывать

с преагрегацией и прочими прелстеями

это имхо монго мышление табличку на табличку

в монге нет табличек

в нашей сеточки по 10 млрд в месяц показов кртуилось

чувак успакойся ) это не ртб\ссп\дсп\дмп етц, я 8 месяцев назад ушел из рекламы, мы откручивали 300млрд в месяц с монгами и не плакали.

я ещё раз вопрос повторю: почему возникла ситуация при которой надо табличку на табличку накатывать

смотри, первая коллекция это данные которые использует апп.

вторая коллекция это по факту вектор изменений.

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

это удобно, и позволяет нам не сканить 30м объектов и всех их чекать.

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

и сразу принимать решение?

какое ?

или решение только ретроспективно может быть принято?

«это позволяет нам знать о том, что необходимо пересчитать сегодня»

ну смотри, у тебя фильм скажем, написано "доступен для просмотра с 25авг до 1сент" а первоого числа нам скажут что он теперь доступен с 1сен до 31дек.

мне нет смысла каждый день для него чекать все его права информация о том что нада пересчитать 30дек попадет во вторую коллекцию и мы пересчитаем все это.

а вообще это забавная штука такие данные в базе считать

эм

а что мешает просто обновлять поле valid_before?

и фильтровать по этому полю?

30м объектов при правильной упаковке это мало индексов

я когда делал рисёрч для нашей штуки, у меня получилось для нашего кейса сделать штуку, которая хранит 10м событий в 360мб (210мб в snappy) + 50мб индексов

ой

простите, я вас наебал

500мб (240мб snappy) + 88 метров индексов

там 4 индекса

а вообще это забавная штука такие данные в базе считать

а что не так ? )

а что мешает просто обновлять поле valid_before?

я не уверен что 500к объектов обновятся быстро.

я расчитываю где то на 2к апдейтов/сек это будет 250сек.

Ну... есть разные методы...

говори, тока без постгри )

почему бы не держать горячие данные в каком нить erlang/scala и на акторах это все считать ? или включать выключать ?

думаю даже вполне себе реалтайм получиться

почему бы не держать горячие данные в каком нить erlang/scala и на акторах это все считать ? или включать выключать ?

и зачем ? это разовый процесс. раз в сутки, обновить каких то там 500к записей. а ты тут про скалу, эрланги, акторы хуе мое

и как они помогут я тож не понимаю рили.

проблема в том чтобы диф вмерджить максимально быстро

они будут по факту обновлять

я не уверен что 500к объектов обновятся быстро.

я ещё раз вопрос задам

не будет дифа

по факту мы и так можем

у тебя все 500к объектов обновляются _постоянно_?

когда заполняем коллекцию вторую.

ох.

я не понимаю зачем делать всё раз в сутки

500к это то что накапливается во второй табличке, и подлежит обновлению.

+1

это 3 апдейта в секунду

что вообщем то немного

потому что такие условия

условия внутренние или внешние?

типа вырубить доступ в 00:00 такого то числа

внешние

данные поступают снаружи строго раз в сутки?

нет,

они поступают снаружи в течении суток из различных источников

и раз в сутки их применить нужно.

и в чем проблема их процессить ?

и что мешает обновлять по мере поступления?

ох.

потому что в первой табличке у меня не даты. а флаг true \ false

чтот напутано с проектированием

короче, я пойду дальше работать

кажется... имхо

да

вот

а ты подумай чо не так

потому что у тебя там бардак походу

да все так ) просто вы не можете решить бзадачу )

потому что ты проблему ставишь неправильно

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

я ее не ставлю. она такая есть

я не вижу никаких костылей

я вижу источник данных, вижу место назначения этих данных

вижу трансформацию этих данных из даты во флаг

я вижу проблему в том что где-то флаги, а не даты :)

типа если время наступило мне нужно переключателем щелкнуть

идея «переключателя» очень плохая