Какую гранулярность выбрать для разбиения таблицы базы данных? - PullRequest
1 голос
/ 06 сентября 2010

У меня есть 20-миллионная таблица записей в базе данных MySQL.SELECT работает очень быстро, потому что я настроил хорошие индексы, но операции INSERT и UPDATE становятся очень медленными.База данных является серверной частью веб-приложения под большой нагрузкой.INSERT и UPDATE очень медленные, потому что в этой таблице около 5 индексов, а размер индекса сейчас составляет около 1 ГБ - я думаю, что для вычисления потребуется много времени.

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

Набор данных состоит из примерно 18000 различных логических срезов, которые можно запрашивать совершенно отдельно.Поэтому я мог бы создать 18000 именованных таблиц (maindata1, maindata2 и т. Д.).Тем не менее, я не уверен, что это оптимальный способ сделать это?Помимо очевидного факта, что мне придется просматривать 18000 элементов в инструменте администрирования всякий раз, когда я хочу что-то сделать вручную, я обеспокоен производительностью файловой системы.Файловая система - ext3.Я не уверен, насколько быстро он находит файлы в каталоге с 36000 файлами (есть файл данных и индексный файл).

Если это проблема, я могу объединить несколько кусков данных в одинТаблица.Например: maindata10, maindata20 и т. Д., Где maindata10 будет содержать фрагменты 1, 2, 3 ... 10.Если бы я пошел на «группы» из 10, у меня было бы только 1800 таблиц.Если бы я сгруппировал 20, я бы получил 900 столов.

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

Редактировать: Мне также интересно, будет ли этоХорошая идея использовать несколько отдельных баз данных для группировки файлов.Итак, даже если бы у меня было 18000 таблиц, я мог бы сгруппировать их, скажем, в 30 баз данных по 600 таблиц в каждой.Кажется, с этим было бы намного легче справиться.Я не знаю, увеличит ли несколько баз данных производительность или уменьшит производительность или объем памяти (это усложнит резервное копирование и восстановление)

Ответы [ 2 ]

1 голос
/ 27 июля 2011

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

1 голос
/ 06 сентября 2010

Есть несколько тактик, которые вы могли бы использовать для повышения производительности. Под «разделами» я предполагаю, что вы имеете в виду «версии таблиц с одинаковым расположением столбцов, но с разным содержанием данных».

Получите сервер, на котором будет работать MySQL 5, если вы можете. Это быстрее и лучше в этом, достаточно, чтобы у вас не было проблем после обновления.

Используете ли вы InnoDB? Если да, можете ли вы перейти на myISAM? (Если вам нужна жесткая целостность транзакций, вы не сможете переключиться).

Для разбиения вы можете попытаться выяснить, какая комбинация данных-срезов даст вам разделы примерно одинакового размера (по количеству строк). На вашем месте я бы выбрал не более 20 разделов, если вы не докажете себе, что вам это необходимо.

Если только некоторые из ваших срезов данных активно обновляются (например, если они являются «данными за этот месяц» и «данными за последний месяц), я мог бы рассмотреть возможность их разделения на более мелкие срезы. Например, вы могли бы иметь» данные этой недели "," данные прошлой недели "и" неделей ранее "в своих собственных разделах. Затем, когда ваши разделы остывают, скопируйте их данные и объедините их в большие группы, такие как" квартал до последнего ". Это имеет недостаток что для этого потребуются обычные задания по обслуживанию в стиле воскресного вечера, но преимущество в том, что большинство или все обновления происходят только в небольшой части таблицы.

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