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

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

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

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

4.08.2008 14:31:11
14 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

200
31.07.2013 17:55:32
Что делать, если размер базы данных превышает 7 ГБ. В том, что срок не действует?
Hacker 8.08.2017 07:12:54

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

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

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

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

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

87
12.05.2017 04:23:30

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

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

10
4.08.2008 19:01:23

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

9
6.08.2008 04:27:52
Хотя это правда, что вопрос масштабирования лучше всего рассматривать в целом, но это совершенно не связано с тем, как масштабируется сам MySQL.
Lie Ryan 9.04.2011 20:15:11

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

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

20
6.08.2008 19:53:54

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

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

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

23
15.02.2017 14:34:05

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

21
5.08.2010 09:03:48

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

44
25.11.2013 13:55:43

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

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

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

9
6.12.2012 05:13:30

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

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

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

5
19.09.2013 11:26:31

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

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

3
3.12.2016 11:55:19

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

1
5.06.2017 10:27:47

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

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

10
30.06.2017 16:32:58

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

0
25.05.2019 09:18:46
у вас есть источник по этому поводу?
Shobi 11.02.2020 16:39:11