Короткий ответ
Да , вы можете написать значимый эталон исследуемого случая, если вы делаете это с осторожностью, и понимаете, что, если он имеет отношение к конкретному случаю, он может не относиться к другим случаям. Это в равной степени верно при сравнении баз данных одного типа (реляционная база данных и другая реляционная база данных) или баз данных разных типов.
Нет , вы не можете написать эталонный тест, который волшебным образом докажет, что конкретная база данных лучше, чем другая в каждом случае, для каждого приложения.
Длинный ответ
Можно определенно сказать, что «переход из базы данных в другую улучшил производительность нашего сайта».
Вы измеряете производительность предыдущей базы данных с помощью профилирования или статистики времени выполнения, собирая достаточно информации о запросах и их скорости.
Вы перемещаете приложение в новую базу данных.
Вы делаете те же меры.
Вы сравниваете.
Например, если полный список из 3 182 432 товаров загружен за 2,834 с. на старую базу данных и загружается за 0,920 с. в новой базе данных, учитывая, что в обоих случаях приложение имеет пустой кэш, это выигрыш: новая база данных улучшила производительность вашего сайта в отношении этого запроса.
Теперь, как и любой показатель производительности, он смещен:
Согласен, новый запрос быстрее. Но подождите, ваш администратор базы данных не знал, как использовать базу данных, которая у вас была раньше , поэтому запрос, который загружает все продукты, не оптимизирован . Если переписать его так, вы сможете загрузить эти продукты за 0,855 с. вместо 2.834.
Хорошо, у вас есть лучший результат. Но не думаете ли вы, что несправедливо сравнивать базу данных со свежими данными, просто сброшенными в базу данных за 10 лет, для которой последний план обслуживания выполнялся три года назад? Кстати, вы не думаете, что должны были обновить продукт базы данных хотя бы один раз за последние четыре года?
Некоторые запросы быстрее. Некоторые медленнее. Как рассчитать средний результат, чтобы узнать, что вы в целом повысили производительность при переходе на новую базу данных? Хорошо, время загрузки всех 3 182 432 продуктов быстрее. Но имеет ли это значение, если запрос выполняется на веб-сайте только в редком случае, когда администратор выполняет какую-то конкретную задачу, которую он выполнял только два раза за последние десять лет? С другой стороны, выполнение всех запросов на домашней странице для нового пользователя тратит 0,281 с. с новой базой данных, когда это было 0,207 с. со старой базой данных. Этот результат имеет гораздо большее значение, особенно потому, что эти запросы не могут кэшироваться в течение длительного времени и выполняются десятки тысяч раз в день.
Обе базы данных должны быть протестированы на одних и тех же серверах , на одном и том же оборудовании, одинаковой структуры. Например, вы не можете протестировать одну базу данных на одном жестком диске, а другую - на RAID1 двух SSD. Когда вы переносите большой проект в новую базу данных, есть вероятность, что вы просто разместите новую базу данных на сотне других вновь развернутых стоечных серверов, когда предыдущая база данных останется на предыдущих компьютерах.
Подводя итог, вы можете сравнить запросы к базе данных приложения и получить точные метрики . Но тогда вы должны придать значение числам. В этом состоянии соблазнительно сказать, что вы повысили производительность сайта: в противном случае руководство было бы сердитым, если бы узнало, что вы потратили тысячи долларов и месяцы работы, просто чтобы замедлить работу.
Самая страшная ошибка состоит в том, чтобы сделать эти выводы из тестов и заключить некоторую глупость типа «Microsoft SQL Server в три раза быстрее, чем Oracle»: говорить это все равно что говорить, что «Java лучше, чем PHP». Определись лучше. Лучше в каких случаях? Для каких приложений? Для чего команда разработчиков?
Чем больше вы интерпретируете и обобщаете, тем больше вещь становится неактуальной и бессмысленной.
Запрос, который select [...]вы можете найти в ревизии # 832 в файле ProductFactory.cs, строка 117 выполняется менее чем за 0,5 с. с новой базой данных при тестировании в условиях, указанных в приложении M к нефункциональным требованиям, случай 3. Это позволяет передать нефункциональное требование 527 (см. стр. 80, редакция 9). Это же требование не было выполнено с предыдущей базой данных, когда результаты испытаний находились в диапазоне 0.9..1.3 с. в тех же условиях.
имеет смысл для разработчика и достаточно точен, чтобы знать, что было протестировано, как и каковы были результаты. Это отвечает на ваш вопрос № 2.
К сожалению, это не имеет никакого смысла для руководства. Вместо:
Миграция нашего продукта с MySQL на новейшую версию Microsoft SQL Server повысила общую производительность нашего продукта в пять раз, одновременно сократив затраты в два раза и воздействие на окружающую среду в три раза. Мы считаем, что перенос всех наших приложений на Microsoft SQL Server в следующем году даст еще лучшие результаты и повысит нашу конкурентоспособность на рынке.
это чистый маркетинговый jibber-jabber, и, технически, ничего не значит, но на удивление имеет значение для менеджмента и отделов маркетинга.
Наконец, мы можем сравнить различные типы баз данных? Я бы сказал, что это вполне возможно. Допустим, у меня есть сайт с большими фотографиями. Эти фотографии хранятся в varbinary(max)Microsoft SQL Server 2005 (поэтому я не могу использовать filestream). Я обеспокоен производительностью при загрузке этих фотографий, поэтому я решил вместо этого сохранить фотографии в виде файлов, используя файловую систему в качестве моей новой базы данных. Во-первых, эти файлы хранятся на том же компьютере, что и база данных. Я профилирую новое решение и получаю результат, который показывает, что в моем случае файлы загружаются на 4% быстрее из файловой системы, чем из Microsoft SQL Server. Тест очень четкий. Теперь я могу подумать о развертывании выделенного сервера, оптимизированного для прямого хранения файлов, а не об использовании сервера, оптимизированного для Microsoft SQL Server.