|
авторА что значить "трехэтажный запрос" применительно к ASA ?
Просто интересно.
У меня например в проекте "расчет зп" на ASA9 довольно шустро одним запросом считаются нарастающие с начала года по текущий месяц включительно, благодаря новым возможностям OLAP в ASA (PARTITION BY), результат перекладывается в времянку, а далее уже рассчитывается одним запросом с использованием этой времянки подоходний налог по всем сотрудникам, который учитывает нарастающие, налоговые вычеты, резиденство и налоговые шкалы (на текущий момент там всего одна запись - 13%). По обьему скрипт расчета подоходнего не маленький и там используется множество подзапросов, CROSS JOIN и LEFT JOIN. Самое удивительное, что довольно шустро работает и строиться приличный план запроса. В этом плане ASA действительно очень красиво оптимизирует - ради интереса я сравнивал аналогичные запросы у MSSQL 2000 и ASA 9.01 на одинаковых по структуре и содержанию БД и для "хитрых" (или можно еще сказать не красиво построенных) запросов ASA умудрялась производить разбор запроса, пересоединение таблиц в другом порядке (а то и просто выбрасывая таблицы, которые только служили для соединения между другими таблицами запроса, полезной нагрузки не несли и главное можно было обойтись без них) и выдавала на выходе более эффективный план запроса. Я не хочу сказать, что у MSSQL2000 плохой оптимизатор - наоборот, он очень мощный и навороченный, однако чтобы им эффективно пользоваться необходимы хорошие и глубокие знания архитектуры и принципов работы MSSQL, ASA же наоборот гарантирует, что как бы плохо не был написан план запроса, она его выполнит более менее эффективно. Раньше это выглядело бы смешно и действительно частенько ASA могла уйти в глубокий table scan, однако ее оптимизатор постоянно прогрессирует и сейчас на текущий момент по моему личному убеждению ничего смешного уже для конкурентов ASA нет по следующим причинам:
1. Существует возможность автоматической калибровки оптимизатора к показателям накопителей (оператор ALTER DATABASE CALIBRATE), позволяющего не гадать на кофейной гуще, за сколько времени считается информация с винта, а при построение запросов учитывать реальные характеристики железа
2. Работает эвристический анализатор запросов, поддерживающий автокорреляцию статистики и отслеживание лучших планов запросов с последующим их сохранением в кэш БД (т.е. планы живы даже после рестарта БД). Он отвечает за самообучение оптимизатора запросов по данным в БД и гарантирует что в независимости от содержания и кол-ва информации в БД оптимизатор будет знать ее текущее состояние и строить адекватные запросы.
3. Встроенна автоматическая поддержка RAID-массивов, гарантирующая, что оптимизатор всегда при построение планов запросов будет правильно выбирать, где лучше вести последовательное, а где параллейное чтение таблиц и индексов.
4. Синтаксис SQL расширен дополнительными конструкциями описания виртуальных представлений запросов, рекурсивных запросов, внутреннего соединения подзапроса с основным запросом (LATERAL соединение), а так же всевозможных OLAP расширений (PARTITION BY, WINDOW, RANGE и т.д.). По всем расширениям оптимизатор запросов имеет собственные специализированные алгоритмы для построения плана запроса, поэтому такие расширения с одной стороны развязывают руки программисту при построении сложных запросов, с другой стороны помогают оптимизатору запросов сразу уловить, что конкретно должен выполнить запрос и выполнить это в наиболее оптимальной форме, чем если бы действие, описанное на обычном SQL делилось на несколько запросов, с использованием времянок или циклов.
5. Поддерживаемый для программиста уровень блокировок как "всегда ROW LOCK" снимает с программиста задачу самому отслеживать, чтобы во время операций не было заблокировано лишних записей и не возникало deadlock-ов. Фактически ASA имеет довольно граммотный механизм блокировок, в которых при возможности без дополнительных последствий автоматом задействуются PRIMARY KEY и UNIQUE и программист при построении запроса всегда может быть уверен на 100%, что блокируются только те записи, которые он и предполагал заблокировать. Так же для уменьшения времени блокировок в ASA реализована модель обработки CONSTRAINTS и BEFORE триггеров во время ведения блокировок. В результате этого, если например должно измениться миллион записей и уже на второй становиться известно, что запись неудовлетворяет условию, ASA снимает блокировки, которые успела поставить и прекращает операцию изменения, откатывая начавшуюся транзакцию (откат все таки происходит по причине того, что в BEFORE триггерах возможно были изменения на обрабатываемые записи). Так же на уровне READ COMMITED открытые курсоры блокируют только текущие записи, а не все.
6. Модель нежесткой кластеризации таблиц с одной стороны в ASA, в отличие от MSSQL приводит к тому, что таблица может быть фрагментирована и для ее дефрагментации по кластерному ключу необходимо вставлять записи с указанием сортировки, приблеженной к кластерному ключу и периодически ее перестраивать с помощью команды REORGANIZE TABLE (к ее чести она не блокирует таблицу и разрешает всем продолжать с ней работать). Сама ASA по возможности старается новые записи вставлять в те странички, которые ближе по кластерному ключу, но опять же только при условии не снижения скорости вставки. Однако такое казалось бы неудобство оборачивается явным преимуществом по сранению с моделью кластарных индексов в MSSQL, так как там из за того, что MSSQL всегда при добавлении или изменении данных перетряхивает таблицу согласно ее кластерному индексу очень часто возникают случаи блокировок последней страницы таблицы, приводящие к тормозам при параллейной работе по вставке и изменению записей множества сессий. Лично мне легче в ASA периодически дефрагментировать таблицу, чем бороться с различными ньюансами блокировок в MSSQL (достаточно посмотреть на форум MSSQL - там блокировки и кластерные индексы - достаточно популярные вопросы)
7. Поддержка различного размера страниц в БД (от 1 до 32 кб), позволяет проектировать эффективные БД для различных задач, где при небольших обьемах БД и мощности серверов достаточно использовать страницы малого обьема, а при построении например аналитических хранилищ использовать большие по размеру страницы. В MSSQL размер страницы 8кб и точка, что не есть хорошее решение по моему скромному мнению
8. Модель работы компилятора ХП, представлений и триггеров в ASA организована так, что они компилируются при первом к ним обращении, однако планы запросов не привязываются к ним, а складываются в общий кэш наравне с планами запросов, непосредственно вызванных сессиями, что соотвествующе с одной стороны снимает всякую необходимость периодически обновлять статистику БД, выполнять перекомпиляцию ХП и гарантирует, что запросы в ХП будут наравне с остальными выполняться по лучшим планам запросов, составленных оптимизатором, что я тоже считаю большим преимуществом по сравнению с MSSQL.
9. Ну и в дополнение для облегчения тюнинга запросов в ASA существует прекрасная возможность создавать виртуальные индексы, которых не существует физически в БД, они не блокируют при создании таблицы, однако ASA учитывает их при построении графического плана запроса и позволяет программисту поэксперементировать с индексами и прикинуть, что и как. Так же этими виртуальными индексами активно пользуется служба "Консультант индексов", которая перехватывает поток запросов к БД, анализирует их и пользуясь такими индексами "прикидывает", а что собственно говоря можно улучшить. Причем рекомендации даются в виде 2 графических планов запросов "Как есть" и "Как может быть". Так же для тюнинга ХП существует служба "Профайлер ХП", отслеживающая все выполнения ХП, UDF и триггеров и показывающая, кто сколько выполнялся, с детальной расшифровкой времени выполнения каждой процедуры по ее строкам. Эта служба позволяет моментально "вычислить" узкие места системы, которые потом можно элементарно отладить с помощью встроенного дебаггера и графического плана запросов (в дебагере позволяется выполнять любые запросы во время точки останова).
Ну вот вроде все, чем по оптимизации ASA круче MSSQL. Но еще раз хочу заметить, что MSSQL не хуже в области оптимизации запросов, например у него в отличие от ASA поддерживается параллейное использование индексов, просто с ним возни больше, знаний больше надо и даже профу можно элементарно "лопухнуться" при составлении запроса, которые на малых тестируемых обьемах будет вести себя на ура, а при реальной нагрузке может привести сервер в состояние вечного тормоза или непрерывной цепи блокировок.
|
