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

mysql database database-performance

170725 просмотра

14 ответа

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

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

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

Автор: Grant Источник Размещён: 22.10.2019 02:12

Ответы (14)


197 плюса

Решение

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

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

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

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

Автор: Nick Berardi Размещён: 04.08.2008 03:26

81 плюса

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

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

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

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

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

Автор: dlinsin Размещён: 04.08.2008 06:44

41 плюса

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

Автор: 0x4a6f4672 Размещён: 26.01.2012 10:33

23 плюса

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

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

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

Автор: BlaM Размещён: 11.08.2008 07:19

21 плюса

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

Автор: ian Размещён: 05.08.2010 09:03

18 плюса

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

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

Автор: deadprogrammer Размещён: 06.08.2008 07:53

9 плюса

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

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

Автор: saint_groceon Размещён: 04.08.2008 07:01

9 плюса

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

Автор: jj33 Размещён: 06.08.2008 04:27

9 плюса

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

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

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

Автор: alditis Размещён: 06.12.2012 05:13

8 плюса

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

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

Автор: Rich Remer Размещён: 30.06.2017 04:25

5 плюса

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

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

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

Автор: Abhijit Buchake Размещён: 19.09.2013 11:26

3 плюса

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

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

Автор: Anands23 Размещён: 29.11.2016 12:05

2 плюса

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

Автор: Viktor Joras Размещён: 05.06.2017 10:27

0 плюса

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

Автор: getNordic Размещён: 25.05.2019 09:18
32x32