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