kzen.dev
  • Вопросы
  • Метки
  • Пользователи
Оповещения
Вознаграждения
Регистрация
После регистрации, сможете получать уведомления об ответах и комментариях на Ваши вопросы.
Вход
Если у Вас уже есть аккаунт, войдите чтобы проверить новые уведомления.
Тут будут вознаграждения за добавленные вопросы, ответы и комментарий.
Дополнительно
Источник
Редактировать
 Grant
Grant
Вопрос

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

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

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

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

290 2008-08-04T14:31:11+00:00 14
 davejal
davejal
Редактировал вопрос 27-го января 2016 в 11:40
Программирование
database
mysql
database-performance
Решение / Ответ
Nick Berardi
Nick Berardi
4-го августа 2008 в 3:26
2008-08-04T15:26:55+00:00
Дополнительно
Источник
Редактировать
#8407400

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

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

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

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

 NTDLS
NTDLS
Редактировал ответ 31-го июля 2013 в 5:55
197
0
 dlinsin
dlinsin
4-го августа 2008 в 6:44
2008-08-04T18:44:15+00:00
Дополнительно
Источник
Редактировать
#8407402

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

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

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

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

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

Elnur Abdurrakhimov
Elnur Abdurrakhimov
Редактировал ответ 12-го мая 2017 в 4:23
82
0
 0x4a6f4672
0x4a6f4672
26-го января 2012 в 10:33
2012-01-26T10:33:01+00:00
Дополнительно
Источник
Редактировать
#8407408

Размер базы данных действительно имеет значение . Если у Вас есть больше чем один стол больше чем с миллионом отчетов, то работа начинает действительно ухудшаться. Количество отчетов действительно, конечно, затрагивает работу: MySQL может быть медленным с большими столами. Если Вы поразите один миллион отчетов, то Вы получите исполнительные проблемы, если индексы не будут установлены право (например, никакие индексы для областей в " ГДЕ statements" или " НА conditions" в соединениях). Если Вы поразите 10 миллионов отчетов, Вы начнете получать исполнительные проблемы, даже если Вы будете иметь все свое право индексов. Модернизации аппаратных средств - добавляющий больше памяти и больше мощности процессора, особенно память - часто помогают уменьшить самые серьезные проблемы, увеличивая работу снова, по крайней мере, до известной степени. Например 37 сигналов пошли от RAM на 32 ГБ до 128 ГБ RAM для сервера базы данных Basecamp.

 0x4a6f4672
0x4a6f4672
Редактировал ответ 25-го ноября 2013 в 1:55
41
0
 BlaM
BlaM
11-го августа 2008 в 7:19
2008-08-11T19:19:05+00:00
Дополнительно
Источник
Редактировать
#8407406

я сосредоточился бы сначала на Ваших индексах, чем сделали, чтобы администратор сервера посмотрел на Ваш OS, и если все это doesn' t помогают, могло бы быть время для конфигурации владельца/раба.

That' s верный. Другая вещь, которая обычно работает, состоит в том, чтобы просто уменьшить количество данных that' s неоднократно работал с. Если у Вас есть " старый data" и " новый data" и 99% Вашей работы вопросов с новыми данными, просто переместите все старые данные в другой стол - и don' t смотрят на него;)

  • Взгляните на разделение.

 BlaM
BlaM
Редактировал ответ 15-го февраля 2017 в 2:34
23
0
 ian
ian
5-го августа 2010 в 9:03
2010-08-05T09:03:48+00:00
Дополнительно
Источник
Редактировать
#8407407

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

21
0
 deadprogrammer
deadprogrammer
6-го августа 2008 в 7:53
2008-08-06T19:53:54+00:00
Дополнительно
Источник
Редактировать
#8407405

It' s довольно бессмысленный, чтобы говорить о " база данных performance" " вопрос performance" лучший термин здесь. И ответ: это зависит от вопроса, данные, которыми это управляет на, индексы, аппаратные средства, и т.д. Вы можете понять то, сколько рядов будет просмотренными и с чем индексы будут используемыми, ОБЪЯСНЯЕТ синтаксис.

2 ГБ действительно не считаются " large" база данных - it' s больше среднего размера.

18
0
 jj33
jj33
6-го августа 2008 в 4:27
2008-08-06T04:27:52+00:00
Дополнительно
Источник
Редактировать
#8407404

Я однажды был призван, чтобы посмотреть на mysql, у которого был " остановленный working". я обнаружил, что файлы DB проживали на регистраторе Network Appliance, установленном с NFS2 и с максимальным размером файла 2 ГБ. И конечно же, стол, который прекратил принимать сделки, был точно 2 ГБ на диске. Но относительно кривой производительности I' m сказал, что работал как чемпион вплоть до него didn' t работают вообще! Этот опыт всегда служит для меня в качестве хорошего напоминания этому there' ре всегда проставляет размеры выше, и ниже того Вы естественно подозреваете.

9
0
 saint_groceon
saint_groceon
4-го августа 2008 в 7:01
2008-08-04T19:01:23+00:00
Дополнительно
Источник
Редактировать
#8407403

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

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

9
0
 alditis
alditis
6-го декабря 2012 в 5:13
2012-12-06T05:13:30+00:00
Дополнительно
Источник
Редактировать
#8407409

Вопрос для рассмотрения - также цель системы и данных в повседневном.

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

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

9
0
Rich Remer
Rich Remer
30-го июня 2017 в 4:25
2017-06-30T16:25:34+00:00
Дополнительно
Источник
Редактировать
#8407413

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

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

Rich Remer
Rich Remer
Редактировал ответ 30-го июня 2017 в 4:32
8
0
Abhijit Buchake
Abhijit Buchake
19-го сентября 2013 в 11:26
2013-09-19T11:26:31+00:00
Дополнительно
Источник
Редактировать
#8407410

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

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

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

5
0
 Anands23
Anands23
29-го ноября 2016 в 12:05
2016-11-29T12:05:24+00:00
Дополнительно
Источник
Редактировать
#8407411

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

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

James Z
James Z
Редактировал ответ 3-го декабря 2016 в 11:55
3
0
Viktor Joras
Viktor Joras
5-го июня 2017 в 10:27
2017-06-05T10:27:47+00:00
Дополнительно
Источник
Редактировать
#8407412

Размер базы данных ДЕЙСТВИТЕЛЬНО имеет значение с точки зрения байтов и table' s число рядов. Вы заметите, что огромная разница в результативности между легкой базой данных и каплей заполнила ту. Как только мое заявление застряло, потому что я поместил бинарные изображения в областях вместо того, чтобы держать изображения в файлах на диске и поместить только имена файлов в базу данных. Повторение большого количества рядов, с другой стороны, не бесплатно.

2
0
 getNordic
getNordic
25-го мая 2019 в 9:18
2019-05-25T09:18:46+00:00
Дополнительно
Источник
Редактировать
#8407414

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

0
0
Похожие сообщества 8
DBA - русскоговорящее сообщество
DBA - русскоговорящее сообщество
3 542 пользователей
Общаемся и обсуждаем темы, посвященные DBA, PostgreSQL, Redis, MongoDB, MySQL, neo4j, riak и т.д. См. также: @devops_ru, @kubernetes_ru, @docker_ru, @nodejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание здесь было полезным и комфортным.
Открыть telegram
MySQL
MySQL
2 849 пользователей
English group: @mysql_en Группа о СУБД MySQL. Правила: https://t.me/mysql_db/68226 Часто задаваемые вопросы: https://git.io/fjLbO Админы: @smlkw @MasterZiv @Gr3ga
Открыть telegram
SQL JOBS
SQL JOBS
2 144 пользователей
Обязательны: компания, город, позиция, вилка, наличие удалёнки, требования, контакты. Бан за рекламу, сексизм, расизм и неадекватный обсёр объявлений
Открыть telegram
ru_mysql
ru_mysql
1 274 пользователей
По-русски о MySQL/Percona/MariaDB. Новостной канал: https://t.me/ru_mysql_ch /report в ответ на спам сообщение Используйте https://0bin.net вместо простыней кода
Открыть telegram
dbGeeks
dbGeeks
768 пользователей
Чат про базы данных, их устройство и приемы работы с ними. Разрешаются любые адеватные дискуссии в рамках тематики чата.
Открыть telegram
Разработка СУБД
Разработка СУБД
209 пользователей
Это чат о разработке СУБД - реляционных, распределенных, и вообще каких угодно. Здесь обсуждаются пейперы, архитектура, доклады, и т.д. Если у вас вопросы по использованию какой-то СУБД, это не сюда.
Открыть telegram
Добавить вопрос
Категории
Все
Технологий
Культура / Отдых
Жизнь / Искусство
Наука
Профессии
Бизнес
Пользователи
Все
Новые
Популярные
1
Ilya Smirnov
Зарегистрирован 1 день назад
2
Денис Васьков
Зарегистрирован 2 дня назад
3
Dima Patrushev
Зарегистрирован 5 дней назад
4
sirojidddin otaboyev
Зарегистрирован 1 неделю назад
5
Елена Гайдамамакинат
Зарегистрирован 1 неделю назад
ES
ID
JA
KO
RO
RU
© kzen.dev 2023
Источник
stackoverflow.com
под лицензией cc by-sa 3.0 с атрибуцией