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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

В целом это очень тонкий вопрос, а не тривиальный. Я рекомендую вам прочитать mysqlperformanceblog.com и High Performance MySQL. Я действительно думаю, что для этого нет общего ответа.

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

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

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

Существует много вопросов, и, как во многих случаях, дьявол находится в деталях.

Answer 3

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

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

Answer 4

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

Answer 5

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

2GB на самом деле не считается «большой» базой данных - это больше среднего размера.

Answer 6

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

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

-> У вас есть посмотрите на partitioning.

Answer 7

2GB и около 15M записей - очень маленькая база данных - я запускал намного больше на pentium III (!), И все по-прежнему работает довольно быстро. Если вы медленны, это проблема с базой данных/дизайном приложения , а не mysql.

Answer 8

База данных размер действительно имеет значение. Если у вас более одной таблицы с более чем миллионом записей, производительность начинает деградировать. Конечно, количество записей влияет на производительность: MySQL can be slow with large tables. Если вы нажмете миллион записей, вы получите проблемы с производительностью, если индексы не будут установлены правильно (например, индексы для полей в «операторах WHERE» или «ON условиях» в объединениях). Если вы нажмете 10 миллионов записей, вы начнете получать проблемы с производительностью, даже если у вас есть все ваши индексы. Обновление оборудования - добавление большего объема памяти и большей мощности процессора, особенно памяти, часто помогает уменьшить самые серьезные проблемы, увеличивая производительность снова, по крайней мере, в определенной степени. Например, 37 signals went from 32 GB RAM to 128GB of RAM для сервера базы данных Basecamp.

Answer 9

Точка зрения также является целью системы и данных в повседневной жизни.

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

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

Answer 10

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

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

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

Answer 11

Это зависит от вашего запроса и подтверждения.

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

Answer 12

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

Answer 13

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

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