Подводные камни при разработке прототипа базы данных (для тестирования жизнеспособности)

Question

Исходя из моего предыдущего вопроса , я собираюсь запустить несколько тестов производительности для различных потенциальных схемных представлений объектной модели. Однако подвох заключается в том, что, хотя модель концептуально завершена, она еще фактически не завершена - и поэтому точное число таблиц и количество / типы атрибутов в каждой таблице не определены.

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

И вот тут возникает вопрос. Мне известно, что характеристики производительности баз данных могут быть не интуитивно понятными, так что небольшое (даже «тривиальное») изменение может привести к разнице на порядок величины. Поэтому мне интересно, какие распространенные подводные камни могут возникнуть при настройке фиктивной структуры таблицы и заполнении ее фиктивными данными. Поскольку среда, вероятно, будет иметь огромное значение, целью является Oracle 10.2.0.3.0, работающий на RHEL 3.

(В частности, я ищу примеры, такие как «убедитесь, что одна из ваших таблиц имеет гораздо более избирательный индекс, чем другой»; «убедитесь, что у вас больше x строк /» столбцы, потому что ниже этого вы не столкнетесь с ошибками страниц, и производительность будет отличаться ";" убедитесь, что вы тестируете с типом данных DATETIME, собираетесь ли вы использовать его, потому что он сильно изменит план запроса "и т. д. I попробовал Google, ожидая, что будет много страниц / сообщений в блоге о передовых методах в этой области, но не мог найти деревья для леса (много страниц о настройке производительности существующей БД вместо этого).)

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

Answer 1

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

1. быть в курсе архитектур, лучших практик и шаблонов
2. знать, как работает база данных
3. выполнение выборочных испытаний для получения дополнительной точности или определения влияния дурацких дизайнерских областей

Больше на каждом:

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

2. Как работает база данных: вам нужно в целом понять, какие опции оптимизатор / планировщик имеет для ваших запросов. Какое влияние оказывают различные заявления на добавление индексов? Каково влияние индексации 256-байтового varchar? Будут ли в отчетных запросах даже ваши индексы? и т.д.

3. Теперь, когда вы выбрали правильный подход и в целом понимаете, как будут работать 90% вашей модели, вы часто прогнозируете производительность с большинством небольших и средних баз данных. Если у вас огромный, на карту поставлена ​​тонна, вам нужно получить более точное (возможно, потребуется заказать больше оборудования) или иметь несколько дурацких мест в дизайне - тогда сфокусируйте свои тесты именно на этом. Сгенерируйте достоверные тестовые данные - и (важные) статистические данные, которые вы увидите в производстве. И посмотрите, что база данных будет делать с этими данными. Если у вас нет реальных данных и реальных серверов размером с продукт, вам все равно придется экстраполировать, но вы, по крайней мере, должны быть в состоянии быть достаточно близко.

Answer 2

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

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

Затем, когда вы получите что-то простое, правильное и правильное, начните беспокоиться о скорости. Вы будете удивлены тем, насколько вы можете ускорить процесс, просто изменив физические возможности своей базы данных, не изменяя код приложения. Для этого вам нужно много узнать о вашей конкретной СУБД.

Они никогда не говорили, что разработка баз данных будет легкой. Они просто сказали, что будет очень весело!

Answer 3

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

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

Другой пример: код. Большинство проблем с производительностью связано с плохо написанным SQL, особенно с неподходящими объединениями. Возможно, вы сможете применить индекс для настройки индивидуума на SELECT * FROM my_table WHERE blah, но это не поможет вам предотвратить плохо написанные запросы.

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

редактировать

Прочитав вопрос, с которым вы связались, я более чётко понимаю, откуда вы пришли. У меня есть небольшой опыт этой проблемы отображения Hibernate с точки зрения дизайнера базы данных. Возьмем пример, который вы приводите в конце страницы ...

Animal> Vertebrate> Mammal> Carnivore> Canine> Dog type иерархия,

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

Это скорее проблема дизайна приложения, чем проблема базы данных. Будет иметь значение то, будете ли вы создавать таблицы только на конкретном уровне (CATS, DOGS) или будете ли вы копировать иерархию в таблицах (ANIMALS, VERTEBRATES и т. Д.). К сожалению, здесь нет простых ответов. Например, вы должны учитывать не только производительность извлечения данных, но и то, как Hibernate будет обрабатывать вставки и обновления: дизайн, который хорошо работает для запросов, может стать настоящим кошмаром, когда речь идет о сохраняющихся данных. Также влияет реляционная целостность: если у вас есть какая-то сущность, которая применяется ко всем Mammals, приятно иметь возможность применять внешний ключ к таблице MAMMALS.