Remkomplekty.ru

IT Новости из мира ПК
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Архитектура ms sql server

Различия в архитектуре Oracle и MS SQL Server

Мне приходилось сотрудничать со многими клиентами, использующими крупные производственные приложения, которые были “перенесены” в Oracle из другой платформы баз данных (например, MS SQL Server). Слово “перенесено” взято в кавычки потому, что большинство встречаемых мною адаптаций сводились к точке зрения “найти минимальные изменения, которые обеспечили бы успешную компиляцию и выполнение кода MS SQL Server на платформе Oracle”. Откровенно говоря, приложения, построенные в результате такого подхода к делу, попадались мне чаще всего, поскольку именно они требовали наибольшей помощи. Я вовсе не критикую SQL Server в этом отношении — ведь справедливо и обратное! Перенос приложения Oracle и его помещение с минимальными изменениями в среду SQL Server приведет к получению столь же плохо работающего кода, как и наоборот; проблема имеет обоюдный характер.

Однако в одном конкретном случае архитектура SQL Server и способ применения SQL Server действительно были навеяны реализацией Oracle. В качестве конечной цели ставилось масштабирование, но обратившиеся ко мне разработчики на самом деле не хотели переходить на другую базу данных. Они хотели провести перенос с минимальными усилиями со своей стороны, и потому оставили архитектуру в основном прежней — на уровне клиента и базы данных. Это решение имело два важных последствия.

  • Архитектура подключений в Oracle осталась той же самой, что и использованная в SQL Server.
  • Разработчики применяли литеральный (неограниченный) SQL-код.

Эти два обстоятельства повлекли за собой построение системы, которая не могла поддерживать необходимую пользовательскую нагрузку (серверу базы данных просто не хватало доступной памяти) и обладала крайне низкой производительностью.

Используйте единственное подключение в Oracle

В среде SQL Server открытие подключения к базе данных для каждого параллельно выполняющегося оператора является весьма распространенной практикой. При выполнении пяти запросов в среде SQL Server вполне можно встретить пять подключений. С другой стороны, в Oracle вне зависимости от того, сколько запросов нужно выполнить, пять или даже пятьсот, максимальное количество открываемых подключений равно единице. В результате то, что принято в SQL Server, совершенно не рекомендуется применять в среде Oracle; наличие множества подключений к базе данных просто нежелательно.

Однако, как раз это и было сделано. Простое веб-приложение для каждой веб-страницы может открывать 5, 10, 15 и более подключений, а это значит, что сервер мог поддерживать только 1/5, 1/10, 1/15 и менее параллельно работающих пользователей от того числа, которое должен. Кроме того, была предпринята попытка использования базы данных на обычной платформе Windows — в среде простого сервера Windows без доступа к Datacenter-вepcии Windows Server. В результате архитектура Windows с единственным процессом ограничила общий объем оперативной памяти, доступной серверу баз данных Oracle, до приблизительно 1,75 Гбайт. Поскольку каждое подключение Oracle занимает, как минимум, определенный фиксированный объем памяти, возможности масштабирования количества пользователей, работающих с приложением, были существенно ограничены. Объем оперативной памяти сервера составлял 8 Гбайт, но из них можно было использовать только около 2 Гбайт.

Важно! В среде 32-разрядной ОС Windows доступны способы использования большего объема оперативной памяти, такие как ключ /AWE, но для этого требуются версии ОС, которые в описанной ситуации не применялись.

Существовало три подхода к решению этой проблемы, причем все три были достаточно трудоемкими — и это после завершения “переноса”!

Были доступны следующие варианты.

  • Изменить архитектуру приложения, чтобы оно могло получить преимущества выполнения в среде Oracle, и во время генерирования страницы применять одно подключение, а не от 5 до 15. Это единственное решение, которое действительно устранило бы проблему.
  • Провести модернизацию ОС (отнюдь не простая задача) и задействовать модель с большим объемом доступной памяти, предлагаемую версией Windows Server Datacenter (что само по себе совсем не просто, т.к. сопряжено со сложной настройкой базы данных, с определением косвенных буферов данных и других нестандартных параметров).
  • Перенести базу данных из Windows в среду какой-то другой ОС, которая поддерживает множество процессов. Это фактически позволило бы базе данных задействовать всю установленную оперативную память. На 32-разрядной платформе Windows вы ограничены примерно 2 Гбайт памяти комбинированных областей PGNSGA (2 Гбайт для обеих вместе), поскольку они выделяются единственным процессом. При использовании платформы с множеством процессов, которая также является 32-разрядной, вы будете ограничены примерно 2 Гбайт для SGA и 2 Гбайт на процесс для PGA, что существенно больше, чем обеспечивает 32-разрядная платформа Windows.

Как видите, ни одна из этих возможностей не относилась к решениям, о которых можно было бы сказать: “Хорошо, мы сделаем это до обеда”. Каждая из них представляла собой сложное решение проблемы, которую проще всего было решить на этапе переноса базы данных, пока вносились изменения в код и в наиболее важные элементы системы. Более того, простое тестирование масштабирования, проведенное до развертывания системы, позволило бы выявить проблемы подобного рода еще до того, как конечные пользователи начали бы испытывать какие-то неудобства.

Используйте переменные привязки

Если бы я писал книгу о том, как строить немасштабируемые приложения Oracle, то первая и последняя глава называлась бы “Не используйте переменные привязки”. Отказ от применения переменных привязки является основной причиной возникновения проблем с производительностью и главным ограничителем возможностей масштабирования, не говоря уже об огромной степени риска в плане безопасности. Способ работы Oracle с разделяемым пулом (очень важная структура данных в разделяемой памяти) в большинстве случаев определяется разработчиками, использующими переменные привязки. Если вы хотите заставить транзакционную реализацию Oracle работать медленно, вплоть до полной ее остановки, просто откажитесь от применения переменных привязки.

Переменная привязки — это метка-заполнитель в запросе. Например, извлечения записи сотрудника 123 можно выполнить следующий запрос:

В качестве альтернативы можно запустить такой запрос:

В типичной системе запрос информации о сотруднике 12 3 вполне может быть выполнен один или два раза и больше никогда на протяжении длительного периода времени. Позже может требоваться информация о сотруднике 456, затем — о сотруднике 7 8 9 и т.д. Или, как в предшествующих операторах SELECT, если вы не указываете в своих операторах вставки переменные привязки, то значения первичного ключа будут жестко закодированы в них, и мне известен тот факт, что такие операторы вставки никогда не смогут использоваться повторно! Если в запросе применяются литералы (константы), то каждый запрос оказывается совершенно новым, никогда ранее не выполнявшимся в базе данных. Он должен быть синтаксически разобран, определен (произведено распознавание имен), проверен на соблюдение правил безопасности, оптимизирован и т.п.

Короче говоря, каждый запускаемый уникальный оператор будет требовать компиляции при каждом своем выполнении .

Во втором запросе использовалась переменная привязки :empno, значение которой передается во время выполнения запроса. Этот запрос компилируется только один раз, а затем план запроса сохраняется в разделяемом пуле (библиотечном кеше), из которого он может быть извлечен и применен повторно. Разница между этим двумя методами с точки зрения производительности и масштабируемости не просто велика — она огромна.

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

При выполнении полного разбора запроса база данных будет дольше хранить определенные низкоуровневые устройства последовательной обработки, называемые защелками (или внутренними блокировками). Эти защелки защищают структуры данных в разделяемой памяти Oracle от одновременных изменений двумя сеансами (в противном случае структуры данных были бы повреждены) и от считывания структуры данных кем-либо во время ее изменения. Чем дольше и чаще приходится “защелкивать” эти структуры данных, тем более длинной будет становиться очередь для получения таких защелок. Это приведет к монополизации ограниченных ресурсов. Временами компьютер может выглядеть недогруженным, тем не менее, все действия в базе данных будут выполняться очень медленно. Внешне все выглядит так, будто кто- то владеет одним из механизмов последовательной обработки, создавая очередь — достичь максимальной производительности не удастся. Достаточно наличия в базе данных одного неправильно ведущего себя приложения, чтобы производительность всех приложений значительно снизилась. Единственное небольшое приложение без переменных привязки со временем приведет к удалению из разделяемого пула всех SQL-запросов, принадлежащих остальным хорошо настроенным приложениям. Одной ложки дегтя хватит, чтобы испортить бочку меда.

Важно! Чтобы увидеть отличие между полным и частичным разбором в действии, рекомендуется пересмотреть демонстрационный видеоролик, доступный по ссылке http://tinyurl. corn/RWP-OLTP-PARSiNG. Он был смонтирован командой, с которой я работал — командой Real World Performance ( Производительность в реальном мире) из Oracle. В нем наглядно показана разница между полным и частичным разбором — она близка к отличию на порядок! В транзакционной системе, архитектура которой ориентирована на использование переменных привязки, можно добиться десятикратного увеличения скорости выполнения в случае их применения. Вы можете использовать эту короткую визуальную презентацию, чтобы убедить других разработчиков о высоком влиянии переменных привязки (либо их отсутствия) на производительность!

Единственное отличие между этими двумя процедурами состоит в том, что в одной применяется переменная привязки, а в другой — нет. Обе процедуры используют динамический SQL-код с идентичной логикой. Разница заключается только в применении переменной привязки в первой процедуре.

Фактически если вы не используете переменные привязки и применяете прием с конкатенацией строк, то код становится уязвимым для атак внедрением SQL и потому должен быть тщательно пересмотрен. Причем это должен сделать кто-то другой, а не разработчик, написавший этот код, потому что код должен быть пересмотрен критически и объективно. Если проверяющий является партнером автора кода или хуже того — другом или подчиненным, то проверка будет не столь критической, какой должна быть. К коду, разработанному без использования переменных привязки, следует относиться с подозрением — он должен быть скорее исключением, нежели нормой.

Структура современной СУБД на примере Microsoft SQL Server 2008

Цель лекции: показать основные элементы структуры современной СУБД (архитектуры базы данных и структуры программного обеспечения) на примере Microsoft SQL Server 2008 .

10.1 Общая структура СУБД

Для лучшего понимания принципов работы современных СУБД рассмотрим структуру одной из наиболее распространенных клиент-серверных СУБД — Microsoft SQL Server 2008 . Несмотря на то, что каждая коммерческая СУБД имеет свои отличительные особенности, информации о том, как устроена какая-то из СУБД , обычно бывает достаточно для быстрого первоначального освоения другой СУБД . Краткий обзор возможностей Microsoft SQL Server — 2008 был приведен в разделе, посвященном краткому обзору современных СУБД . В данном разделе рассмотрим основные моменты, связанные со структурой соответствующей СУБД (архитектурой базы данных и структурой программного обеспечения).

Под архитектурой (структурой) базы данных конкретной СУБД будем понимать основные модели представления данных, используемые в соответствующей СУБД а также взаимосвязи между этими моделями.

Читать еще:  Архитектура mcs 51

В соответствии с рассмотренными в «Различные архитектурные решения, используемые при реализации многопользовательских СУБД. Краткий обзор СУБД» различными уровнями описания данных различают разные уровни абстракции архитектуры базы данных .

Логический уровень (уровень модели данных СУБД) — средство представления концептуальной модели. Здесь каждая СУБД имеет некоторые отличия, но они являются не очень значительными. Отметим, что у разных СУБД существенно отличаются механизмы перехода от логического к физическому уровню представления.

Физический уровень (внутреннее представление данных в памяти ЭВМ — физическая структура базы данных). Данный уровень рассмотрения подразумевает изучение базы данных на уровне файлов, хранящихся на жестком диске. Структура этих файлов – особенность каждой конкретной СУБД , в т.ч. и Microsoft SQL Server .

10.2. Архитектура базы данных. Логический уровень

Рассмотрим логический уровень представления базы данных (http://msdn.microsoft.com). Microsoft SQL Server 2008 представляет собой реляционную СУБД (данные представляются в виде таблиц). Таким образом, основной структурой модели данных этой СУБД являются таблицы.

Таблицы и типы данных

Таблицы содержат данные о всех сущностях концептуальной модели базы данных. При описании каждого столбца (поля) пользователь должен определить тип соответствующих данных. Microsoft SQL Server 2008 поддерживает как уже ставшие традиционными типы данных (символьная строка с разным представлением, число с плавающей точкой длиной 8 или 4 байта, целое число длины 2 или 4 байта, дата и время, поле примечаний, булево значение и т. д.), так и новые типы данных. Кроме этого Microsoft SQL Server 2008 предоставляет специальный аппарат для создания пользовательских типов данных .

Рассмотрим краткую характеристику некоторых новых типов данных, значительно расширяющих возможности пользователя (http://www.oszone.net).

Тип данных hierarchyid

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

Пространственные типы данных

Пространственные данные – это данные, определяющие географические расположения и формы, преимущественно на Земле. Это могут быть ориентиры, дороги и даже расположение фирмы. В SQL Server 2008 есть географические (geography) и геометрические ( geometry ) типы данных для работы с этой информацией. Тип данных geography работает с информацией для шарообразной земли. Модель шарообразной земли использует при расчетах кривизну земной поверхности. Информация о положении задается широтой и долготой. Эта модель хорошо годится для приложений, связанных с морскими перевозками, военным планированием и краткосрочными приложениями, имеющими привязку к земной поверхности. Эту модель нужно использовать, если данные хранятся в виде широт и долгот.

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

Типы geography и geometry создаются из векторных объектов, заданных в форматах Well-Known Text (WKT) или Well-Known Binary (WKB). Это форматы для перенесения пространственных данных, описанные в простых функциях открытого геопространственного консорциума (Open Geospatial Consortium ( OGC ) Simple Features) для спецификаций SQL (SQL Specification).

Ключи

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

Кроме таблиц, в модель данных Microsoft SQL Server 2008 входит еще целый ряд компонентов. Дадим краткую характеристику основным из них.

Индексы

В «Использование формального аппарата для оптимизации схем отношений» рассматривалось понятие индекса. Здесь понятие индекса вынесено на логический уровень для удобства пользователя. Индексы создаются для ускорения поиска нужной информации и содержат информацию об упорядоченности данных по различным критериям. Индексирование может быть выполнено по одному или нескольким столбцам. Индексирование может быть произведено в любой момент. Индекс содержит ключи, построенные из одного или нескольких столбцов в таблице или представлении. Эти ключи хранятся в виде структуры сбалансированного дерева , которая поддерживает быстрый поиск строк по их ключевым значениям в SQL Server.

Представления

Представление — это виртуальная таблица, содержимое которой определяется запросом. Представление формируется на основе SQL-запроса SELECT, формируемого по обычным правилам. Таким образом, представление есть поименованный запрос SELECT.

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

Сборки

Сборки являются файлами динамической библиотеки, которые используются в экземпляре SQL Server для развертывания функций, хранимых процедур, триггеров, определяемых пользователем статистических вычислений и определяемых пользователем типов.

Ограничения

Ограничения позволяют задать метод, с помощью которого компонент СУБД Database Engine автоматически обеспечивает целостность базы данных. Ограничения задают правила допустимости определенных значений в столбцах и представляют собой стандартный механизм обеспечения целостности. Рекомендуется использовать ограничения, а не триггеры , правила и значения по умолчанию. Оптимизатор запросов также использует определения ограничений для построения высокопроизводительных планов выполнения запросов.

Правила

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

Значения по умолчанию

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

SPBDEV Blog

В предыдущей статье мы говорили о том, какое значение стали играть системы Business Intelligence (BI) для топ-менеджеров, чтобы оптимизировать использование ресурсов, а также оставаться конкурентоспособными.

Мы также говорили о пользователях BI и о том, как BI относится к хранению данных и бизнес-аналитике. В этой статье мы попробуем разобраться, чем Business Intelligence отличается от OLTP-систем организации, как выглядит типичная архитектура системы BI, а также различные компоненты архитектуры системы Business Intelligence.

Что такое OLAP и как она отличается от OLTP?

Предполагается, что системы OLTP (OnLine Transaction Processing) отслеживают и записывают транзакции в режиме реального времени и предназначены для автоматизации процесса ввода данных канцелярских данных или поиска данных для функциональных областей. Эта система позволяет пользователям добавлять, изменять, удалять и просматривать данные в базе данных OLTP, используя интерфейс пользователя.

В свою очередь, системы OLAP (OnLine Analytical Processing — интерактивная аналитическая обработка) являются ядром систем Business Intelligence и должны позволить пользователю быстро анализировать огромное количество информации, которая была объединена в многомерные представления и иерархии. Инструменты OLAP используются для проведения анализа тенденций по обобщенным данным; например, анализ агрегированных продаж и финансовой информации на ежегодной основе. Инструменты OLAP позволяют бизнес-пользователям легко и выборочно извлекать и просматривать данные с разных точек зрения или размеров, таких как время, география, пол, продукт и т. д. Вот некоторые из запросов, на которые можно своевременно получить ответы из систем OLAP:

  1. Какой регион обеспечивает высокий уровень доходов для организации?
  2. Какой магазин в этом конкретном регионе несет наибольшую ответственность за доходы?
  3. Какие продукты или категории продуктов в наибольшей степени приносят доход?
  4. Какой клиентский сегмент какой продукт использует или какой продукт популярен среди группы клиентов?

Вы можете возразить, что ответы на эти вопросы также могут быть получены из баз данных OLTP; зачем же тогда нужна система OLAP? В какой-то степени вы действительно вы можете ответить на эти вопросы при помощи системы OLTP, но это не лучшее решение. Обычно такие типы запросов основаны на большом наборе данных. Кроме того, для получения результата потребуется больше времени, и эти типы запросов негативно скажутся на производительности всей OLTP-системы. Помните, что OLTP-системы предназначены для обработки транзакций, что может повлиять на несколько записей, тогда как OLAP-системы основаны на аналитической обработке, что может повлиять на тысячи и миллионы записей. Имейте в виду, что платформа BI предварительно вычисляет или суммирует агрегаты, то есть суммирует продажи в год, поэтому, когда вы запускаете запрос для получения общих продаж в год, запрос просто предоставляет данные из агрегатов и не требует вычисления каждого значения. Но это не значит, что вам нужны системы OLAP для всех типов отчетов; для оперативной отчетности вы можете использовать OLTP-системы.

Типичная архитектура системы BI, основанная на платформе Microsoft SQL Server и Business Intelligence

Когда мы говорим о разработке системы BI, это подразумевает планирование, проектирование и разработку следующих компонентов:

Интеграция данных или ETL (извлечение, преобразование и загрузка)

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

Ваша система BI может использовать SSIS (служба интеграции SQL Server) — компонент платформы SQL Server, позволяющий интегрировать данные в хранилище данных. SSIS обеспечивает возможность согласованного и централизованного представления данных из разных исходных систем и помогает обеспечить достоверность данных посредством интеграции, очистки, профилирования и управления. SSIS обладает быстрой и гибкой базой ETL и возможностями преобразования памяти для очень быстрых сценариев интеграции данных. SSIS имеет несколько встроенных компонентов для подключения к стандартным гетерогенным источникам данных (RDBMS, FTP, Web Services, XML, CSV, EXCEL и прочее), а также богатый набор компонентов преобразования для интеграции данных. Помимо того, SSIS включает DQS (службы качества данных) для очистки данных, сопоставления и профилирования. Еще одним компонентом SQL является MDS. Он предоставляет платформу Master Data Management для централизованного управления основными данными организации.

Пакеты SSIS могут быть разработаны с использованием Business Intelligence Development Studio (BIDS) в SQL Server 2008 R2 и более ранних версиях (SSIS доступен из SQL Server 2005) или SQL Server Data Tool (SSDT) в SQL Server 2012 и могут быть сконфигурированы в процессе выполнения, основываясь на метаданных, хранящихся в репозитории метаданных. Существует несколько способов развертывания пакета служб SSIS, а в SQL Server 2012 введена еще более надежная модель развертывания пакетов.

Читать еще:  Виды архитектуры сетей

Анализ. После того, как вы закончите создание хранилища данных и компонентов интеграции данных для их загрузки в хранилище данных, вам нужно создать многомерную структуру OLAP. Система Business Intelligence может использовать SSAS (службу анализа SQL Server) для предоставления данных для аналитики и отчетности. SSAS — ведущий инструмент OLAP, обеспечивающий интерактивную аналитическую обработку и функции интеллектуального анализа данных для приложений бизнес-аналитики. SSAS предварительно вычисляет, суммирует и сохраняет данные в сильно сжатой форме, что в конечном итоге делает отчетный и предсказательный анализ чрезвычайно быстрым и интерактивным исследованием агрегированных данных с разных точек зрения.

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

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

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

Службы отчетов SQL Server (SSRS) позволяют создавать отформатированные и интерактивные отчеты с параметрами или без них. SSRS также обладает масштабируемыми возможностями распределения и планирования для автоматической доставки отчетов. Вы можете создавать табличные отчеты, а также различные варианты отчетов в виде диаграмм и графиках, карт или географических отчетов. Кроме того, также могут быть созданы отчеты о показателях на основе KPI.

PowerPivot, Power View, службы Excel и SSRS предоставляют пользователям возможность устанавливать и осуществлять специальные отчеты из стандартной модели данных. Благодаря кубу SSAS пользователи могут свободно анализировать отчеты на основе открытых размеров и измерений. Пользователи также имеют доступ к самым нормализованным данным и имеют возможность детализировать данные для анализа “вдоль и поперек”.

PowerPivot, Power View, Excel обеспечивают быстрое исследование, визуализацию и презентацию данных для пользователей всех типов — от бизнес-руководителей до информационных работников. Он позволяет пользователям изучить данные с разных сторон, используя диаграммы, графики, детализацию и т. д.

Платформа для совместной работы и хостинга. Вы можете использовать SharePoint 2010 или 2013 как платформу для сотрудничества, размещения и совместного использования данных; все отчеты и информационные панели будут развернуты или размещены на портале SharePoint. SharePoint является одним из ведущих продуктов для управления корпоративным контентом и обеспечивает возможности совместной работы, социальных сетей, корпоративного поиска, BI и прочее.

Не обязательно иметь SharePoint в качестве пользовательского интерфейса для отчетов, вы можете успешно получать отчеты SSRS, развернутые на сервере отчетов. Тем не менее, рекомендуется использовать SharePoint в качестве платформы хостинга, поскольку она дает вам несколько других функций, таких как службы Performance Point — для создания привлекательных панелей мониторинга, которые обеспечивают анализ данных “вглубь”, детализацию и разложения данных. Кроме того, службы Excel и PowerPivot могут использоваться для развертывания Excel или PowerPivot для SharePoint, чтобы сделать его доступным для других людей, превратив личную BI в организационную.

Для обеспечения безопасности вы можете использовать SharePoint встроенную в функции безопасности, которые обеспечивают безопасность на основе ролей. SSAS также позволяет определять безопасность на основе ролей, а также безопасность на уровне ячейки. Эти уровни безопасности будут регулировать доступ к данным и обеспечить соответствующий доступ к нужной информации в нужное время.

Microsoft SQL Server 6.5. Обзор основных возможностей

Введение

Коль скоро нынешний номер журнала посвящен серверам баз данных, невозможно не упомянуть о том, что создание машин для хранения и управления данными является, пожалуй, одним из самых значимых достижений человечества со времени изобретения письменности. Как известно, в начале было слово. Слово, ознаменовавшее переход от рефлексии в восприятии окружающего мира к абстрактному мышлению. Возможно, именно этот переворот в сознании нарушил первозданную гармонию и противопоставил человека природе. Как бы то ни было, при всей ограниченности и имманентной неполноте вербального общения именно слово служит основным способом передачи информации по сравнению, например, с музыкой, танцем, живописью, архитектурой и т. д. В рамках той парадигмы, в которой сегодня работает наш мозг, представляется иррациональной возможность просветления, озарения, т. е. мгновенного получения необходимых знаний. Остается процесс постепенного познания действительности, и для этого человек вынужден был научиться сохранять информацию, полученную на предыдущих этапах. Ключевым моментом стало возникновение знакового письма, которое, несмотря на большие или меньшие потери, смогло обеспечить должное хранение формализованных знаний. Как утверждают антропологи, за последние несколько десятков тысяч лет физиологические параметры homo sapiens практически не изменились — образно говоря, мы не стали лучше думать или глубже чувствовать. Единственное, что отличает современного человека от его предшественников — это объем накопленной информации и усовершенствованные способы ее обработки. Именно владение информацией обеспечило прогресс человеческого общества, позволив каждому последующему поколению опереться на объем знаний и опыта, собранный предшественниками, и в общем случае не изобретать заново велосипед.

Нелинейный рост во времени совокупной базы знаний цивилизации вызвал к жизни прогрессирующую эволюцию средств хранения, обработки и представления информации как инструментов умножения ее интеллектуальной мощи. В этом ряду применение последних достижений в области компьютерных технологий сравнимо по степени важности с изобретением печатного станка или даже его превосходит. Наблюдается и обратная зависимость: чем более изощренные средства используются для обработки информации, чем быстрее растут ее объемы, тем большее значение она приобретает практически во всех аспектах человеческой деятельности, в частности в экономике. Роль информации, как товара или предмета труда, носит совершенно особый характер. Информация сравнительно легко копируется без ущерба для своих потребительских свойств. В отличие, например, от тонны нефти, одна и та же информация может быть потреблена неоднократно, в том числе одновременно различными участниками товарных отношений. Все мы еще с уроков обществоведения усвоили, что труд является основным источником создания материальных благ. Однако даже у авторов учения о прибавочной стоимости можно встретить мысль о том, что по мере развития науки главная доля прироста общественного благосостояния будет обуславливаться ускоренными темпами обновления основного капитала в силу роста технического прогресса. Многие современные западные экономисты склонны считать, что человечество вступило в постиндустриальный период своего развития, основным средством производства в котором будет выступать информация и по отношениям собственности на которую в обществе уже начал определяться новый правящий класс — когнитариат. Можно принимать или оспаривать эти выводы, очевидно одно — в деятельности современного предприятия информация становится одним из важнейших производственных ресурсов, выделяясь в самостоятельный фактор успешного бизнеса из традиционных составляющих, таких как кадры, клиенты, каналы сбыта, технологии. Наконец, информация не может потребляться непосредственно: например, чтобы усвоить текст, нужно, как минимум, уметь читать. Отсюда с ростом значения информации возрастает роль средств ее обработки. Если зачастую стоимость информационной базы корпорации оказывается выше производимой ею продукции и услуг, если информация — это всегда деньги (и в общем-то немалые), то неудивительно, что рынок СУБД на сегодня оценивается в десятки миллиардов долларов.

Хотя предки нынешних СУБД существовали на мэйнфреймах еще до появления в 1969 г. знаменитой статьи Э. Кодда, положившей начало теории реляционных баз данных, их поистине массовое распространение и беспрецедентный рост популярности обеспечили «настольные» варианты одновременно с мировой экспансией персональных компьютеров. Однако требования корпоративного доступа к ресурсам и появление локальных вычислительных сетей на базе ПК привели к созданию наиболее многочисленных на сегодня решений на базе технологии «клиент-сервер». В последнее время необходимость поддержки мультимедийных проектов (изображений, видео, звука) и работы с другими видами неструктурированной бизнес-информации (временные ряды, географические карты) вызвала к жизни внедрение объектной идеологии в старые добрые реляционные базы независимо от того, достигалось ли это полным переписыванием ядра или интеграцией готовых реляционных и объектных баз данных. Классическую же в терминах реляционной теории СУБД, как известно, в первом приближении можно описать как комплекс из инструментария для поддержки таблиц и отношений между связанными таблицами, пользовательского интерфейса для ввода, поиска данных и их представления и высокоуровневых средств разработки приложений. Выделение в этой среде своеобразного исполнительного информационного центра, принимающего короткие запросы от клиентов, отыскивающего оптимальный путь их выполнения и передающего в ответ результирующие множества, приводит к разделению функций СУБД, часть из которых закрепляется за сервером, а часть — за клиентом. Традиционно на сервер возлагаются обязанности по оперативному исполнению транзакций, поддержке целостности данных, обеспечению безопасности хранения и доступа, обеспечению пользовательских соединений и соблюдению части логики приложения, большей или меньшей в зависимости от самого конкретного приложения. Естественно, самая минимальная часть серверной логики должна обеспечивать проектирование структурной схемы базы вместе с соответствующими ограничениями. На стороне клиента у нас, таким образом, остаются другая (как правило, все-таки меньшая) часть бизнес-логики приложения и пользовательский интерфейс. Исходя из всего сказанного выше о значении и цене информации в современном мире не будет большим преувеличением сказать, что в серверах баз данных (во всяком случае, для «большой шестерки») воплотились лучшие достижения в области информационных технологий. Microsoft SQL Server 6.5 является одним из наиболее стремительно развивающихся серверов баз данных на рынке корпоративных СУБД. Разумеется, в рамках данной статьи невозможно подробно остановиться на характеристиках этого продукта в той мере, в какой это хотелось бы сделать и какой он, безусловно, заслуживает. Поэтому мы ограничим нашу задачу рассмотрением хотя бы некоторых базовых возможностей Microsoft SQL Server 6.5 применительно к перечисленным выше функциям сервера баз данных.

Архитектура MS SQL Server 6.5

Симметричная мультипроцессорная архитектура MS SQL Server предусматривает использование «родных» сервисов операционной системы Windows NT для управления потоками (threads), памятью, операциями дискового чтения/записи, сетевыми службами, функциями безопасности, а также для поддержки параллельного выполнения потоков на нескольких CPU. Использование потоков Windows NT позволяет MS SQL Server автоматически масштабироваться при работе на многопроцессорных платформах, что исключает необходимость дополнительной конфигурации или программной настройки. Например, на Comdex была продемонстрирована работа MS SQL Server на платформе AlphaServer 8400 производства Digital, оснащенным 12 процессорами, 28 Гбайт памяти и 39-ти терабайтным хранилищем. В отличие от большинства распространенных СУБД, вынужденных иметь в своем составе механизмы дублирования ядра операционной системы для обеспечения кросс-платформенной переносимости, MS SQL Server обладает достаточно легковесной прозрачной архитектурой, не перетяжеленной несвойственными ей функциями. В результате, например, при смене типа процессора не требуется заново приобретать MS SQL Server для новой аппаратной платформы. Он ставится, по определению, на все, на чем работает Windows NT (на сегодня это Intel, Alpha, MIPS и PowerPC). По мере того как Windows NT завоевывает все большее признание и все ведущие производители СУБД уже выпустили версии своих продуктов под этой операционной системой или уже заявили о своей готовности это сделать в ближайшее время, изначальная ориентированность MS SQL Server 6.5 на тесную интеграцию с Windows NT выступает в качестве одного из серьезных преимуществ.

Читать еще:  Сетевая архитектура это

На каждое пользовательское соединение в MS SQL Server назначается отдельный рабочий поток (порядка 55К) в рамках единого серверного процесса. Так как каждый из этих потоков в действительности является потоком Win32, на них распространяются соответствующие функции контроля операционной системы, включая защиту памяти, правила доступа к оборудованию и планирование выполнения потоков во времени (thread scheduling). Это предоставляет улучшенные способности к масштабированию при росте числа одновременно работающих пользователей, динамическую балансировку при загрузке процессоров и повышенную надежность, так как пользовательские запросы, исполняющиеся на разных потоках, защищены друг от друга. Несмотря на то что пул соединений ограничен 1024 потоками, динамическое управление пользовательскими соединениями и свободными потоками позволяет увеличить эту величину до 32 767. Кроме этого, другие пулы потоков могут использоваться для параллельного выполнения операций сканирования данных, удаления и обновления, резервного копирования, проверки целостности базы, индексирования, асинхронного опережающего чтения данных в кэш на основе алгоритмов предсказания, создания и управления курсорами и т. д.

Сетевые службы Windows NT обеспечивают MS SQL Server поддержку протоколов TCP/IP, NWLink IPX/SPX, Named Pipes (NetBEUI), Banyan Vines, AppleTalk (ADSP) и DECNet. В версии 6.5 к ним добавилась дополнительная сетевая библиотека — multiprotocol network library, которая «умеет слушать» порты TCP/IP, сокеты SPX или поименованные каналы (named pipes), которые обычно выбираются динамически. Несомненным достоинством multiprotocol является наличие сетевого сервиса, обеспечивающего взаимодействие между процессами при помощи вызовов удаленных процедур, что позволяет, например, использовать шифрование при передаче данных.

Производительность

Многопоточное ядро и интеграция со службами планирования потоков Windows NT обеспечивает высокую производительность MS SQL Server при обработке OLTP- и DSS-запросов, что особенно заметно при одновременной работе нескольких сотен пользователей. В опубликованных результатах по тестированию MS SQL Server 6.5 на максимальное число одновременно работающих пользователей приводится цифра 3500, хотя известны реально работающие приложения, где нагрузка доходила до 5000 одновременных пользовательских соединений. За период с октября 1995 г. по декабрь 1996 г. производительность MS SQL Server, измеренная по тестам TPC-C (см. http://www.tpc.org), выросла с 2454 до 7521 транзакции в минуту, т. е. более чем в 3 раза. Для сравнения заметим, что ежедневный объем транзакций в расчетной системе VISA составляет от 10 до 40 млн. Темп 7,5 тыс. транзакций в минуту означает, что один MS SQL Server способен при режиме работы 24х7 обслужить немногим менее 11 млн. транзакций в сутки. Существует еще один параметр, тесно связанный с производительностью, который, не являясь в строгом смысле слова техническим, очень популярен на Западе при оценке возможностей того или иного сервера баз данных, так как от него существенно зависит стоимость владения продуктом (cost of ownership). Речь идет об удельной цене за транзакцию в минуту, иными словами, сколько придется заплатить за достижение такой скорости обработки запроса. За тот же самый период, в течение которого мы рассматривали рост производительности, показатель «цена/производительность» снизился с 242 до 65 долл. за транзакцию в минуту, что говорит о разумной стоимости систем на базе MS SQL Server при высоких требованиях к скорости обработки.

Распределенная среда управления

В состав MS SQL Server 6.5 входит свыше 20 графических средств управления и утилит командной строки, которые кратко охарактеризованы в табл. 1.

Архитектура системы безопасности MS SQL Server

Дата добавления: 2013-12-23 ; просмотров: 2778 ; Нарушение авторских прав

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

Чтобы разрешить этим пользователям обращаться к серверу, создайте для них учетные записи в SQL Server либо предоставьте им доступ посредством учетных записей в домене, если вы используете систему безопасности Windows. Разрешение доступа к серверу не дает автоматически доступа к базе данных и ее объектам.

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

Полный доступ к базе данных и всем ее объектам имеет администратор, который является своего рода хозяином базы данных — ему позволено все.

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

Третья категория пользователей имеет права доступа, выданные им администратором или владельцем объекта.

Учетные записи и пользователи

Система безопасности SQL Server 2000 и выше базируется на учетных записях (имена входа) и пользователях.

Рис. 1. Учетные записи (мена входа) определяются на уровне сервера

Рис. 2. Пользователи определяются для БД

Пользователи проходят следующие два этапа проверки системой безопасности. На первом этапе пользователь идентифицируется по имени учетной записи и паролю, то есть проходит аутентификацию.

Если данные введены правильно, пользователь подключается к SQL Server. Подключение к SQL Server, или регистрация, не дает автоматического доступа к базам данных. Для каждой базы данных сервера регистрационное имя (или учетная запись — login) должно отображаться в имя пользователя базы данных (user).

На втором этапе, на основе прав, выданных пользователю как пользователю базы данных (user), его регистрационное имя (login) получает доступ к соответствующей базе данных. В разных базах данных login одного и того же пользователя может иметь одинаковые или разные имена user с разными правами доступа.

Для доступа приложений к базам данных им также понадобятся права. Чаще всего приложениям выдаются те же права, которые предоставлены пользователям, запускающим эти приложения. Однако для работы некоторых приложений необходимо иметь фиксированный набор прав доступа, не зависящих от прав доступа пользователя. SQL Server 2000 позволяет предоставить такие с применением специальных ролей приложения.

Рис. 3. Роли приложений

Итак, на уровне сервера система безопасности оперирует следующими понятиями:

— учетная запись (login);

— встроенные роли сервера (fixed server roles).

На уровне базы данных используются следующие понятия:

— пользователь базы данных (database user);

— фиксированная роль базы данных (fixed database role);

— пользовательская роль базы данных (users database role);

— роль приложения (application role).

SQL Server 2000 может использовать два режима аутентификации пользователей:

— режим аутентификации средствами Windows;

— смешанный режим аутентификации (Windows Authentication and SQL Server Authentication).

Смешанный режим позволяет пользователям регистрироваться как средствами Windows, так и средствами SQL Server. Кроме того, этот режим предлагает некоторые удобства по сравнению с первым. В частности, при аутентификации только средствами домена Windows, если пользователь не имеет учетной записи в домене Windows, то он не сможет получить доступа к серверу баз данных. Смешанный режим аутентификации позволяет избежать этой проблемы.

При выборе режима аутентификации следует исходить как из требований обеспечения наибольшей безопасности, так и из соображений простоты администрирования. Если ваша организация небольшая и должности администратора сети и администратора баз данных совмещает один человек, то удобнее использовать аутентификацию Windows. Если же в организации сотни пользователей и функции системного администратора и администратора баз данных выполняют различные люди, то может оказаться, что аутентификация средствами SQL Server удобнее. В противном случае человеку, занимающемуся администрированием сервера баз данных, придется постоянно обращаться к системному администратору для создания нового пользователя, смены пароля или для перевода пользователя из одной группы в другую. К тому же системный администратор будет иметь возможность назначать права доступа по своему усмотрению, а это совсем ни к чему.

С другой стороны, каждый пользователь организации, скорее всего, имеет в домене учетную запись, администрированием которой занимается системный администратор. Благодаря аутентификации Windows администратор баз данных может использовать уже готовые учетные записи, а не отвлекаться на создание новых.

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

Рис. 4. Выбор режима аутентификации

После того как клиент успешно прошел аутентификацию, он получает доступ к SQL Server. Для получения доступа к любой базе данных учетная запись пользователя (login) отображается в пользователя данной базы данных (user). Объект «пользователь базы данных» применяется для предоставления доступа ко всем объектам базы данных: таблицам, представлениям, хранимым процедурам и т.д. В пользователя базы данных может отображаться:

— учетная запись Windows;

— учетная запись SQL Server.

Подобное отображение учетной записи необходимо для каждой базы данных, доступ к которой хочет получить пользователь. Отображения сохраняются в системной таблице sysusers, которая имеется в любой базе данных. Такой подход обеспечивает высокую степень безопасности, предохраняя от предоставления пользователям, получившим доступ к SQL Server, автоматического доступа ко всем базам данных и их объектам.

Пользователи баз данных, в свою очередь, могут объединяться в группы и роли для упрощения управлением системой безопасности.

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

Если в сети имеется небольшое количество пользователей, то достаточно легко предоставить доступ каждому пользователю персонально. Однако в больших сетях с сотнями пользователей подобный подход займет много времени. Гораздо более удобным и эффективным является подход, когда доступ к SQL Server предоставляется целым группам пользователей. Как раз такой подход возможен при аутентификации средствами Windows, когда на уровне домена создается несколько групп, каждая из которых предназначена для решения специфических задач. На уровне SQL Server такой группе разрешается доступ к серверу, предоставляются необходимые права доступа к базам данных и их объектам. Достаточно включить учетную запись Windows в одну из групп, и пользователь получит все права доступа, предоставленные этой группе. Более того, одна и та же учетная запись может быть включена во множество групп Windows, что даст этой учетной записи возможность пользоваться правами доступа, предоставленными всем этим группам.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×