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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

-> Взгляните на разбиение .

Answer 5

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

Answer 6

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

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

Answer 7

Обсуждаемым моментом является также назначение системы и данные на каждый день.

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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