другую таблицу для вставки и выбора - PullRequest
1 голос
/ 25 июня 2011

Чтобы улучшить производительность вставки и нагрузку на сервер, я решил разделить большую таблицу на 2. Большую таблицу, которая будет использоваться только для «выбора», и таблицу меньшего размера, которая будет использоваться в основном для «вставки»"а иногда и" выберите ".Каждый период времени (я думал о дне) я буду объединять меньшую таблицу в большую.

Пересмотр большой таблицы: есть ли способ повысить производительность, сообщив серверу mysql, что он доступен только для чтения?Учитывая, что это только для выбора, могу ли я предположить, что он будет обрабатывать SELECT менее чем за 1 сек.когда он станет ~ 1e9 строк?

Что касается небольшой таблицы: какую настройку я должен сделать здесь?Каков наилучший способ разработки автоматизированного процесса слияния от маленькой к большой таблице (в php)?

Ответы [ 4 ]

4 голосов
/ 25 июня 2011

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

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

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

Предложение Konerak относительно упакованных таблиц ISAM является хорошим дополнением к этой точке зрения.Одним из эффектов является то, что он дает вам таблицу (и индексы) без отверстий.

3 голосов
/ 25 июня 2011

Упакованные таблицы ISAM идеально подходят для таблиц MySQL только для чтения, но вам все равно понадобятся правильные индексы для тяжелых запросов.

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

3 голосов
/ 25 июня 2011

Полагаю, вам это не нужно ..

Если ваша цель - дать больший приоритет запросу SELECT, вы можете просто вставить с помощью INSERT DELAYED.

1 голос
/ 25 июня 2011

Я не думаю, что вам нужно поддерживать разные таблицы для SELECT и INSERT, в основном так, если количество INSERT не очень большое или частое.Если таблица имеет правильные индексы, SELECT будет эффективным.Однако, обратите внимание, что слишком много индексов могут убить INSERT.

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

Вы также можете посмотреть INSERT DELAYED, если считаете, что SELECT имеют более высокий приоритет, но я бы посоветовал вам прочитать их достаточно, прежде чем их использовать.

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

Вы также можете попробовать разбиение;Я думаю, что в вашем случае это может быть горизонтальное разбиение.Хотя я признаю, что у меня самого нет опыта его использования.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...