Человек vs MySQL&HUGE-table

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

Как вы уже знаете, мускул на больших объёмах данных в таблице тормозит. Сильно. Как вариант, можно отключить ключ и добавить нужную строку. А что делать, если ключ всё-таки необходим? Или вообще при апдейте — без ключа он искать запись будет долго. А после добавления/изменения надо ведь будет ещё и вернуть ключ, а это тоже не быстрая операция.
Есть другой вариант — группировать инсерты в блоки по, скажем, 10-100 записей. Но тут есть проблема — одна из записей может не пройти по ключу, что не даст добавить остальные. Аналогично можно группировать и апдейты, только там хитрее действовать придётся. 🙂

В итоге оба варианта слишком далеки от желаемого. Но есть и другие способы ускорить изменение данных в таблице. Вот какой вариант реализовал я:

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

Я сделал очень просто. При апдейте HUGE я беру из второй таблицы данные, которые ждали апдейта более 5 минут. После апдейта удаляю данные, которые лежат в таблице более 20 минут. Учитывая частые запуски этих апдейт+делет, данные не успевают залёживаться так, чтобы апдейт занял более 15 минут. Ну и, соответственно, из-за постоянно низкого количества строк во второй таблице (у меня порядка 2-20 тысяч, в среднем — 5-7 тысяч), инсерт в неё производится очень быстро.

One comment

  1. У меня вероятно тоже скоро появиться таблица-миллионник, пока обхожусь прямым инсертом. Мне в нее вообще только вставка и нужна, даже обновлений не нужно. Только нужно точно знать что вставилось а что нет, по этому вставляю по одной записи, и пока 25-ть записей сохранятся за 200-250 мс, что пока не очень много.
    Если запись в базу станет узким местом, буду оптимизировать.

Leave a Reply

Ваш e-mail не будет опубликован. Обязательные поля помечены *