blogs.embarcadero.com
Производительность систем БД настолько важная тема, что именно вопросы снижения времени отклика и повышение эффективности обслуживания пользователей являются сегодня двигателем инициатив большинства компаний по смене архитектуры и модернизации инфраструктур.
Чтобы соответствовать современным требованиям, компаниям приходится идти на значительные финансовые затраты для достижения необходимого уровня масштабирования, пытаясь получить выигрыш за счет более эффективного решения своих задач.
На производительность информационных систем, в конечном счете, влияет огромное количество различных факторов, начиная от изначальных архитектурных решений, способностей и возможностей используемых СУБД и аппаратного обеспечения, заканчивая состоянием собственно информационных ресурсов.
Индексирование данных, работа с индексами - одна из фундаментальных основ работы любой базы данных. Правильное применение индексов может повысить производительность информационной системы или приложения в разы, а то и в десятки раз. Подавляющее число специалистов по работе с данными хорошо знакомы с различными правилами, технологиями и приемами применения разнообразных индексов в промышленных системах. Тем не менее, бывает очень тяжело достичь оптимального баланса, так как добившись улучшения работы за счет расширения набора индексов, скорее всего, можно получить потери производительности при операциях модификации данных.
Оптимизация и тонкая настройка производительности систем БД требует расширенных знаний о хранимых данных. Прежде всего, качество проектирования архитектуры данных без учета этих знаний может сильно повлиять на производительность всей системы, на некорректное использование индексов встроенными оптимизаторами запросов, на возможности и стоимость масштабирования. Это касается не только широко распространенных "классических" реляционных СУБД, но и новейших классов нереляционных БД. Например, наличие достаточного пространства в оперативной памяти сервера для помещения наиболее часто используемых блоков индексов может резко улучшить производительность. И напротив, использование в качестве ключа партиционирования полей с неподходящим распределением может отрицательно повлиять на эффективность функционирования системы по мере добавления и модификации информации.
Физическая организация данных также сильно отличается для различных аппаратно-программных сред, а ее оптимальность меняется по ходу эксплуатации системы и зависит от актуальных внутренних характеристик и метрик хранимых данных.
Никто, кроме "владельца" данных не может лучше знать все тонкости устройства, взаимодействия, использования и распределения значений информации. Поэтому, оптимизация и тонкая настройка запросов на сервере - это скорее, искусство, требующее колоссальных знаний, времени и опыта.
Как же быть, если результат нужен быстро, а достигнутый уровень "шедевра" может стать недостаточным на следующий день работы системы?
В каждой СУБД, какого бы типа она не была, обязательно имеются средства, автоматически ищущие и находящие практические решения на каждый момент выполнения запроса. Чаще всего, это внутренний оптимайзер, достаточно "интеллектуальный" для решения обычных рутинных задач. Он формирует планы выполнения каждого запроса или кода на SQL. Ведущие СУБД применяют оптимайзеры, которые разбирают код SQL, проводят его возможные логические преобразования, ищут решения на физическом уровне (и при этом опираются на имеющиеся статистики), оценивают стоимость каждого варианта и выбирают окончательный план по общей стоимости выполнения.
Чтобы повлиять на выбор плана оптимайзером, нужно очень много знаний: теоретические о технологиях, о БД, физических носителях, аппаратных средствах, свойствах данных, распределении зачений, частотах использования. Оптимайзер находит план исходя из внутренних данных. И надо понимать, почему, на основании какой части этой информации было принято конкретное решение.
Для успешной работы информационных систем администраторы БД должны обеспечить сбор и обновление статистик по данным. В современных условиях, когда резко возросло количество различных БД на разного типа СУБД, каждому администратору необходимы простые и эффективные средства, расширяющие возможности инструментов СУБД.
Как с помощью решений компании Embarcadero можно упростить и сделать более эффективным процесс управления структурами индексов, сбора и поддержки статистик в акутальном состоянии, выяснения почему оптимайзер использует определенный план, а в случае необходимости, быстро найти альтернативные варианты оптимизации запроса на конкретной БД - рассказано на вебинаре "Анализ индексов, использование статистик и гистограмм при оптимизации запросов". Большую часть вебинара составляет демонстрация решения этих задач в Embarcadero DBArtisan и DB Optimizer. На базе использования подробных статистик и метрик с помощью этих инструментов можно быстро найти оптимальный план, оптимизировать структуру и применение индексов в любой базе данных на платформах Oracle, MS SQL, Sybase и DB2.
