Многие говорят, что размер базы данных не должен сильно влиять на производительность. Пока индексы таблиц помещаются в памяти, база данных должна оставаться работоспособной.
Однако какова реальность? Если архитектура базы данных не самая лучшая, индексы не помещаются в памяти, и существует потенциально много избыточных данных, есть ли значительные выгоды, которые можно получить, просто удалив избыточные данные? По моим оценкам, 60-80% данных в моей базе данных могут быть удалены.
Я считаю, что уменьшение размера базы данных и увеличение объема оперативной памяти, чтобы индексы могли поместиться в памяти, дало бы значительное увеличение производительности, что дало бы некоторое передышку на несколько месяцев для перестройки системы.
Существуют ли другие факторы, такие как IO, фрагментация, рабочий набор данных и т. Д., Которые влияют на производительность в зависимости от размера базы данных?
источник
Ответы:
Это полностью зависит от того, что вы делаете с данными.
Для базовых транзакций вставки / обновления / удаления, которые затрагивают всего несколько строк, увеличение размера данных, вероятно, не является важным фактором. База данных будет использовать индексы в памяти для доступа к правильной странице. Вы получаете больше промахов кэша, когда таблицы больше не помещаются в память. Однако издержки могут быть незначительными - в зависимости от базы данных, конфигурации базы данных и конфигурации оборудования.
Если вы выполняете запросы, требующие полного сканирования таблицы, то ваша производительность будет расти линейно или хуже с размером данных. Индексы могут на самом деле усугубить ситуацию за счет рандомизации доступа к страницам, что в значительной степени гарантирует отсутствие кеша.
Альтернативой большему объему памяти является улучшенная скорость диска - твердотельный диск может обеспечить огромное улучшение.
Наличие большего количества данных вряд ли повлияет на производительность, если только таблицы не используются в запросах. Являются ли данные избыточными внутри таблицы или между таблицами? Наличие больших таблиц, которые никогда не используются, является грязным, но оказывает минимальное влияние на производительность. Можно предположить, что если у вас есть миллионы ненужных таблиц, то компиляция запросов может начать занимать больше времени.
источник
Правило номер один для настройки AMM («Добавить больше памяти») простое. Это также очень дорого и, в конце концов, неэффективно, когда есть проблемы с селективностью. Даже если база данных полностью помещается в памяти, производительность приложения может быть плохой. В худшем случае из-за блокировок и блокировок при очень избирательном выполнении SQL. Это должно быть исправлено в первую очередь. Одной из причин является параллелизм, который подобен ударам - и удержанию - разрывов, если каждый SQL каждый раз обращается ко всем данным в таблице.
Убедитесь, что SQL не обращается к большему количеству строк, чем необходимо. Это дает самый эффективный способ сохранить производительность. Обычная база данных знает, как обрабатывать IO, и выполняет некоторую форму кеширования наиболее часто используемых данных.
Если ваше приложение уже свело к минимуму все возможные обращения и вы уже используете самые быстрые дисковые системы, рассмотрите возможность использования реальных массивов флэш-памяти. Они могут повысить производительность на другом уровне.
источник
Пожалуйста, обратитесь эти сообщения:
Подсказки, чтобы сделать ваши данные как можно меньше:
Создайте свои таблицы, чтобы минимизировать их пространство на диске. Это может привести к огромным улучшениям за счет уменьшения объема данных, записываемых на диск и считываемых с него. Меньшие таблицы обычно требуют меньше основной памяти, в то время как их содержимое активно обрабатывается во время выполнения запроса. Любое уменьшение пространства для табличных данных также приводит к меньшим индексам, которые могут быть обработаны быстрее.
MySQL поддерживает множество различных механизмов хранения (типы таблиц) и форматы строк. Для каждой таблицы вы можете решить, какой метод хранения и индексирования использовать. Выбор правильного формата таблицы для вашего приложения может значительно повысить производительность.
Вы можете повысить производительность таблицы и минимизировать объем хранилища, используя перечисленные ниже методы: - Используйте наиболее эффективные (наименьшие) типы данных. MySQL имеет много специализированных типов, которые экономят дисковое пространство и память. Например, используйте меньшие целочисленные типы, если это возможно, чтобы получить меньшие таблицы. MEDIUMINT часто является лучшим выбором, чем INT, поскольку столбец MEDIUMINT занимает на 25% меньше места.
Объявите столбцы как NOT NULL, если это возможно. Это делает все быстрее, и вы экономите один бит на столбец. Если вам действительно нужен NULL в вашем приложении, вы обязательно должны его использовать. Просто не используйте его во всех столбцах по умолчанию.
Для таблиц MyISAM, если у вас нет столбцов переменной длины (столбцы VARCHAR, TEXT или BLOB), используется формат строки фиксированного размера.
Таблицы InnoDB используют компактный формат хранения. В версиях MySQL более ранних, чем 5.0.3, строки InnoDB содержат некоторую избыточную информацию, такую как количество столбцов и длина каждого столбца, даже для столбцов фиксированного размера. По умолчанию таблицы создаются в компактном формате (ROW_FORMAT = COMPACT). Наличие компактного формата строк уменьшает пространство хранения строк примерно на 20% за счет увеличения использования ЦП для некоторых операций. Если ваша рабочая нагрузка является типичной, которая ограничена частотой обращений к кэшу и скоростью диска, она, вероятно, будет быстрее. Если это редкий случай, который ограничен скоростью процессора, он может быть медленнее.
Компактный формат InnoDB также меняет способ хранения столбцов CHAR, содержащих данные UTF-8. Если ROW_FORMAT = REDUNDANT, символ UTF-8 CHAR (N) занимает 3 × N байтов, учитывая, что максимальная длина кодированного символа UTF-8 составляет три байта. Многие языки могут быть написаны, главным образом, с использованием однобайтовых символов UTF-8, поэтому фиксированная длина хранилища часто занимает пустое место. С форматом ROW_FORMAT = COMPACT InnoDB выделяет переменный объем памяти в диапазоне от N до 3 × N байтов для этих столбцов, удаляя конечные пробелы при необходимости. Минимальная длина хранилища сохраняется в виде N байтов для облегчения обновления на месте в типичных случаях.
Первичный индекс таблицы должен быть как можно короче. Это делает идентификацию каждого ряда легкой и эффективной
Создавайте только те индексы, которые вам действительно нужны. Индексы хороши для поиска, но плохи, когда вам нужно быстро хранить данные. Если вы обращаетесь к таблице в основном путем поиска по комбинации столбцов, создайте для них индекс. Первая часть индекса должна быть наиболее часто используемой колонкой. Если вы всегда используете много столбцов при выборе из таблицы, первый столбец в индексе должен быть с наибольшим количеством дубликатов, чтобы получить лучшее сжатие индекса.
В некоторых случаях может быть полезно разделить таблицу на две части, которые сканируются очень часто. Это особенно верно, если это таблица динамического формата, и можно использовать меньшую таблицу статического формата, которую можно использовать для поиска соответствующих строк при сканировании таблицы.
источник