Может стоит оптимизировать ненужную нагрузку? в плане — если вместо 100

апдейтов можно сделать один, или вообще один INSERT сделать — то так и поступить?

возвращаясь к вчерашнему разговору — не пытаемся ли мы тут натянуть технический долг на возможности базы и/или железа?

Или хотя бы не в один поток...

ну вотя. вам реальный кейс и расписал. Это нужная нагрузка. Считайте что куча девайсов пишут хартбит(свое состояние) постоянно. Инсертом заменить можно, но через 24 часа база кончиться ))) Ну понятно что в той или иной степерни, можно частично решать железом, купить х5 сервер, ядра с большей частотой диски выдающие в 100 раз больше перфонмас - и наверно будет чуть лучше. Но мы говорим про целесообразность. На одном среднем (не дешевом) железе база для моего, специального патеррна нагрузки выдает вот такой плохой результат. Конечно по хорошему - надо логически шардировать и сделать много белких баз. Но иногда это можно, иногда сложно и не целосообразно а иногда вообще не возможно

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

Как-будто нагрузку ДБА создают... Мы только имеем, что имеем, и страдаем от этого. А уже есть ли инструментарий, как проблему пофиксить, или нет, зависит, в том числе, и от СУБД...

ну акционеры и руководство обычно не оценивают закупку серверов на млн$, как «что-то подшаманить». Я повторюсь что в описанном выше кейсе - кроме как шардировать и распилить базу на много мелких - другого целесообразного рещения нет

здесь архитектура базы должна быть построена под такую нагрузку. Это типичный случай append-only и постгрес справится не хуже оракла. А вот с десятками тысяч случайных апдейтов от десятка до нескольких сотен строк одной таблицы с миллиардами записей - уже нет

true

Ещё нанять спецыалиста по постгресу (хотя бы временно).

Вас?

толстый и некрасивый троллинг, фу

а почему бы не поставить перед посгресом что-то (kafka) с пред-агрегацией всех апдейтов и подачей в постгрес готового результата за временной промежуток?

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

вы говорите про общий случай, Jamal говорил про Golden-Gate репликацию из Oracle в Postgres и я отвечал именно на его частный случай

Да все можно сделать, просто одно можно сделать быстро и не напрягаясь, а с другим и с бубном поплясать надо будет, но все равно сделать. :)

накапливать батч - можно было бы (репликакция кстати так и делает, я тестировал и батчем по 1к строк и по 5-10к строк), но это сильно не помогает. Но это не решает в общем то проблему. Представьте у вас есть 10млн девайсов и бизнес требование - кажлдые 10 сек получать их стейт. То есть в сек вам нужно обновлять 1млн устройств. И разумеется они пишут в случайное время а не все сразу в одну миркосек. Накапливая батчи - вы просто не уложитесь никогда в подобные требования и девайсы будут обновлять не каждые 10 сек а намного намного реже

ну да я примерно это и расписал, чуть подробней

А вы уверены что вам ОЛТП нужно? А не носкуел какой нить?

А там что-то ценное в этих стейтах есть? Я к тому, чего б это тупо в клик не писать? У него скорость записи будет в разы больше реляционок строчных... 🤔 Ну, и аналитику гонять из него тоже проще. Без апдейтов, разумеется. Он их не умеет

выглядит как проблема сайзинга под конкретные требования. и, также, следует рассмотреть другие БД, как коллеги советуют выше

Там не аналитика а real time платформа. Да и клик вообще апдейты плохи кушает. Еще хуже чем ПГ, но это другая тема ))

Или хотя бы не в один поток этот миллион update запускать... Так-то в общем выглядит не так чтобы чрезмерно для пары сотен ядер.

ну тоже вариант конечно. Но вы можете предложить другую БД для этого кейса (оракл не предлагать, в нем итак счас все работает хорошо) ?

Я пропустил определение базовой задачи. Вам надо собирать и хранить сосояние кучи объектов и строить аналитику по ним?

давайте хотя бы без аналитики, Бог с ней. просто иметь всегда стейт 10млн строк, которые обновляются с огромным апдейт-рейтом и делать селект по ключу/девайсу. Вот такая задача, чистый oltp

ELK-стек гляньте

нет, ELK это вообще другая и медленная тема, и к тяжелым oltp не подходит. Lucen двидок эластика - жутко медленный, у меня есть опыт работы с базой на этом движке