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