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

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

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

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

Ответов (15)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновление: несколько лет спустя наш набор данных вырос примерно до 800 ГиБ. Кроме того, у нас есть одна таблица размером 200+ ГиБ и несколько других размером от 50 до 100 ГиБ. Все, что я сказал раньше, остается в силе. Он по-прежнему работает нормально, но проблемы с выполнением операций с полным набором данных стали еще хуже.

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

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

Запросы с проиндексированными полевыми условиями вместе с полным значением обычно будут возвращаться за 1 мс, но start_with, IN, Between, очевидно, содержит условия, может занять больше времени с большим количеством записей для сканирования.

Также вы столкнетесь с множеством проблем обслуживания с DDL, например, ALTER, DROP будет медленным и трудным с большим живым трафиком даже для добавления индекса или новых столбцов.

Как правило, рекомендуется кластеризовать базу данных в столько кластеров, сколько требуется (500 ГБ будет общим эталоном, как говорят другие, он зависит от многих факторов и может варьироваться в зависимости от вариантов использования), таким образом это обеспечивает лучшую изоляцию и дает независимость для конкретного масштабирования кластеры (больше подходят для B2B)

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

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

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

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

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

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

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

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

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

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

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

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