у меня задача была получать 50к данных новых, попутно получая 150к сообщений о дубликатах 🤣😅

в сек

Не, ну в в Рамблере же ОпенБЗД стояла на лоад-балансере. Умела утилизировать только 1 CPU (давно было,  SMP не написали ещё), так там покупали под машину разогнанные процы.

Стыд и позор

И что?

А, точно! На одном CPU же это сложно!

хрыч не уиноуат, там в пг баги и в микрокодах

Надо перемикрокодить микрокод и перебаговать баги. Известно же, что ПГ писан неумехами. Зрыч подтвердит

мне сказано было чтобы хост был с 1 цпу, я и взял

сигаев вообще индеец

Не, ну руководство же лучше знает, чокак

особенно весело когда оно поёт заказчику 1,5 года сказки, а потом тебе говорит - ну вот мы тут напели, а вы думайте как выполните

кароч итого
- баги в пг
- микробаги в микрокодах
- начальство мудаки
- хрыч красавчик

Так не надо выполнять. Самое страшное - уволят, и что?

никогда небыло и вот опять

Это на DO машина за 5 бачей в месяц? Неплохо. Хайлоад.

я там бумаг набрал, что я не несу ответственности и тд, шт 80

а вот ты чем занимался на работе вместо работы

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

Коллеги! А кто-то занимался аналитическими системами? Там вообще есть понятие при ETL для зон с "грязной" информаций и "чистой"? Я имею в виду не столько разделение raw данных и структурированных, сколько модерацию полученной информации.

На mssql до версии 16 в конструкции с «alwayson» репликой был  трабл с ограничением в 1 поток процесса наката лога транзакий на реплику = примерно 50 mbps лога в пике, вне зависимости от железа под ногами. В mssql 16 ситуация изменилась. Мы когда делали конструкции со стэндбаем для хранилища (olap+rolap) «на стеке микрософт» - упирались в это как блокирующий фактор, но сейчас вроде как не упираемся, со слов микрософта сейчас оно где-то в районе 500 Мбайт/сек, не проверял.