Сравнительные базы данных

Я вижу много дискуссий о производительности db 'x' или о том, что переход от 'x' к 'y' улучшил производительность нашего сайта.

Я пока не вижу правильного бенчмаркинга, который работает в разных типах баз данных.

1. Можно ли написать значимый тест, который можно использовать для нескольких типов БД, таких как реляционные, ориентированные на документы и т. Д.

2. Как бы вы пошли о разработке такого теста?

Короткий ответ

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

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

Длинный ответ

Можно определенно сказать, что «переход из базы данных в другую улучшил производительность нашего сайта».

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

2. Вы перемещаете приложение в новую базу данных.

3. Вы делаете те же меры.

4. Вы сравниваете.

Например, если полный список из 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.

1. Если бы на карту были поставлены все основные компании, работающие с базами данных, и большая группа разработчиков, занимающихся разработкой приложений с открытым исходным кодом, то, если бы был способ сделать это, они бы это уже поняли (и получили результаты по всему Интернету. ).

2. Я бы не стал. Вместо этого создайте конкретные критерии для конкретных потребностей и условий.

В какой-то момент количество доступных денег и опыт дизайнера в конкретной базе данных могут определить ограничения больше, чем что-либо другое. Хороший Oracle dba превзойдет большинство начинающих разработчиков независимо от того, какую платформу они выберут.

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

Тем не менее, разработка сайта, такого как Computer Language Benchmarks Game , который включает в себя широкий спектр тестов и позволяет легко сравнивать тесты (либо специфические тесты для разных языков, либо композиты из многих языков), принесет некоторую пользу (при по крайней мере, в моих глазах), особенно если оно было настроено так, чтобы сообщество могло представлять решения и исправлять любые недостатки в схемах или запросах.

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

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

Я хотел бы добавить еще несколько причин, почему вы не можете сравнить все типы баз данных.

1. Существует два основных направления систем баз данных: OLAP и OLTP (см. Сравнение ).

2. Как вы сказали, существуют также реляционные и ориентированные на документы системы баз данных. Хотя RDBS строго следует принципу ACID , в большинстве документов-ориентированных DBS вы можете решить, что слабых данных достаточно для вашего приложения. Это делает блокировку и планирование намного проще.

Короче говоря: вы не будете спорить, что Lamborghini - лучший автомобиль в мире . Подумайте об объеме багажника, количестве мест или пробеге.

Примечание: вот эталон для систем баз данных OLTP.