Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

Статистическая глобальная оптимизация

Возможности улучшений физической структуры базы данных на основе статистической информации о потоке запросов зависят от специфики конкретной СУБД. Вообще говоря, в число этих возможностей входят и изменения способа хранения отношений (если, как в СУБД INGRES, система поддерживает более одного способа хранения), и заведение новых копий отношения в распределенной базе данных (если в системе обеспечивается поддержка копий), и порождение новых разделов отношения (если система поддерживает разделенное хранение отношение) и т.д. Но если система, подобно System R, допускает сохранение ранее откомпилированных запросов и их повторное многократное выполнение, то естественным ограничением автоматических преобразований физической структуры базы данных является следующее: каковы бы не были эти преобразования, ранее откомпилированные запросы должны оставаться выполняемыми.

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

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

Примером компонента СУБД, поддерживающего оптимальный набор индексов в реляционной базе данных, может служить средство DBDSGN [119], разработанное в рамках СУБД System R. (Как отмечается в [119], на основе этого средства впоследствии был создан коммерческий продукт RDT, используемый в коммерчески доступных СУБД фирмы IBM SQL/DS и DB2.)

DBDSGN обладает двумя основными особенностями. Первой особенностью является то, что это средство не интегрировано с внутренними компонентами System R, в частности, с оптимизатором запросов. В DBDSGN используется информация, которую можно получить от системы через ее стандартный интерфейс. Язык SQL, обеспечивающий этот интерфейс, включает специальный оператор EXPLAIN, позволяющий получить информацию о типе запроса, его структуре, выбранном для выполнения плане и оценках стоимости плана целиком и его составляющих. На основе этой информации в DBDSGN принимаются решения о необходимости создания дополнительных индексов, и индексы создаются также на основе обычного интерфейса SQL (используется динамически выполняемый оператор CREATE IMAGE; подробности о возможностях System R по части динамически выполняемых операторов можно найти в [129]).

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

Вторая особенность связана с тем, что задача выбора оптимального набора индексов является NP-полной, и, следовательно, ее точное решение может оказаться слишком накладным. Поэтому для решения применяется набор эвристических правил. Мы не будем описывать применяемые в DBDSGN эвристики, поскольку достаточно сложны и специфичны. Как отмечается в [119], эти эвристики позволяют получить решение, близкое к оптимальному.

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

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

Назад | Содержание | Вперед

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...