Тестирование производительности базы данных Greenfield

Question

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

Нужны ли данные для испытаний? Как это выглядит, если для базы данных еще не установлены шаблоны использования?

ПРИМЕЧАНИЕ. Ресурсы, такие как сообщения в блогах и названия книг, приветствуются.

Answer 1

Вы можете использовать такой инструмент, как RedGate's Data Generator, чтобы получить хорошую нагрузку на тестовые данные, чтобы увидеть, как схема работает под нагрузкой. Вы правы, что, не зная шаблонов использования, сложно составить идеальный план тестирования, но я предполагаю, что у вас должно быть четкое представление о том, какие запросы будут выполняться против него.

Адекватные стандарты производительности действительно определяются конкретными клиентскими приложениями, которые будут потреблять вашу базу данных. Получите трассировку профайлера sql, в то время как приложения попадают в ваш db, и вы должны быстро выявлять любые проблемные области, которые могут потребоваться в большей степени оптимизировать (или даже де-нормализовать в некоторых случаях).

Answer 2

Я хотел бы сделать несколько вещей:

1) имитирует подключение пользователя/приложения к БД и испытательной нагрузке (нагрузочное тестирование). Я бы посоветовал подключиться со многими другими пользователями, чем ожидалось, чтобы фактически использовать систему. Вы можете подключить всех своих пользователей или забрать стороннее программное обеспечение, которое будет регистрировать многих пользователей и выполнять определенные функции, которые, по вашему мнению, являются адекватным тестом вашей системы.

2) Вставьте много (возможно, миллионов) тестовых записей и снова проверьте нагрузку (проверка масштабируемости). По мере роста таблиц вы можете обнаружить, что вам нужны индексы, в которых у вас их раньше не было. Или могут возникнуть проблемы с VIEWS или соединениями, которые используются в системе.

3) Проанализируйте базу данных. Я имею в виду метод анализа таблиц. Here - скучная страница, описывающая, что это такое. Также here - это ссылка на отличную статью о настройке базы данных Oracle. Некоторые из них могут относиться к тому, что вы делаете.

4) Выполнять запросы, сгенерированные приложениями/пользователями, и запускать для них планы объяснений. Это, например, скажет вам, когда у вас есть полное сканирование таблицы. Это поможет вам решить многие проблемы.

5) Также резервное копирование и перезагрузка из этих резервных копий, чтобы показать уверенность в этом.

Answer 3

+1 birdlips, согласен с предложениями. Тем не менее, тестирование нагрузки базы данных может быть очень сложным, потому что первый и решающий шаг - это , предсказывающие как можно больше шаблоны данных, которые будут встречаться в реальном мире. Эта задача лучше всего делать в сочетании с, по крайней мере, одним экспертом в области, поскольку это очень важно для функциональных, а не технических аспектов системы.

Моделирование шаблонов данных настолько критично, что большинство планов выполнения SQL основано на табличной «статистике», то есть подсчетах и ​​коэффициентах, которые используются современной СУБД для расчета оптимального плана выполнения запроса. Некоторые люди написали книги по так называемому "query optimizers", например. Cost Based Oracle Fundamentals, и довольно часто проблема заключается в устранении некоторых из этих проблем из-за отсутствия документации о том, как работают внутренние устройства (часто преднамеренные, поскольку поставщики РСУБД не хотят слишком подробно рассказывать о деталях).

Возвращаясь к вашему вопросу, я предлагаю следующие шаги:

1. Дайте себе пару дней/недель/месяцев (в зависимости от размера и сложности проекта), чтобы попытаться определить состояние «зрелая» (например, 2-3-летняя) база данных, а также некоторые тесты производительности, которые вам нужно выполнить в этом большом наборе данных.
2. Постройте все сценарии для накачки в исходных данных. Вы можете использовать сторонние инструменты, но я часто обнаружил, что им не хватает функциональности, чтобы делать более продвинутые дистрибутивы данных, а также часто гораздо быстрее писать SQL, чем изучать новые инструменты.
3. Создайте/выполните клиент сценария тестирования производительности! Это в настоящее время сильно зависит от того, какое приложение необходимо поддерживать БД. Если у вас есть пользовательский интерфейс на основе браузера, многие инструменты, такие как LoadRunner, JMeter, выполняют сквозное тестирование. Для веб-сервисов есть SoapSonar, SoapUI ... Может быть, вам придется написать пользовательский JDBC/ODBC/.Net-клиент с многопоточными возможностями ...
4. Test -> tune -> test -> tune ...
5. Когда вы размещаете систему в производстве, приготовьтесь к неожиданностям, так как ваше предсказание шаблонов данных никогда не будет очень точным. Это означает, что вам (или тому, кто является производственным администратором баз данных), возможно, придется подумать о своих ногах и создать некоторые индексы «на лету» или применить другие трюки в торговле.

Успехов

Answer 4

Я нахожусь в такой же ситуации сейчас, вот мой подход (с помощью SQL Server 2008):

Создайте отдельную «Числа» таблица с миллионами строк данных образцов. Таблица может иметь случайные строки, идентификаторы GUID, числовые значения и т. Д. Напишите процедуру для вставки данных образца в вашу схему. Используйте модуль (%) столбца чисел для имитации разных идентификаторов пользователей и т. Д.

Создайте еще одну таблицу «NewData», аналогичную первой таблице. Это можно использовать для имитации добавления новых записей.

Создайте таблицу «TestLog», где вы можете записать количество строк, время начала и время окончания тестовых запросов.

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

Если производительность кажется быстрой, рассмотрите вероятность промаха в кеше! Например, если ваш производственный сервер имеет 32 ГБ оперативной памяти, а ваша таблица, как ожидается, будет 128 ГБ, поиск в случайной строке будет> 75%, вероятно, не будет найден в буферном кеше.

Для имитации этого, вы можете очистить кэш перед выполнением запроса:

DBCC DROPCLEANBUFFERS; (Если Oracle: ALTER SYSTEM FLUSH SHARED POOL)

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

Запуск SET STATISTICS IO ON; для сбора статистики запросов. Найдите случаи, когда число логических чтений очень велико (> 1000) для запроса. Обычно это знак полного сканирования таблицы.

Используйте стандартные методы, чтобы понять шаблоны доступа к запросам (сканирование и поиск) и настроить производительность.

Включить план фактического выполнения, профилировщик SQL Server