Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для высших учебных заведений (6-е изд.) - 2009

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

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

A.Правило «пяти минут». Соотношение цен основной и дисковой памяти таково, что экономически целесообразно кэшировать данные, обращения к которым происходят более одного раза каждые пять минут. Для определения размера кэша нужно сначала на уровне всей системы сложить объемы всех данных, которые приложения предполагают использовать более часто, чем один раз в пять минут. Дополнительно следует зарезервировать еще 5-10% от суммарного объема данных для хранения индексов, хранимых процедур и другой управляющей информации СУБД. Правило широко используется при конфигурировании серверов баз данных, для которых точное определение размера кэша затруднительно.

B.Правило «90/10». Исследования современных БД показывают, что 90% всех обращений выполняются к 10% данных («горячие» данные). Более того, обращения к «горячим» данным, в свою очередь, тоже подчиняются правилу «90/10». Таким образом, около 80% всех обращений к данным связаны с доступом к примерно 1% данных. Отсюда следует, что для кэша требуется объем основной памяти не менее 1% от «чистого» объема хранимых данных, не считая памяти под индексы и другую служебную информацию.

Правило применимо для больших баз данных, когда 10% общего объема базы данных принципиально невозможно или дорого разместить в кэше. Так, для скромных по сегодняшним меркам баз данных объемом 5 Гбайтов 10% составляет 500 Мбайтов. Сконфигурировать машину класса Pentium с таким объемом кэша пока проблематично и дорого. Обеспечить кэш объемом

в1% всех данных и для очень больших баз данных - вполне реально.

C. По числу пользователей. Грубой оценкой требуемого объема основной памяти под кэш является величина, получающаяся при выделении от 50 до 300 кбайтов на каждого пользователя. Правило целесообразно применять для

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

Замечания.

•Чрезмерное увеличение размера кэша обычно не дает существенного эффекта. Более того, эффект может оказаться обратным: система станет работать медленнее. Причиной этого может быть лишение пользовательского приложения или сервера СУБД требуемой для нормальной работы основной памяти.

•Выделение памяти под кэш может уменьшить размер виртуальной памяти, используемой операционной системой для буферизации операций файловой системы.

•В системе должно обеспечиваться пространство для традиционного использования памяти. Так, в вычислительных системах под управлением UNIX желательно иметь объем основной памяти не менее 16 Мбайтов для операционной системы, 2-4 Мбайта — для ряда программ СУБД и достаточно места для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1 - 2 Мбайта, но иногда они могут достигать десятков Мбайтов. Поскольку операционная система обеспечивает разделение памяти между множеством процессов, достаточно зарезервировать пространство для одного приложения.

•Для современных серверных систем существует также следующее эмпирическое правило: неразумно комплектовать машину памятью менее чем примерно по 64 Мбайтов на процессор. В противном случае в систе-

ме возникает интенсивная фрагментация памяти.

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

Так, результаты теста ТРС-А для восьмипроцессорного SPARCserver 1000 показывают, что он способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. Этот результат достигнут путем тщательной настройки ОС Solaris, СУБД Oracle и самого теста. Для большинства пользователей более реалистической верхней границей числа пользователей па процессор для транзакций типа ТРС-А возможно составит порядка 100-200 пользователей на один процессор 50 МГц SuperSPARC.

Дисковая система ввода/вывода. Как известно, любое обновление базы данных связано с обновлением индексов и с выполнением записи в журнал. Каждая из этих операций может вызывать последовательное и/или произвольное обращение к дисковой памяти. Примером последовательного обра-

ного просмотра) или частичного сканирования индексов (отсортированных) перед обращением к записям индексированной БД.

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

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

На производительность дисковой подсистемы ввода/вывода большое влияние оказывает количество и вид используемых системных шин. Различные шины поддерживают работу разного количества дисков. Так, на одной шине Fast SCSI-2 (10 Мб/с) можно сконфигурировать небольшое число дисков (3-5), а на шине Fast-and-Wide SCSI (20 Мб/с) - до 8 - 1 0 дисков.

Помимо характеристик емкости МД и пропускной способности шин, на производительность подсистемы ввода/вывода большое влияние оказывает уровень загруженности этих компонентов. Практика показывает, что в случае пиковых нагрузок степень загруженности шины должна поддерживаться на уровне 40%, а степень загрузки дисков — на уровне 60%.

Многопроцессорные системы обработки баз данных

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

•хранение и обработка информации в оперативной памяти компьютера; •выполнение запросов в многопроцессорных и многомашинных вычис-

лительных системах с различными архитектурами;

•эффективная реализация типовых операций в БД (сортировка, поиск, реорганизация, пакетная загрузка/выгрузка и пр.);

•восстановление данных в случае отказа узлов вычислительной системы и т. д. Одними из основных параметров систем, использующих БД, являются

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

Фирмы, разрабатывающие СУБД, для улучшения названных характеристик использовали следующие варианты аппаратных средств:

1.Традиционные однопроцессорные ЭВМ повышенной производительности.

2.Специализированные процессоры баз данных - машины баз данных.

3.Вычислительные системы на базе многопроцессорных структур.

Несмотря на широкое распространение систем первого типа, в настоящее время лучшие результаты показывают системы третьего типа. Примерами параллельных систем баз данных являются Teradata, Tandem, Gamma, Bubba и Arbre. Рассмотрим более подробно многопроцессорные вычислительные системы, предварительно дав определение эффективности.

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

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

•высокой производительности вычислительной системы;

•значительного объема БД в сотни мегабайтов и терабайтов;

•решения в реальном масштабе времени;

•одновременной обработки разнородных подзадач (массовый ввод и модификация данных, поддержка принятия решения, пакетная обработка);

•одновременного обслуживания большого числа запросов.

Анализ перечисленных требований показывает, что обеспечить их, ограничившись универсальной однопроцессорной вычислительной системой или специализированным средством с аппаратной реализацией часто выполняемых операций, весьма (ложно. Примером уникальной вычислительной системы, которая в некоторой степени могла бы удовлетворить предъявляемым требованиям, можно считать суперкомпьютер баз данных (Super Database Computer - SDC) токийского университета. В нем используется комбинированный аппаратно-программный подход к решению проблемы производительности. Основное обрабатывающее устройство из одного или нескольких процессоров с совместно используемой памятью дополняется специализированным устройством сортировки и дисковой подсистемой.

Более перспективными с точки зрения удовлетворения перечисленным выше требованиям оказываются многопроцессорные вычислительных системы.

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

К сильно связанным вычислительным системам, или системам с разделением ресурсов, относятся следующие:

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

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

Достичь высоких временных показателей обработки данных в слабосвязанных вычислительных системах удается благодаря использованию реляционной модели. Реляционный запрос хорошо подходит к параллельному выполнению: из операторов над отношениями можно составить параллель-

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

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

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

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

ит. д.).

Вреализации параллельных систем баз данных имеются следующие нерешенные проблемы:

• обеспечение высоких временных характеристик при смешанной нагрузке;

•оптимизация параллельных запросов;

•выбор оптимальных методов физического проектирования баз данных (разделение данных, выбор индексов для таблиц и т. д.);

•разработка методов и средств реорганизации данных в режиме on-line;

•исследование алгоритмов конвейеризации и т. д.

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

9.2. Перспективы развития СУБД

Анализ современных СУБД и реализованных на их основе приложений позволяет предположить следующие направления их развития:

1) поиск более совершенных моделей представления и типов данных

вбазах;

2)разработка новых архитектур СУБД;

3)расширение областей применения БД;

4)улучшение сервиса конечных пользователей, администраторов и разработчиков.

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

гиперссылка.

Новые архитектуры СУБД. Современные информационные системы в ряде случаев требуют от СУБД возможности хранить и обрабатывать данные объемом порядка Петабайтов (Petabyte - 1013 байтов). Несмотря на значительный рост возможностей по объему магнитных и магнитоопти-

260 Часть 2. Проектирование и использование БД

ческих дисков, вряд ли их будет достаточно для информационных систем, работающих со сверхбольшими объемами данных. В связи с этим говорят о необходимости организации нового уровня иерархии носителей - «третичной памяти». Устройствами третичной памяти могут быть устройства в виде стоек магнитных дисков или лент с автоматически сменяемыми носителями.

Примером такого устройства является буферная система VSM (Virtual Storage Manager - менеджер виртуальной памяти) корпорации StorageTek. Система VSM накапливает данные и сохраняет их на жестких дисках в буфере данных, где они складируются в виде виртуальных томов на магнитных лентах (до 100 ООО виртуальных томов на каждом дисковом буфере). Максимальная скорость передачи данных пользователя - до 45 Мбайтов/с.

Еще одним примером является система CD Storage System корпорации Compaq Computer. Она предоставляет сетевым пользователям доступ к данным на компакт-дисках, размещенных в корпусе фирмы Micro Design International. Всего может быть до семи блоков (корпусов), каждый из которых вмещает по семь приводов компакт-дисков. Объем памяти каждого блока - до 4,5 Гбайтов. Можно установить до 49 дисководов на сервер и управлять ими как одним логическим диском.

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

Примером системы, решающей одну из задач первого класса, является проектируемая информационная система наблюдения Земли EOS (Earth Observing System), основным элементом которой является база данных EOSD1S (EOS Data and Information System - система данных и информации).

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

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

Осознание необходимости хранения в базах данных не только информации о предметной области, но и информации разработчиков приложений привела к тому, что некоторые крупные фирмы (Oracle, Microsoft) заявили о

скором появлении программных продуктов управления метаданными - объектно-ориентированных репозиториях. Такие репозитории полезны администраторам БД в управлении метаданными, а также разработчикам, так как позволяют при разработке приложений многократно использовать готовые компоненты.

Одним из новых требований в области информационных технологий является обеспечение безостановочной работы. С одной стороны, возможности компьютеров, а с другой - конкуренция привели к тому, что некоторые информационные системы работают непрерывно. Появился так называемый «стандарт готовности», который определяется как возможность пользователя совершать интерактивное обновление данных 24 часа в сутки, 7 дней в неделю, 52 недели в год. Часто безостановочный режим работы называют «7*24-» или «24*365-работой». Это означает, что в каждый день года в любое время пользователю доступны информационные ресурсы, без скидок на выходные и праздничные дни.

Такой уровень качества прикладных систем, использующих БД, помимо мер повышения надежности и устойчивости непрерывной работы, выдвигает и новые требования к организации обслуживания систем. Раньше существовали «окна» ночного времени, в которых выполнялось резервное копирование, исправление ошибок, реорганизация БД, установка новых версий ПО, модернизация компьютера и ОС. Теперь это требуется делать в «горячем» режиме, совмещая с текущим обслуживанием пользователей. Решение этих задач требует новых подходов к организации вычислительных работ и управлению БД, при котором допустимо параллельное и бесконфликтное решение задач пользователей и администратора БД.

В современных условиях появляется потребность в обеспечении информационного обслуживания мобильного пользователя. Ранее типовой схемой ввода и обновления данных в базе являлся пакетный ввод информации и оперативный ввод с терминалов пользователей. Теперь нужно иметь возможность ведения БД как на центральной (стационарной) ВС, так и на портативном (переносном) компьютере. При этом необходимо иметь средства загрузки/выгрузки выбранных данных с центральной на портативную ЭВМ, а также средства обеспечения согласованности информации в обеих базах.

Определенные шаги в реализации такого рода услуг в некоторых СУБД уже сделаны. Так, в системе Access имеется средство репликации БД (подраздел 10.9). Другим примером реализации средства работы с БД мобильного пользователя является СУБД Oracle Lite (Oracle), функционирующая в карманных компьютерах с операционной системой Windows СЕ. Эта СУБД, называемая клиентской, обеспечивает доступ через сеть к данным и приложениям, поддерживаемым системой Oracle 8. Категорию пользователей, для которых разработана Oracle Lite, составляют менеджеры, руководители и спе-

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

9.3. Стандартизация баз данных

Необходимость стандартизации в области обработки данных осознана еще на этапе внедрения первых «массовых» СУБД. В настоящее время в индустрии информационных технологий работает более 250 подкомитетов официальных стандартизирующих организаций. Ими принято или находится в процессе разработки более 1000 стандартов. Рассмотрим характеристику стандартизации и наиболее распространенные стандарты для баз данных.

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

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

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