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

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

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

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

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

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

600 в секунду и всё заваливается.

это всё равботает до тех пор пока тебе клиенту скажем не надо вернуть айдиху сущности которую назначает база.

клиенту возможно нужен айди чтоб создать новую сущность которая имеет связь с ранее созданной и сохраненной.

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

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

какой батчинг? я не с файлика данные копирую.

Что там за железо чтоб тащить 250ксек?
Майтон я все понимаю за постгрес но его потенциал роста вверх в моем случае исчерпан. Вот и чешу репу чтоб и два горошка скушать и на стул сесть

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

по поводу конфиги. у меня бд не ссд (я хз что еще оказывается не ссд бывает но так девопсы сказали) 24 ядра хз сколько оперативки.
при озвучанных выше значениях начинает просто каждый последующий инсерт вставляться все дольше и дольше и так до 5-ти минут на простой инсерт!

то что в кавычках - поясняю. если пропадет 1% данных - то это не будет страшно. если пропадет 50% данных - то это плохо.
асинхронно писать - потому что я не вижу особо выхода. либо вертикально скейлить бд, либо думать всякую фигню с репликами. либо переписывать код. всё.

ну я по-сути хочу что-то такое же.

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

так я этого еще не сделал. я рассматриваю варианты. почему ты пишешь в прошедшем времени?

по твоей логике все эти акки кафки и прочее что не гарантирует доставку - фигня на постном масле и глупые выдумки. ничего кроме православной синхронки с гарантиями не существует.

какой код? там приложение простое как топор - получил данные обработал данные сохранил данные отдал клиенту результат обработки. вроде не рокетсаенз чтоб это рассматривать чем то фантастически нетривиальным.

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

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

это мой предыдущий шаг перед тем что я выше сказал. если не поможет. а скорее всего не поможет.

Выше вон говорят 250 тыщ норм и 600 - ниачем.

Как мне батчи формировать. К меня может быть как 0-1 запрос в секунду так и 600 запросов. Придумывать костыли типа если вот сколько ол времени новых данных нет то скидываем то что есть и прочее уныние. Не. Да и особо не помню дикого прироста с переходом на батчинг кода это делал давно да вставлять стало быстрее но чуда не произошло.

Апдейтов практически нет. Инсерты онли.

Так у меня не биллинг)) еще раз. Основная цель приложения - процессинг данных и возврат результата клиенту. Сохранение данных - это цель с наименьшим приоритетом. Не обязательно условно сразу.
Требования к системам бывают разными. В моем случае они таковы. Не надо требовать то чего не требуется)

Батчинг.. Ну вколочу я батчинг а он даст перформанс + 20% - это время в ведро.

Плюс опять же. Мне надо будет из батча вытряхнуть все новые айди записей раздать их всем ожидающим по каким то там признакам причем я не уверен что батчи это умеют. Эээ да харош))

Да. По ууид это единственное тут решение. Отвязываемся от базы и спим спокойно.
Насчет батчинга. Еще раз. Я не файл ксв в базу импортирую. Я с живым и непредсказуемым трафиком работаю.