Я правильно понимаю суть идеи — мы создаем вторую точку встречи на промежуточной таблице main_table и размазываем «нагрузку встречи» между двумя точками?
Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.
Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
просто bunch?
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
Кому нужен журнал, по которому не делается селект?
Ваше предложение пока что конкуриет по своей непродуманности с развязкой через кластер: UPDATE на мастере, SELECT со слейва. Надеюсь, не надо рассказывать почему такая развязка не развязка?
вам, простите, приходилось поддерживать что-то со сходным с mysql-query-plan-builder legacy? Или с его же переменчивым набором требований? Как вы думаете, много там багов?
хотите влет пример JOIN, который я руками гарантированно сделаю быстрее, чем используемая на проде версия MySQL сервера?
Площадка-интернет-магазин с редактированием товаров продавцами онлайн. Как архитектурно верно избежать встречного потока SELECT — UPDATE и связанного с встречей замедления обоих потоков?
это моя статья и там в названии сказано что она про сайт))))
система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.
Абсолютно правильно понимаете. Более того — я уже наблюдал результат такой оптимизации. Дважды. Про постгрес верю, но хочу спросить — на каких объемах данных и нагрузках?
Вы уверены что это именно ошибка? Есть конкретные примеры решения такой архитектурной ошибки? Ну кроме уже предложенного выше способа «пишем в мастер, читаем со слейва».
что делать неспециалисту? учиться задавать вопросы на английском языке.
в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.
ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.
такая бд нужна для хранения данных привычным команде разработчиков способом. для получения из нее данных. для записи.
А насчет дешевизны INSERT в контексте пересчета индексов уже отписывался
Суммарный оверхед от этого должен вырасти, но мы получаем механизм контроля над потоком UPDATE для изначальной точки — и даже можем попытаться коррелировать его с интенсивностью SELECT для той же таблицы.
Мне не очень нравится как скейлится такой подход — три точки встречи, четыре? — и поэтому как архитектурное решение он мне не нравится. Но вот в качестве экстренной аварийной меры может быть очень даже эффективным
теперь UPDATE-запросы идут не поодиночке, а предварительно группируются в «журнальной» main_table? и можно ли считать INSERT… ON DUPLICATE KEY UPDATE одним большим запросом?
Ваше предложение пока что конкуриет по своей непродуманности с развязкой через кластер: UPDATE на мастере, SELECT со слейва. Надеюсь, не надо рассказывать почему такая развязка не развязка?
Стоимость развязки SELECT — INSERT чуть выше, чем SELECT — UPDATE, не согласны?
вам, простите, приходилось поддерживать что-то со сходным с mysql-query-plan-builder legacy? Или с его же переменчивым набором требований? Как вы думаете, много там багов?
хотите влет пример JOIN, который я руками гарантированно сделаю быстрее, чем используемая на проде версия MySQL сервера?
система медицинских заказов на целый край хранит данные, наверное, в чем-нибудь максимально энтерпрайзном? я, к сожалению, не умею проводить «агрерацию в pipeline mode по покрывающим индексам» привычными для веба инструментами.
и какая, если не секрет, нагрузка на систему?
Не сразу понял про соединение.
в 99% случаев правильно поставленный вопрос получает ответ на гугле. Это называется StackOverflow driven development. Оставшийся один процент придется задать.
ну и правило «зачем?»: если ты не понимаешь зачем это — оно тебе не нужно.