Корпоративные базы данных - статьи

       

Состояние и перспективы Microsoft SQL Server


Алексей Шуленин, Microsoft

Новые и обновленные утилиты

  • SQL Enterprise Manager
  • Интегрирован с MMC, включает средства взуализации из Visual Data Tools (создание структуры, протягивание отношений, редактирование данных в таблицах по ходу дела, ...)
  • Больше wizard'ов, хороших и разных:

    • Создание базы, поддержка базы, управление предупреждениями (alerts), импорт/экспорт данных, тиражирование, хранимые процедуры, ...
    • Index Tuning Wizard- моделирование рабочей нагрузки (множества запросов и определение наиболее подходящих индексов. Взаимодействует с Query Optimizer. Не учитывает одновременных пользователей.

  • Нельзя администрить предыдущие версии SQL Server- они не понимают новую модель SQL-DMO

    • Использовать старый Enterprise Manager или написать свой snap-in для 4.2, 6.х



  • SQL Server Agent (бывший SQL Executive)
  • Основные понятия: jobs (бывшие tasks), operators и alerts
  • Job- последовательность шагов

    • Каждый шаг - batch на T-SQL
    • Выбор действия в зависимости от удачного / неудачного выполнения шага (выход с сообщением, переход на шаг № ...)
    • Время и частота выполнения задач планируется администратором

  • Operator - лицо, которому посылается сообщение по сети, e-mail или пэйджингу о результатах выполнения job или наступления alert
  • Назначение выполнения job и/или отправки сообщения для operator

    • на возникновение ошибки с определенным номером в определенной БД
    • на достижение порогового значения каким-либо показателем в SQL Performance Monitor



  • SQL Server Profiler (бывший SQL Trace)
  • В отличие от Trace, кот. использовал ODS, Profiler встроен в Engine и обладает большими возможностями

    • Может смотреть, что делают SP, проигрывать ранее записанную последовательность действий, имеет лучшие возможности фильтрации и группирования событий
    • SQL Query Analyzer (бывший isql/w)

  • Улучшенный Showplan и графический план выполнения запроса
  • Выделение языковых конструкций цветом
  • Настройка вида результатов для удобочитаемости (grid)

Механизм хранения

  • Механизм хранения управляет
  • размещением данных на жестких носителях
  • распределением памяти
  • вводом / выводом
  • контролем одновременного доступа к данным
  • журналированием транзакций
  • резервным копированием и восстановлением
  • Цель - полностью отделить реляционный engine (процессор запросов) от механизма хранения
  • и заставить QP общаться с ним только через уровень OLE DB


Базы данных и файлы

  • Понятие "device" уходит
  • Device => file, БД может лежать на нескольких файлах, обратное теперь неверно
  • БД и журнал транзакций теперь обязательно лежат на разных файлах (.mdf / .ndf и .ldf)
  • Всего три типа файлов в БД:

    • primary (.mdf)- cтартовая точка БД, содержит данные + указатели на остальные файлы, может быть только один на БД
    • secondary (.ndf)- необязателен, содержит данные, не поместившиеся в primary, в одной БД может быть много
    • log file (.ldf)- как минимум, один, содержит transaction log

  • Объекты БД не могут быть приписаны конкретному файлу, для этих целей используется группа

Базы данных и группы файлов

  • Понятие "сегмент" уходит
  • Файлы могут объединяться в file groups для удобства размещения данных на определенные диски и администрирования

    • Группе файлов могут назначаться отдельные таблицы, индексы и данные типов text, ntext, image
    • Каждый файл может быть членом только одной группы

  • Два типа file groups

    • Default- для primary файлов, системных таблиц и файлов, для которых группа не определена. Всегда одна на БД
    • User-defined- для остальных. Может быть несколько групп на БД
    • Logи не являются частью групп и управляются отдельно от базы


Динамическое управление размером
Новые форматы хранения
Хранение text и image

Полнотекстовый поиск

  • Расширения DML
  • Предикаты CONTAINS, FREETEXT, функция RELEVANCE, ...

    • SELECT publication, pub_date, writer FROM magazines WHERE CONTAINS ( article, ' Edison NEAR(WORD,20) "electric%" ' )

  • Этапы развития
  • Ноябрь 1997- OLE DB провайдер для Index Server 2.0- поиск данных в файловой системе
  • Март 1998- OLE DB провайдер для Site Server 3.0- поиск по документам на Web
  • 2-я половина 1998 г.- поиск по BLOB-полям в Sphinx
  • Возможности легко доступны из приложений

Set rstMain = CreateObject(ADODB.RecordSet) rstMain.Open "SELECT DocAuthor,

FileName FROM SCOPE(' DEEP TRAVERSAL OF ( "D:\Sphinx\tsql\specs") ') WHERE size > 50000", "Provider = MSIDXS;" Блокировка уровня записи


Key Range Locking
Динамическая блокировка
Log Manager
Резервное копирование
Производительность SQL Server 7.0 при on-line backup
Кое-что новое в T-SQL

  • В связи с введением распределенных запросов имя состоит из 4-х частей
  • Отложенное разрешение имен
  • Можно создать таблицу и тут же сослаться на нее в хранимой процедуре
  • Новое в поддержке курсоров
  • Тип Cursor, переменные можно передавать как параметры
  • Процедуры sp_cursor_list, sp_describe_cursor_columns / _tables
  • Процедуры управления заданиями и предупреждениями
  • sp_add_alert, sp_add_job, sp_add_operator, ...
  • Процедуры управления SQL Profiler xp_trace_*
  • Добавлены новые указания оптимизатору (hash, merge, loop, robust plan, ... ) для операторов DML
  • Новые clauses TOP, PERCENT, WITH TIES для SELECT
  • ALTER PROCEDURE (TRIGGER, VIEW) без изменения прав
  • Опция DROP COLUMN появилась в ALTER TABLE
  • Добавлены новые функции
  • Системные: ObjectProperty, ColumnProperty, DatabaseProperty, ...
  • Статистические: StDev, Var, ...
  • Секьюрные: Is_Member, Is_SrvRoleMember, ...
  • Операции над датами (+/-)
  • Новые типы данных
  • Unicode'овские nchar, nvarchar, ntext
  • длина char, varchar, binary, varbinary- до 8К
  • Тип Uniqueidentifier (GUID), поле ROWGUIDCOL и функция NewID()
  • Substring от данных TEXT и IMAGE


Новое в безопасности

  • Улучшенная интеграция с безопасностью NT
  • Аутентификация средствами NT (как текущий пользователь- без пароля, как другой- login+pwd)
  • Mixed (возможна аутентификация средствами SQL Srv)
  • Полная поддержка пользователей, групп и ролей
  • Роли могут быть приписаны пользователям и группам NT, а также пользователям Sphinx
  • Роли могут быть вложены
  • Прикладные роли для 3-уровневых систем
  • Позволяют назначать права при доступе через приложение, а не isql
  • Гибкая гранулярность прав и системных ролей
  • Предопределенные роли ServerAdmin, SecurityOfficer, ...
  • Поддержка делегирования в NT 5.0
  • На 2-м сервере не как удаленный пользователь, а под тем же именем
  • Простое и мощное администрирование

Новое в QP

  • Multi-index - одновременное использование нескольких индексов (в т.ч.


    над одной таблицей)
  • пересечение двух множеств RID по каждому индексу для получения результирующего множества (например, SELECT * FROM orders WHERE cust_id = 987 and order_value >= 10000- индексы по cust_id и order_value)
  • создание covering index из нескольких имеющихся, которые в отдельности не являются covering для данного запроса (covering index позволяет читать значения колонок с leaf-уровня, не залезая в саму таблицу)
  • Merge Join
  • Получить row из outer table
  • Получить row с таким же ключом из inner table
  • Если найден, далее- по inner table, если нет- по внешней
  • Выглядит как обычная nested iteration, но проходится за один шаг и потому выполняется быстрее
  • Hash Join
  • Хэш-функция - свертка ключа, на выходе- значение меньшего размера, основное требование- равномерное распределение, главное преимущество- доступ к записи за одно обращение к таблице
  • Пример - алфавитная записная книжка, первая буква- хэш-функция, буквенные секции - букеты
  • Применяется, когда не задан порядок сортировки или нет подходящих индексов
  • Прочитать меньшую таблицу, нарезать ключи и RID в букеты хэш-таблицы
  • Читать большую таблицу. Хэшировать ключ, проверить хэш-таблицу, повторить.
  • Hash aggregation (sum, ...)
  • Из входной таблицы хэшировать ключ в букет
  • Если он там уже лежит, вычислить агрегат
  • Зациклить, в конце выдать окончательный агрегат


Оптимизация запросов

  • Запросы оптимизируются по условной стоимости
  • Учитываются факторы количества операций чтения/записи и времени работы процессора
  • А также целевые записи (напр., построить оптимальный план для выбора первых 10 записей)
  • При этом используются
  • Статистика по хранимым данным (плотности и гистограммы)
  • Индексы (например, наличие уникального индекса о чем-то говорит?)
  • Ограничения (DRI, сonstraints, nulls)
  • Constraints и разбиение данных
  • Имеем несколько таблиц: январь, февраль, март
  • Построили совокупный view- union
  • Делаем из него select за один месяц, QP ищет только в одной таблице (при условии, что на нее был определен месячный constraint)
  • Auto partitioning при вводе by value между несколькими таблицами - в следующей версии
  • Обработка массивных обновлений- QP поддерживает индексы
  • При массовых insert, update, delete изменения сортируются по индексу и применяются за один проход (на один индекс)



    • Технология используется в ВСР, DBCC


Модель оптимизации

  • Определение самого дешевого дерева на основе пула альтернатив
  • Изменение порядка join'ов
  • (R JOIN S) JOIN T = (R JOIN T) JOIN S
  • Раннее применение условий фильтрации
  • Классы эквивалентности для колонок и другие неявные предикаты
  • Если a=b, то sort(a), очевидно, такой же, как sort(b)
  • Функциональная избыточность
  • Group(e#,ename) = group(e#)
  • ...

Параллельная обработка запросов

  • Параллельная обработка- одновременное выполнение одного запроса несколькими процессорами
  • Асинхронный ввод/вывод, обслуживание клиентов на разных потоках не рассматривается
  • Дает преимущество только на машинах с >1 СPU
  • Запрос компилируется для параллельного выполнения, формируется параллельный план
  • Единый параллельный план для нескольких процессоров
  • К операторам последовательного плана добавлены Exchange Operators (Distribute, Gather, Repartition)

Exchange Operator
Степень параллелизма

  • Кол-во процессоров, на которых выполняется данный шаг плана запроса
  • Может отличаться для разных шагов, например, при вычислении результирующего агрегата из промежуточных DOP=1
  • Insert / update / delete выполняются на одном потоке
  • Но их части, относящиеся к SELECT могут выполняться с DOP>1
  • Выигрывают долгоиграющие запросы с массивными агрегатами, joinами, unionами и т.д.
  • Не выигрывают OLTP-запросы
  • Число одновременных пользователей >> числа процессоров - предпочтительнее межзапросный параллелизм

Настройка DOP

  • В конфигурации max DOP меняется от 0 до 32
  • Default=1- отключить параллельное выполнение
  • Default=0 (автоматическая настройка в зависимости от конкретного запроса

    • Учет затрат на инициализацию параллельного плана, перемещение данных между потоками
    • При высокой загрузке, росте коннектов, нехватке памяти Sphinx будет стремиться понизить DOP
    • Сost threshold of parallelism- генерировать параллельные планы только для запросов с более высокой стоимостью (конфигурация 0-32767, default=5)

  • Showplan показывает Exchange-итераторы
  • DOP каждого конкретного запроса можно видеть в SQL Profiler



Сравнение производительности QP
Универсальный доступ к данным

  • Данные хранятся по-разному, а нужны зачастую все и сразу
  • Руководитель сидит в MS Project, хочет прочитать переписку (e-mail), поднять документ (файловая система) увидеть баланс (СУБД), послушать музыку...
  • Качать это все в базу всякий раз, чтобы воспользоваться ее механизмами обработки?

    • Потом обратно, а источники уже могли независимо измениться... Целостность?
    • QP СУБД заведомо не оптимизирован под новые типы

  • Выход - не универсальное хранение, а универсальная обработка
  • Никто, лучше самих данных, не знает, как их обрабатывать
  • OLE DB - набор стандартных интерфейсов: что должна уметь делать компонента обработки данных
  • Аналогия с ODBC, но для данных произвольной природы
  • OLE DB является "родным" интерфейсом Sphinx
  • QP общается с Data Storage через OLE DB
  • DB-Lib эмулируется средствами OLE DB и больше развиваться не будет

Универсальный доступ к данным (3)
Гетерогенные запросы
Распределенные операции в Sphinx
Sphinx и Data Warehousing
Объектная модель службы преобразования данных
Понятие пакета DTS
DTS Designer в Sphinx
Microsoft Data Cube Service

  • Базовая архитектура:
  • Кэшировать не дисковые страницы, а результаты запросов и метаданные
  • Мгновенный ответ на кэшированные запросы
  • Алгоритмы выведения пропущенных данных и преобразования запросов
  • Агрегация, фильтрация, комбинирование
  • Эффективное распределение обработки запросов и промежуточных вычислений между клиентом и сервером
  • Объединяет серверные и настольные платформы
  • Унифицирует доступ к многомерным данным из Excel, Plato, SQL Server ...

Microsoft

Алексей Шуленин

Тел.: (095) 967-8585 Факс (095) 967-8500

|

Содержание раздела