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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Чтобы смоделировать это, вы можете очистить кеш перед выполнением запроса:

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

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

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

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

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

Answer 3

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

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

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

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

Удачи

Answer 4

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

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