Question

У меня есть таблица, которая достигла почти 3 миллионов записей.Хотя я понимаю, что эта сумма не может считаться большой по сравнению с СУБД, я заметил замедление операций, связанных с этой таблицей.Я чувствую, что могу оптимизировать или перестроить его.

Это часть базы данных для PocketBracket March Madness App .По сути, в таблице хранятся метаданные для отношения один ко многим (в скобках много скобок).Твист спрос на столе отличается в разы.Например, существует короткий период (две недели), когда таблица выполняет в основном запись.Но для остальной части года это в основном читает.Кроме того, подавляющее большинство записей не доступны.

Вот скриншот текущей структуры:

enter image description here

С этим, вот некоторые мысли, которые яиметь:

Поместить старые записи в отдельную таблицу.Уменьшает количество записей, но потребует модификаций кода.
Денормализуйте таблицу, чтобы модели были 1-1 (т. Е. Соберите все скобки в один сериализованный столбец).Уменьшает количество записей, но потребует изменения кода.
Поменяйте местами механизм таблицы или индексы в течение запросов периодов (т. Е. InnoDB / MyISAM).
Что-то, что у меня естьне думал о ...

Буду признателен за ваше руководство.В конце концов, я в порядке с изменениями кода, я просто хочу убедиться, что я ре-архитектор в правильном направлении.

Silenteh · Answer 1 · 14 февраля 2012

Прежде чем сходить с ума от "оптимизаций", таких как разбиение на разделы, разбиение, денормализация и т. Д., Которые приведут к множеству дополнительных проблем, я сначала попытался бы определить причину замедления.

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

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

Поэтому, прежде всего, важно иметь больше информации

Количество оперативной памяти сервера
Тип диска сервера / с
Есть ли RAID? если да, то какой?
Это виртуальный сервер
Сколько запросов в секунду обрабатывает mysql?

Возможно, таблица просто фрагментирована, а конфигурация mysql нуждается в дополнительной настройке. Прежде всего вы должны переключиться на innodb, как предложил Vyktor, а затем вы также должны настроить буфер innod db на более высокое значение. Значение по умолчанию слишком низкое. Вот пример моего конфигурационного файла. Имейте в виду, что параметры настроены для моего типа данных, запросов и спецификаций сервера. Кроме того, я использую вариант MySQL под названием percona , который также может вам помочь, потому что он оказался быстрее. На сайте вы можете найти несколько ориентиров.

innodb_file_per_table  
innodb_file_format=barracuda

innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_size = 3GB
query_cache_size = 98304
innodb_log_file_size = 10485760
innodb_log_buffer_size = 3145728

Я бы также попытался запустить mysqlcheck . ВНИМАНИЕ !!! блокирует стол!

Если вам нужна дополнительная информация о настройке MySQL, это отличный блог

Vyktor · Answer 2 · 10 февраля 2012

Основываясь на этой статье в блоге оракула (и приложенном техническом документе), я предполагаю, что переход с MyISAM на InnoDB может решить ваши проблемы.Просто любопытно, что их аппаратная конфигурация: 1003

1005 4 разъема, всего 48 ядер, 4 x 12-ядерных процессоров AMD Opteron 6172 «Magny-Cours» 2,1 ГГц.(Примечание: 36 ядер были выделены для MySQL, а остальные 12 процессов Sysbench.) 64 ГБ ОЗУ DDR3 2 x твердотельных накопителя Intel X25E

Но что более важно чтение-запись сравнение:

Как показано на графике ниже, InnoDB обеспечивает пропускную способность в 35 раз выше, чем MyISAM, при этом масштабируемость от 6 до 85% - 90%36-ядер.Выше 30 ядер кривая масштабируемости начинает сглаживаться по мере роста числа горячих мьютексов, но производительность все еще продолжает увеличиваться.

И только для чтения сравнение:

InnoDB обеспечивает в 4,6 раза более высокую пропускную способность, чем MyISAM, и обеспечивает масштабируемость от 90 до 95% от 6 до 36 ядер.Выше 30 ядер масштабируемость сглаживается, так как сервер снова насыщен множеством горячих мьютексов.

Единственными недостатками, которые они упоминают в InnoDB и MyISAM, являются:

Нет R-деревьев
Нет полнотекстовых индексов
Максимальный размер таблицы 64 ТБ (MyISAM 256 ТБ).

Вот статья о настройке InnoDB.

Вероятно, вам BENCHMARK ваши запросы как на движке MyISAM, так и на InnoDB (убедитесь, что вы правильно настроили FOREIGN KEY s).Вы можете использовать следующие тесты:

DO BENCHMARK( 100, (SELECT games.someField
    FROM brackets
    INNER JOIN relation_table ON relation_table.bracketID = brackets.id
    INNER JOIN games ON games.id = relation_table.gameID
    LIMIT 1  
));

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

_{В любом случае, пожалуйста, оставьте результаты в комментарии, мне интересно об этом}

Sergey Benner · Answer 3 · 14 февраля 2012

Хорошо, разбиение имеет следующие преимущества. Ниже приведены некоторые выдержки из документации mysql. В конце ответа я также приведу список ссылок на разбиение таблиц для разных баз данных. Некоторые из вас также могут захотеть прочитать о SHARDING http://en.wikipedia.org/wiki/Shard_(database_architecture)

Но поскольку с каждой технологией разбиения следует обращаться осторожно, а не просто следовать вслепую советует, что у него есть свои недостатки, и, вероятно, я обнаружил, что это требует много взаимодействия и его управляемость страдает, как сказал Том Кайт в своем блоге оракула:

are your tables getting larger then you feel comfortable managing?  eg: it might take longer to 
restore a 100gig tablespace than 1-10 gig tablespace (and the other 90gig of data is online whilst 
doing this)

Преимущества:

Секционирование позволяет хранить больше данных в одной таблице, чем может храниться на одном диске или в разделе файловой системы.
Данные, которые теряют свою полезность, часто можно легко удалить из многораздельной таблицы, удалив раздел (или разделы), содержащий только эти данные. И наоборот, процесс добавления новых данных в некоторых случаях может быть значительно облегчен путем добавления одного или нескольких новых разделов для хранения именно этих данных.
Некоторые запросы могут быть значительно оптимизированы в силу того факта, что данные, удовлетворяющие данному предложению WHERE, могут храниться только в одном или нескольких разделах, что автоматически исключает любые оставшиеся разделы из поиска. Поскольку разделы могут быть изменены после создания многораздельной таблицы, вы можете реорганизовать свои данные, чтобы улучшить частые запросы, которые не часто использовались при первоначальной настройке схемы разделения. Эта возможность исключать несоответствующие разделы (и, следовательно, любые строки, которые они содержат) часто упоминается как сокращение разделов и была реализована в MySQL 5

Другие преимущества, обычно связанные с разделением, перечислены в следующем списке. Эти функции в настоящее время не реализованы в MySQL Partitioning, но занимают важное место в нашем списке приоритетов.

Запросы с участием агрегатных функций, таких как SUM () и COUNT (), можно легко распараллелить. Простым примером такого запроса может быть SELECT salesperson_id, COUNT (orders) as order_total FROM sales GROUP BY salesperson_id ;. Под «распараллеливанием» мы подразумеваем, что запрос может быть запущен одновременно для каждого раздела, а окончательный результат получен путем суммирования результатов, полученных для всех разделов.
Достижение большей пропускной способности запросов за счет распространения поиска данных по нескольким дискам.

ссылки