Планирование емкости дисков и оперативной памяти
Планирование дискового пространства и объема памяти для сервера базы данных является черным делом. Чем больше, тем лучше. Быстрее, тем лучше.
В качестве общих указаний я предлагаю следующее:
- Вы хотите , больше дискового пространства , чем вы когда - либо нужно.
Оцените, сколько дискового пространства вам потребуется в течение следующих 3-5 лет, а затем удвойте его.
- Вам понадобится достаточно оперативной памяти для хранения индексов базы данных в памяти, обработки самого большого запроса, по крайней мере, два раза, и при этом останется достаточно места для исправного дискового кэша ОС.
Размер индекса зависит от вашей базы данных, а все остальное сильно зависит от вашего набора данных и структуры запроса / базы данных. Я предложу «По крайней мере, в два раза больше вашей самой большой таблицы» в качестве предложения, но учтите, что это предложение разбивает на действительно большие операции с хранилищами данных, где самая большая таблица может составлять десятки или сотни гигабайт.
У каждого поставщика базы данных есть некоторые инструкции по настройке производительности вашего диска / памяти / ядра ОС. Потратьте некоторое время с этой документацией перед развертыванием. Это поможет.
Сравнительный анализ рабочей нагрузки и планирование производительности
Предполагая, что вы еще не развернули ...
Многие системы баз данных поставляются с Benchmarking Tools. Например,
PostgreSQL поставляется с
pgBench .
Эти инструменты должны стать вашей первой остановкой в тестировании производительности базы данных. Если возможно, вы должны запустить их на всех новых серверах баз данных, чтобы понять, «сколько работы» может выполнять сервер баз данных.
Вооружившись теперь исходным тестом, ABSOLUTELY MEANINGLESSдавайте рассмотрим более реалистичный подход к тестированию: загрузите схему базы данных и напишите программу, которая заполняет ее фиктивными данными, а затем выполните запросы вашего приложения к этим данным.
Это тестирует три важные вещи: 1. Сервер базы данных (аппаратное обеспечение) 2. Сервер базы данных (программное обеспечение) 3. Структура вашей базы данных и как она взаимодействует с (1) и (2) выше.
Обратите внимание, что это требует гораздо больше усилий, чем простые предварительно построенные тесты, такие как pgBench: вам нужно написать некоторый код для заполнения, и вам может понадобиться написать некоторый код для выполнения запросов и времени выполнения отчета.
Этот вид тестирования также значительно более точен: поскольку вы работаете со своей схемой и запросами, вы можете увидеть, как они будут работать, и это дает вам возможность профилировать и улучшать вашу базу данных / запросы.
Результаты этих тестов являются идеальным представлением вашей базы данных. На всякий случай предположим, что вы достигнете только 50-70% этой производительности в вашей производственной среде (остальное - подушка, которая позволит вам справиться с неожиданным ростом, сбоями оборудования, изменениями рабочей нагрузки и т. Д.).
Слишком поздно! Это в производстве!
Как только ваши системы будут запущены в эксплуатацию, будет слишком поздно проводить «тестирование» - вы можете на короткое время включить ведение журнала / синхронизацию запросов и посмотреть, сколько времени потребуется для выполнения, и вы можете выполнить некоторые «стресс-тестовые» запросы для больших наборов данных во время отключения. ч. Вы также можете посмотреть на использование ЦП, ОЗУ и пропускной способностью диска системы, чтобы понять, насколько сильно она загружена.
К сожалению, все эти вещи помогут вам понять, что делает система, и смутное представление о том, насколько она близка к насыщению.
Это подводит нас к ...
Текущий мониторинг
Все тесты в мире не помогут вам, если ваша система вдруг увидит новые / другие модели использования.
К лучшему или худшему, развертывания баз данных не являются статичными: ваши разработчики будут что-то менять, ваш набор данных будет расти (они никогда не уменьшаются), и ваши пользователи каким-то образом будут создавать безумные комбинации событий, которые вы никогда не предсказывали при тестировании.
Чтобы правильно планировать емкость вашей базы данных, вам необходимо внедрить некоторый мониторинг производительности, чтобы предупредить вас, когда производительность базы данных больше не соответствует вашим ожиданиям. На этом этапе вы можете рассмотреть корректирующие действия (новое оборудование, схема БД или изменение запроса для оптимизации использования ресурсов и т. Д.).
Примечание. Это очень общее руководство по определению размера оборудования базы данных и выяснению степени злоупотребления им. Если вы все еще не знаете, как определить, соответствует ли конкретная система вашим потребностям, вам следует обратиться к эксперту по базе данных.
Существует также сайт Stack Exchange, специально посвященный управлению базами данных: dba.stackexchange.com . Ищите их в архиве вопросов или просматривайте теги, специфичные для вашей базы данных, для получения дополнительных рекомендаций по настройке производительности.