Могу придумать кейс когда индекс на поле по которому идёт поиск будет замедлять систему)

ошнь интересно ))

Особенно когда у тебя индекс супортит выборку которая нужна "в полночь" а пишут в нее весь день

Или там даже "выборка делается раз в минуту по крону но одним процессом а пишут много много процессов. Как итог перестройка индекса будет отнимать больше ресурсов системы чем помогать твоему крону

Так что "есть нюансы" а не "само собой"

а, ну я поняла о чем ты, тогда евент соурсинг ))

Шо это стоп слово такое теперь?

не поняла ((

А я не понял причем тут ивент сурсинг

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

хотя подожди, мы же не о праймери индесах говорим? разве простые индексы перестраиваются? Например на ту же дату если говорить о данном кейсе

что такое индекс и как он работает? что происходит когда ты меняешь значение? Ну и еще от СУБД зависит. Например у PostgreSQL MVCC реализован таким образом, что апдейт это вставка на самом деле + отметка для предыдущей версии строки что мол оно уже не нужно (то что dead tuples). мы в любом случае должны взять наш btree и вставить в него новое значение с указателем на новый ряд. Вставка в btree это O(logn) как правило, то есть занимает время, пуская и не оч много. Ну и все это надо записать.

если бы индексы не накладывали оверхэда СУБД бы давно научились их автоматом генерировать на основе статистики

в случае того же PG есть например трюк - heap only tuple. Мол представь что ты делаешь какой-нибудь leaderboard. у тебя там чуваки которые постоянно пишут свои результаты в табличку и ты хочешь выстраивать по этой табличке рейтинг игроков. Что бы table bloat не вызывать и т.д. можно заюзать HOT апдейты для таблички (https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/) но в этом случае нельзя индексы на колонки которые обновляются вешать. Что в целом не проблема так как рейтинг ты будешь пересчитывать условно по крону или в цикле из одного процесса и тот факт что там будет скан всей таблицы не сильно проблема.

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

простой способ  - отдать планирование оповещений на откуп какому-нить гуглу, он будет стучаться когда надо с id-шкой на api endpoint и будет запускаться выполнение оповещений 🤔
но вообще наверное тут вся сложность в том, чтобы сделать скейлящиеся delayed оповещения
я не знаю сколько выдержат всякие MQ с дилеем, но может быть тоже много

у меня это просто табличка с таймстэмпом "когда тебе надо" и скрипт который в бесконечном цикле выгрибает те что прошли. таймаут вышел - сообщение идет обратно в очередь. Очень гибко, не зависит от транспорта, надежно (хаки с priority queue + dead letter мне не понравились, воровал идею у nservicebus)

тут наверное у человека проблема что рекурентные штуки... иначе объяснить таких сложных предложений не могу. но для рекурентных штук есть свои решения. Ну и опять же там фигурировало "миллиард запией" - вообще хз че там обсуждалось. ремайндеры уровня 10-ти фэйсбуков?

Уровня зендеск.

Добрый день. Подскажите у symfony http client есть что нибудь по типу хэндлеров в guzzle ?