Насколько большой может стать база данных MySQL, прежде чем производительность начнет снижаться

Question

В какой момент база данных MySQL начинает терять производительность?

• Имеет ли значение физический размер базы данных?
• Имеет ли значение количество записей?
• Является ли какое-либо снижение производительности линейным или экспоненциальным?

У меня есть, как мне кажется, большая база данных, содержащая примерно 15 миллионов записей, которые занимают почти 2 ГБ.Основываясь на этих цифрах, есть ли у меня какой-либо стимул очищать данные, или я могу с уверенностью позволить им продолжать масштабироваться еще несколько лет?

Answer 1

Физический размер базы данных не имеет значения.Количество записей не имеет значения.

По моему опыту, самая большая проблема, с которой вы столкнетесь, — это не размер, а количество запросов, которые вы можете обрабатывать одновременно.Скорее всего, вам придется перейти на конфигурацию «главный/подчиненный», чтобы запросы на чтение могли выполняться на ведомых устройствах, а запросы на запись — на ведущем.Однако, если вы еще не готовы к этому, вы всегда можете настроить индексы для выполняемых вами запросов, чтобы ускорить время ответа.Также вы можете внести множество изменений в сетевой стек и ядро ​​Linux, которые помогут.

У меня был объем до 10 ГБ, с умеренным количеством подключений, и он отлично справлялся с запросами.

Я бы сначала сосредоточился на ваших индексах, затем попросил администратора сервера просмотреть вашу ОС, и если все это не поможет, возможно, пришло время реализовать конфигурацию «главный/подчиненный».

Answer 2

В общем, это очень тонкий вопрос и совсем не тривиальный.Я советую вам прочитать mysql Performanceblog.com и Высокопроизводительный MySQL.Я действительно думаю, что на этот вопрос нет общего ответа.

Я работаю над проектом, в котором есть база данных MySQL с объемом данных почти 1 ТБ.Наиболее важным фактором масштабируемости является оперативная память.Если индексы ваших таблиц помещаются в память и ваши запросы хорошо оптимизированы, вы можете обслуживать разумное количество запросов на средней машине.

Количество записей имеет значение в зависимости от того, как выглядят ваши таблицы.Разница заключается в том, что у вас много полей varchar или всего пара целых или длинных полей.

Физический размер базы данных также имеет значение:подумайте, например, о резервных копиях.В зависимости от вашего движка ваши физические файлы базы данных растут, но не сжимаются, например, с помощью innodb.Таким образом, удаление большого количества строк не поможет уменьшить ваши физические файлы.

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

Answer 3

Размер базы данных имеет значение.Если у вас более одной таблицы с более чем миллионом записей, производительность действительно начинает снижаться.Количество записей, конечно, влияет на производительность: MySQL может работать медленно с большими таблицами.Если вы наберете один миллион записей, у вас возникнут проблемы с производительностью, если индексы установлены неправильно (например, нет индексов для полей в «операторах WHERE» или «условиях включения» в соединениях).Если вы достигнете 10 миллионов записей, у вас начнутся проблемы с производительностью, даже если у вас все индексы в порядке.Модернизация оборудования — добавление большего количества памяти и большей мощности процессора, особенно памяти, — часто помогает уменьшить наиболее серьезные проблемы за счет повторного повышения производительности, по крайней мере, в определенной степени.Например 37 сигналов перешли с 32 ГБ ОЗУ на 128 ГБ ОЗУ для сервера базы данных Basecamp.

Answer 4

Я бы сначала сосредоточился на ваших индексах, а затем попросил администратора сервера просмотреть вашу ОС, и если все это не поможет, возможно, пришло время для конфигурации «главный/подчиненный».

Это правда.Еще одна вещь, которая обычно работает, — это просто уменьшить количество данных, с которыми неоднократно приходится работать.Если у вас есть «старые данные» и «новые данные» и 99% ваших запросов работают с новыми данными, просто переместите все старые данные в другую таблицу — и не смотрите на нее ;)

-> Посмотрите разделение.

Answer 5

2 ГБ и около 15 миллионов записей — это очень маленькая база данных. Я запускал гораздо большие базы данных на Pentium III (!), и все по-прежнему работало довольно быстро.Если у вас медленный, это проблема проектирования базы данных/приложения, а не MySQL.

Answer 6

Говорить о «производительности базы данных» бессмысленно, здесь лучше использовать термин «производительность запросов».И ответ:это зависит от запроса, данных, с которыми он работает, индексов, оборудования и т. д.Вы можете получить представление о том, сколько строк будет сканироваться и какие индексы будут использоваться, с помощью синтаксиса EXPLAIN.

2 ГБ на самом деле не считаются «большой» базой данных — это скорее средний размер.

Answer 7

Также следите за сложными соединениями.Сложность транзакции может быть важным фактором в дополнение к объему транзакции.

Рефакторинг тяжелых запросов иногда дает значительный прирост производительности.

Answer 8

Однажды меня попросили посмотреть MySQL, который «перестал работать».Я обнаружил, что файлы БД находились в файлере Network Appliance, смонтированном с помощью NFS2, и максимальный размер файла составлял 2 ГБ.И действительно, таблица, которая перестала принимать транзакции, занимала на диске ровно 2 ГБ.Но что касается кривой производительности, мне сказали, что она работала как чемпион, пока не перестала работать вообще!Этот опыт всегда служит для меня хорошим напоминанием о том, что всегда существуют измерения выше и ниже того, о котором вы, естественно, подозреваете.

Answer 9

Следует также учитывать назначение системы и повседневные данные.

Например, для системы с GPS-мониторингом автомобилей не актуален запрос данных о местонахождении автомобиля за предыдущие месяцы.

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

Answer 10

В настоящее время я управляю базой данных MySQL в облачной инфраструктуре Amazon, объем которой вырос до 160 ГБ.Производительность запросов в порядке.Кошмаром стало резервное копирование, восстановление, добавление подчиненных устройств или что-либо еще, что касается всего набора данных или даже DDL для больших таблиц.Получить чистый импорт файла дампа стало проблематично.Чтобы сделать процесс достаточно стабильным для автоматизации, необходимо было сделать различные варианты, отдавая приоритет стабильности над производительностью.Если бы нам когда-нибудь пришлось восстанавливаться после аварии с помощью резервной копии SQL, мы бы простояли несколько дней.

Горизонтальное масштабирование SQL также довольно болезненно и в большинстве случаев приводит к его использованию способами, которые вы, вероятно, не планировали, когда изначально решили поместить свои данные в SQL.Шарды, подчиненные устройства чтения, мультимастеры и т. д. — все это действительно дерьмовые решения, которые усложняют все, что вы когда-либо делаете с БД, и ни одно из них не решает проблему;лишь в некоторой степени смягчает его.Я настоятельно рекомендую рассмотреть возможность перемещения некоторых ваших данных из MySQL (или любого SQL), когда вы начинаете приближаться к набору данных такого размера, когда подобные вещи становятся проблемой.

Answer 11

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

Если у вас есть правильные индексы, используйте правильные механизмы (не используйте MyISAM там, где ожидается несколько DML), используйте секционирование, выделяйте правильную память в зависимости от использования и, конечно же, имеете хорошую конфигурацию сервера, MySQL может обрабатывать данные даже в терабайтах!

Всегда есть способы улучшить производительность базы данных.

Answer 12

Это зависит от вашего запроса и проверки.

Например, я работал с таблицей из 100 000 лекарств, в которой есть общее название столбца, в котором для каждого препарата в этой таблице содержится более 15 символов. Я разместил запрос для сравнения родового названия лекарств в двух таблицах. Запрос принимает больше минут для запуска. То же самое, если вы сравните лекарства, используя индекс лекарств, используя столбец идентификаторов (как сказано выше), это займет всего несколько секунд.

Answer 13

Размер базы данных ДЕЙСТВИТЕЛЬНО имеет значение с точки зрения количества байтов и количества строк таблицы.Вы заметите огромную разницу в производительности между легкой базой данных и базой данных, заполненной большими двоичными объектами.Однажды мое приложение зависло из-за того, что я поместил двоичные изображения в поля вместо того, чтобы хранить изображения в файлах на диске и помещать в базу данных только имена файлов.С другой стороны, повторение большого количества строк не является бесплатным.

Answer 14

Нет, это не имеет особого значения.Скорость MySQL составляет около 7 миллионов строк в секунду.Таким образом, вы можете масштабировать его совсем немного