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

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

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

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

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

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

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

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

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

- > Посмотрите partitioning.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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