Как я могу учиться делать реалистические предположения о производительности базы данных?
Я - прежде всего, Java-разработчик, который работает с, в спящем режиме, и в некоторых моих вариантах использования у меня есть запросы, которые работают очень медленно по сравнению с тем, что я ожидаю. Я говорил с локальным DBAs, и во многих случаях они утверждают, что производительность не может быть улучшена из-за природы запроса.
Однако я несколько не решаюсь ловить их на их слове. Что ресурсы могут я использовать для изучения, когда я должен высосать его и найти другой способ получить информацию, я хочу или учусь жить со скоростью и когда я могу назвать ерунду на DBAs.
5 ответов
Вы находитесь на интересном этапе. Большинство Java-разработчиков используют инструменты ORM, потому что они ничего не знают о базах данных, не хотят ничего узнавать о базах данных и особенно не хотят ничего узнавать об особенностях конкретной проприетарной СУБД. ORM якобы защищают нас от всего этого.
Но если вы действительно хотите понять, как должен выполняться запрос, вам придется понять, как работает база данных Oracle. Это хорошо: вы определенно создадите лучшие приложения Hibernate, если будете работать с зерном базы данных.
В комплект документации Oracle входит том по настройке производительности. С него и следует начать. Узнайте больше. Как уже говорили другие, инструментом начального уровня является EXPLAIN PLAN. Еще одно важное чтение - Руководство по концепциям баз данных компании Oracle. Жизненно важным аспектом настройки является понимание логической и физической архитектуры базы данных. Я также согласен с рекомендацией DCooke о книге Тома Кайта.
Имейте в виду, что есть подрядчики и консультанты, которые зарабатывают на жизнь настройкой производительности Oracle. Если бы это было легко, они были бы намного беднее. Но вы определенно можете дать себе достаточно знаний, чтобы заставить этих надоедливых DBA взаимодействовать с вами должным образом.
DCookie, OMG и APC получают +1 за свои ответы. Я был на стороне администраторов баз данных для приложений Hibernate, и, как сказал Том Кайт, нет параметра «fast = true», который мог бы использовать неэффективный SQL и ускорить его работу. Время от времени мне удавалось захватить проблемный запрос Hibernate и использовать анализатор Oracle SQL для создания профиля SQL для этого оператора, который улучшает производительность. Этот профиль представляет собой набор подсказок, которые «перехватывают» создание оптимизатором плана выполнения и вынуждают его (без изменений в приложении) выбрать лучший план, который обычно по какой-то причине игнорируется оптимизатором. Тем не менее, эти результаты являются скорее исключением, чем правилом для плохо работающего SQL.
Одна вещь, которую вы можете сделать как разработчик, который предположительно понимает данные лучше, чем уровень ORM, - это написать эффективные представления для решения конкретных проблем с запросами и представить эти представления в Hibernate.
Очень специфическая проблема, на которую следует обратить внимание, - это столбцы Oracle DATE (не TIMESTAMP), которые попадают в запросы, сгенерированные Hibernate и сравниваются с переменными привязки в предложении WHERE - несоответствие типов с типами данных временных меток Java предотвратит использование индексов для этих столбцов.
На чем основаны ваши ожидания производительности запросов? Интуиция? Если вы собираетесь спорить с DBA, вам нужно знать (как минимум), что представляют собой ваши запросы, понимать EXPLAIN PLAN и быть в состоянии указать, как улучшить ситуацию. И, как отмечает @OMG Ponies, Hibernate может плохо справляться с построением запросов - что тогда делать?
Нелегко? Возможно, лучшим подходом было бы занять немного менее враждебную позицию по отношению к сотрудникам DBA и вежливо спросить, что именно в запросах препятствует улучшению производительности и есть ли у них какие-либо предложения о том, как их можно рефакторить, чтобы они работали лучше.
это также может быть проблема со структурой таблицы (нормализацией). В основном, именно поэтому я не использую hybernate - вы всегда должны иметь возможность писать свои собственные запросы, которые являются оптимальными.
Размещаю свой комментарий в качестве ответа:
Это компромисс с использованием ORM - вы находитесь в его власти в отношении того, как он строит запрос, который отправляется в базу данных. LINQ - единственное, что меня заинтересовало, потому что вы можете использовать его в тандеме с хранимыми процедурами для подобных ситуаций. Я удивлен, что DBA не говорят вам отказаться от ORM, если вы хотите большей скорости...
План EXPLAIN даст вам представление об эффективности, но не даст представления о скорости. Для Oracle вам нужно будет использовать tkprof (если он вам доступен), чтобы проанализировать происходящее.