оптимизации insert update запросов?
Никак
Всмысле никак. Серверы же как то принимают и по 1млн запросов
в бд обычно встречаются две противоречивые задачи: быстро читать (olap) и быстро писать (oltp). Для быстрого формирования выборки для чтения нужны индексы, которые мешаю быстрой записи. Таже не стоит забывать на наложенные ограничения (например уникальность записи), которые тоже могут тормозить запись. Нужно разбираться конкретно. плюс разные виды блокировок при параллельном доступе
Спасибо вам за развёрнутый ответ
Нормализация данных; вынесение чтение на реплику, чтобы мастер разгрузить; горизонтальное маштабирование. Если домен коллаборативный (т.е. N кол-во пользователей работает с одним ресурсом), то можно апдейты заменить на инсёрты (тогда пользователь будет получать результат операции позже)
Всмысле убрать инсерты?
Тот же вопрос. Я вроде не писал, что инсёрты надо убрать
Спутал, хотел написать всмысле апдейты убрать
В коллаборативных домене, при апдейте одной строки, будут блокировки, а соответственно, все конекшены будут выстраиваться в очередь и ждать пока блокировка отпустится. Если разрешать делать инсёрты, то блокировок не будет. Пример: 10000 пользователей одновременно пытаются купить книгу, бестселлер. Ты не можешь продать больше, чем у тебя есть. Придётся блокировать строку, которая отвечает за кол-во на складе, и уменьшать кол-во при каждой успешной покупке. Все 10000 пользователей выстроятся в очередь из-за блокировки строки (скорее всего намного меньше, потому что коннекты к бд закончатся раньше). Решение может быть таким: Убираешь апдейты строки, ответственной за кол-во книг на складе. Разрешаешь всем делать заказы т.е. инсёрты. Решение об инсёрте принимаешь на основе stale данных, которые ты отдаешь на операции чтения. Офервлоу по заказам и кол-ву книжек разрешаешь в бекграунде. Те, кто оплатил или заказал, получат уведомление с тем, что извините, закончились на складе, можете подождать новой партии, либо вернуть деньги. И да, для такого подхода надо менять бизнес процесс
Наоборот, вместо апдейта использовать инсерты. Но вот только в pgsql апдейтов под капотом не существует, для базы все изменения это инсерты :) Поэтому реально можно просто нормально настроить базу (блокировки и прочее) и получить тот же результат.
В pgsql апдейты существуют, они блокируются, и это совсем другое поведение в отличии от инсёртов. То, о чем ты говоришь это MVCC, и да, с этой стороны update похож на delete + insert. Но это не значит что апдейтов не существкет и проблемы блокировок нет. Она есть, еще и какая. При этом очередь еще может распадаться, что будет приводить к ресурсному голоданию
Они существуют, но реально реализованы внутри как ты сказал. По поводу второй части твоего комментария, я же написал, что можно настроить базу, а не что она будет также работать по умолчанию.
Обсуждают сегодня