В какой момент база данных MySQL начинает терять производительность?
У меня есть то, что я считаю крупной базой данных, с примерно 15-мегапиксельными записями, которые занимают почти 2 ГБ. Основываясь на этих цифрах, есть ли у меня стимул для очистки данных, или я уверен, что он сможет продолжать масштабирование еще на несколько лет?
Физический размер базы данных не имеет значения. Количество записей не имеет значения.
По моему опыту, самая большая проблема, с которой вы собираетесь работать, - это не размер, а количество запросов, которые вы можете обрабатывать одновременно. Скорее всего, вам придется перейти к конфигурации ведущего/ведомого, чтобы запросы на чтение могли выполняться против подчиненных устройств и запросы на запись выполнялись против ведущего устройства. Однако, если вы еще не готовы к этому, вы всегда можете настроить свои индексы для запросов, которые вы используете, чтобы ускорить время ответа. Также есть много настроек, которые вы можете сделать для сетевого стека и ядра в Linux, которые помогут.
У меня было до 10 ГБ, с небольшим количеством соединений, и он отлично обрабатывал запросы.
Сначала я бы сосредоточил внимание на ваших индексах, а затем администратор сервера посмотрел на вашу ОС, и если все это не поможет, возможно, пришло время реализовать конфигурацию ведущего/ведомого.
В общем, это очень тонкий вопрос, и он не является тривиальным. Я рекомендую вам прочитать mysqlperformanceblog.com и High Performance MySQL. Я действительно думаю, что нет общего ответа на это.
Я работаю над проектом, который имеет базу данных MySQL с почти 1 ТБ данных. Наиболее важным фактором масштабируемости является ОЗУ. Если индексы ваших таблиц помещаются в память и ваши запросы высоко оптимизированы, вы можете обслуживать разумное количество запросов на среднем компьютере.
Количество записей имеет значение, в зависимости от того, как выглядят ваши таблицы. Разница в том, чтобы иметь много полей varchar или только пару целых или длинных целых.
Физический размер базы данных также имеет значение: например, подумайте о резервных копиях. В зависимости от вашего движка ваши физические файлы БД растут, но не сжимаются, например, с помощью innodb. Таким образом, удаление большого количества строк не поможет уменьшить ваши физические файлы.
Здесь много вопросов, и, как и во многих случаях, дьявол кроется в деталях.
Размер базы данных имеет значение. Если у вас более одной таблицы с более чем миллионом записей, производительность начинает деградировать. Конечно, количество записей влияет на производительность: MySQL может быть медленным с большими таблицами. Если вы нажмете миллион записей, вы получите проблемы с производительностью, если индексы не будут установлены правильно (например, индексы для полей в "операторах WHERE" или "ON условиях" в объединениях). Если вы нажмете 10 миллионов записей, вы начнете получать проблемы с производительностью, даже если у вас есть все ваши индексы. Обновление оборудования - добавление большего объема памяти и большей мощности процессора, особенно памяти, часто помогает уменьшить самые серьезные проблемы, увеличивая производительность снова, по крайней мере, в определенной степени. Например, 37 сигналов передавались от 32 ГБ оперативной памяти до 128 ГБ ОЗУ для сервера базы данных Basecamp.
Сначала я бы сосредоточил внимание на ваших индексах, чем администратор сервера посмотрел на вашу ОС, и если все, что не помогает, может быть временем для конфигурации ведущего/ведомого.
Это правда. Другое дело, что обычно работает, - просто уменьшить количество данных, с которыми вы неоднократно работали. Если у вас есть "старые данные" и "новые данные", и 99% ваших запросов работают с новыми данными, просто переместите все старые данные в другую таблицу и не смотрите на нее;)
- > Посмотрите partitioning.
2GB и около 15M записей - очень маленькая база данных - я запускал намного больше на pentium III (!), и все еще работает довольно быстро. Если вы медленны, это проблема с дизайном базы данных/приложения, а не mysql.
Бесполезно говорить о "производительности базы данных", "производительность запросов" - лучший термин здесь. И ответ: это зависит от запроса, данных, на которых он работает, индексов, аппаратного обеспечения и т.д. Вы можете получить представление о том, сколько строк будет проверяться и какие индексы будут использоваться с синтаксисом EXPLAIN.
2GB на самом деле не считается "большой" базой данных - это больше среднего размера.
Также следите за сложными объединениями. Сложность транзакций может быть большим фактором в дополнение к объему транзакции.
Рефакторинг тяжелых запросов иногда дает большой прирост производительности.
Мне когда-то было предложено посмотреть на mysql, который "перестал работать". Я обнаружил, что файлы DB были размещены на сетевом устройстве, установленном с NFS2, и с максимальным размером файла 2 ГБ. И, конечно же, таблица, которая перестала принимать транзакции, была ровно 2 ГБ на диске. Но что касается кривой производительности, мне говорят, что она работает как чемпион, пока она не работает вообще! Этот опыт всегда служит мне как приятному напоминанию о том, что всегда есть размеры выше и ниже того, что вы, естественно, подозреваете.
Рассматриваемая точка зрения также является целью системы и данных в повседневной жизни.
Например, для системы с GPS-мониторингом автомобилей не актуальны данные запроса с позиций автомобиля в предыдущие месяцы.
Поэтому данные могут быть переданы в другие исторические таблицы для возможной консультации и сокращения времени выполнения ежедневных запросов.
В настоящее время я управляю базой данных MySQL в облачной инфраструктуре Amazon, которая выросла до 160 ГБ. Производительность запроса прекрасна. То, что стало кошмаром, - это резервное копирование, восстановление, добавление подчиненных или что-либо еще, что касается всего набора данных, или даже DDL на больших таблицах. Получение чистого импорта файла дампа стало проблематичным. Чтобы сделать процесс достаточно стабильным для автоматизации, необходимо сделать выбор, чтобы определить приоритетность стабильности по производительности. Если нам когда-либо приходилось восстанавливаться после стихийного бедствия, используя резервную копию SQL, мы не будем работать в течение нескольких дней.
Горизонтальное масштабирование SQL также довольно болезненно и в большинстве случаев приводит к его использованию таким образом, что вы, вероятно, не планировали, когда вы решили разместить ваши данные в SQL в первую очередь. Осколки, чтение рабы, мультимастер и т.д., Они все очень дерьмовые решения, которые добавляют сложность всему, что вы когда-либо делали с БД, и ни одна из них не решает проблему; только смягчает его в некотором роде. Я бы настоятельно предложил рассмотреть некоторые из ваших данных из MySQL (или действительно любого SQL), когда вы начинаете приближаться к набору данных размера, где эти типы вещей становятся проблемой.
Производительность может ухудшиться в несколько тысяч строк, если база данных не разработана должным образом.
Если у вас есть правильные индексы, используйте надлежащие механизмы (не используйте MyISAM, где ожидаются несколько DML), используйте разделение, выделяйте правильную память в зависимости от использования и, конечно, имеете хорошую конфигурацию сервера, MySQL может обрабатывать данные даже в терабайтах
Всегда есть способы улучшить производительность базы данных.
Это зависит от вашего запроса и проверки.
Например, я работал с таблицей из 100 000 лекарств, у которой есть общее имя столбца, где у нее более 15 символов для каждого препарата в этой таблице. Я поставил запрос сравнить общее название лекарств между двумя таблицами. Для выполнения запроса требуется больше минут. То же самое, если вы сравниваете наркотики с использованием индекса наркотиков, используя столбец идентификатора (как сказано выше), это занимает всего несколько секунд.
Размер базы данных имеет значение с точки зрения количества байтов и рядов строк. Вы заметите огромную разницу в производительности между световой базой данных и заполненной блобом. Как только мое приложение застряло, потому что я помещал двоичные изображения внутри полей, вместо того, чтобы хранить изображения в файлах на диске и помещать только имена файлов в базу данных. Итерация большого количества строк, с другой стороны, не является бесплатной.
Нет, это не имеет значения. Скорость MySQL составляет около 7 миллионов строк в секунду. Таким образом, вы можете масштабировать его немного