В течение 80-х годов поставщики мэйнфреймов и мини-компьютеров пытались решить задачу создания систем обработки транзакций на базе языка SQL, способных обрабатывать более 1000 транзакций в секунду.
В период с 1989 по 1992 годы по таким параметрам, как производительность и отношение стоимость/производительность, первенство принадлежало патентованным системам. В частности, лучшие показатели имели компьютеры VAX компании Digital и Cyclone/CLX компании Tandem. Наилучшая производительность компьютеров компании HP была зарегистрирована для ее продукта Allbase. В то же время линия изделий AS/400 компании IBM также имела впечатляющие параметры (существенно превосходящие соответствующие характеристики изделий серии RS/6000-AIX).Характерно, что компания IBM никогда не публиковала результаты тестирования системы DB2 на своих мэйнфреймах. Конечно, СУБД DB2 имела превосходную производительность (оценивавшуюся в сотнях транзакций в секунду), но она работала на дорогих мэйнфреймах. Вероятнее всего, IBM не хотела показывать неэкономичность своих мэйнфреймов путем публикации результатов контрольных испытаний на тесте TPC-A. Единственным поставщиком мэйнфреймов, рискнувшим опубликовать результаты тестирования, оказалась компания Unisys, система которой показала отношение стоимость/производительность примерно на уровне45 K$/tps. В то время этот показатель вдвое превышал соответствующие показатели ее конкурентов.
В период между 1989 и 1993 годами операционные системы (SCO Unix, NetWare, NT), системы управления базами данных (Oracle, Informix, Sybase, Ingres)и мониторы транзакций (Tuxedo, VIS/TP, Encina), которые сегодня смело можно отнести к разряду продуктов массового потребления, резко улучшили свою производительность при решении задач обработки простых транзакций.
В 1993 году комбинация продуктов Unix/ Oracle/ Tuxedo стала лидером по отношению стоимость/производительность. Oracle, Tuxedo и операционная система Dynix, работающие на многопроцессорной системе компании Sequent, построенной на базе процессоров Intel 486, были первыми, преодолевшими барьер 1 Ktps, который продержался более десятилетия. Чуть позже СУБД Rdb и Oracle преодолели этот барьер с несколько лучшим отношением стоимость/производительность при выполнении тестов на шестипроцессорной системе Alpha AXP компании Digital, работающей под управлением ОС VMS. Аналогичных результатов добились и компании HP и Sun. В 1994 году лидером по отношению стоимость/производительность оказалась комбинация продуктов Compaq/SCO Unix/Oracle. Системы компаний Digital, HP и Sun имели более высокую производительность, но и более дорогие решения.
Пиковая производительность систем и их стоимость в пересчете на одну транзакцию продолжают быстро улучшаться. В настоящее время лидерство по отношению стоимость/производительность принадлежит комбинации продуктов Compaq/ Windows NT/Microsoft SQL, хотя, как и прежде, системы компаний Digital, HP и Sun имеют более высокую производительность (см. таблицу 1).
Таблица 1.
Еще несколько лет назад о компьютерах, построенных на базе платформы Intel (например ПК совместимых системах компании Compaq), сравнивая их с системами компаний Digital, HP, IBM и Sun, можно было сказать, что в них отсутствует контроль четности в памяти или процессоре, что они используют сравнительно малонадежные диски, или что для них, например, отсутствует программное обеспечение для оперативной обработки транзакций (OLTP). Естественно, такие машины, попросту говоря, не были конкурентоспособными. Сегодня ситуация полностью изменилась. Компания Compaq является не только самым крупным в мире поставщиком серверов уровня рабочих групп, но и самым крупным поставщиком дисковых массивов уровня RAID-5. " Корпоративные " версии ее продуктов имеют мощные средства встроенной диагностики, удаленного обслуживания, интегрированные источники бесперебойного питания и даже некоторые средства резервирования узлов. Широкое распространение получают комбинации продуктов SCO-Unix/Tuxedo/Oracle, Novell NetWare/Oracle, Microsoft NT/Sybase и др.
К сожалению, эти системы массового применения в настоящее время все еще не имеют полностью отработанных средств кластеризации. Кластерные архитектуры дают возможность множеству процессоров обслуживать множество клиентов, обеспечивают единообразный программный интерфейс и интерфейс управления общими ресурсами. Средства кластеризации требуются, прежде всего, для построения действительно крупномасштабных систем, включающих десятки и сотни дисков и обслуживающих тысячи клиентов. Эти средства требуются также для построения систем высокой готовности. В случае отказа какого-либо устройства или процессора в кластере другие устройства автоматически переключаются и обеспечивают доступ к точной копии сервера или данных.
Еще два года назад наиболее отработанная технология кластеризации была ограничена операционной системой Guardian компании Tandem, системой DBC/1024компании Teradata и операционной системой VMS компании Digital. Однако уже в то время практически каждый крупный поставщик вычислительных систем предлагал свои средства кластеризации на базе операционных систем Unix и NT. Ожидалось, что для полного " созревания " соответствующего программного обеспечения потребуется несколько лет и что оно будет готовок концу 1996 - началу 1997 года.
Кроме того, оказалось, что новое программное обеспечение существенно проще использовать. На пример, комбинация продуктов NT/Sybase обеспечивает единообразный механизм доменов наименования и секретности, графический интерфейс для администрирования и работы, а также современные инструментальные средства разработки. Хранимые процедуры SQL, генераторы приложений типа PowerBuilder, SQLWindows, Windows 4GL и другие средства значительно упрощают построение TP-приложений клиент-сервер, поддерживающих более сотни пользователей на каждом сервере. Правда, масштабирование системы для обслуживания значительно большего числа пользователей требует разделения задачи на несколько меньших серверов или использования традиционных мониторов обработки транзакций типа Tuxedo, Encina, ACMSxp или CICS. Программное обеспечение для автоматизации построения подобного рода систем клиент-сервер может быть реализовано с помощью инструментальных средств типа Ellipse и Forte.
Таким образом, времена изменились. Полным ходом идет процесс перевода на массовую технологию систем, ранее базировавшихся на мэйнфреймах. Программное обеспечение массового потребления установило и новые точки отсчета в области ценообразования.
Системы управления базами данных (СУБД) являются одним из наиболее распространенных классов прикладных систем для серверов, выпускаемых большинством компаний-производителей компьютерной техники. Следует отметить, что приложения, ориентированные на использование баз данных, и сами СУБД сильно различаются по своей организации. Если системы на базе файловых серверов сравнительно просто разделить по типу рабочей нагрузки на два принципиально различных класса (с интенсивной обработкой атрибутов файлов и с интенсивной обработкой самих данных), то провести подобную классификацию среди приложений баз данных и СУБД просто невозможно. Стандартный язык реляционных СУБД (SQL) намного богаче, чем набор операций сетевой файловой системы.
На сегодня абсолютное большинство инсталлированных в мире систем реляционные, и эта архитектура выбрана такими производителями, как Oracle, Sybase, Ingres, Informix, Progress, Empress и dBase. ADABAS компании Software AG - иерархическая система, хотя может обрабатывать стандартный SQL. Но даже с учетом того, что подавляющее большинство систем работает по одной и той же концептуально общей схеме, между различными продуктами имеются большие архитектурные различия. Возможно, наиболее существенным из них является реализация самой СУБД.
Подробный анализ различных моделей СУБД уже проводился на страницах журнала СУБД (см., например, [4] стр. 125-142). Здесь отметим лишь, что можно выделить два основных класса систем: системы, построенные по принципу"2N" (или " один-к-одному "), и многопотоковые системы. В более старых 2N-реализациях для каждого клиента на сервере используется отдельный процесс, даже если программа-клиент физически выполняется на отдельной системе. Таким образом, для работы каждого клиентского приложения используются два процесса - один на сервере и один на клиентской системе. Многопотоковые приложения как раз и разработаны для того, чтобы существенно снизить дополнительные расходы на организацию управления таким большим количеством процессов. Обычно они предполагают наличие нескольких процессов(от одного до пяти), работающих на серверной системе. Эти процессы имеют внутреннюю многопотоковую организацию, что обеспечивает обслуживание запросов множества клиентов. Большинство основных поставщиков СУБД в настоящее время используют многопотоковую реализацию или двигаются в этом направлении.
В компьютерной индустрии термин " транзакция " (transaction)может означать почти любой вид взаимодействия или обмена информацией. Однако в мире бизнеса " транзакция " имеет вполне определенный смысл: коммерческий обмен товарами, услугами или деньгами. В настоящее время практически все бизнес-транзакции выполняются с помощью компьютеров. Наиболее характерными примерами систем обработки транзакций являются системы управления учетом, системы резервирования авиабилетов и банковские системы. Таким образом, необходимость стандартов и тестовых пакетов для оценки таких систем все больше усиливается. Чтобы решить эти проблемы, в 1988 году была создана организация TPC (Transaction Processing Performance Council), основной задачей которой является точное определение тестовых пакетов для оценки систем обработки транзакций и баз данных, а также для распространения объективных, проверяемых данных в промышленности.
TPC публикует спецификации тестовых пакетов, которые регулируют вопросы, связанные с работой тестов. Эти спецификации гарантируют, что покупатели имеют объективные значения данных для сравнения производительности различных вычислительных систем. Хотя реализация спецификаций оценочных тестов оставлена на усмотрение индивидуальных спонсоров тестов, сами спонсоры, объявляя результаты TPC, должны представить TPC детальные отчеты, документирующие соответствие всем спецификациям. Эти отчеты, в частности, включают конфигурацию системы, методику калькуляции цены, диаграммы значений производительности и документацию, показывающую, что тест соответствует требованиям атомарности, согласованности, изолированности и долговечности (ACID atomicity, consistency, isolation, and durability), которые гарантируют, что все транзакции из оценочного теста обрабатываются должным образом.
TPC определяет и управляет форматом нескольких тестов для оценки производительности OLTP (On-Line Transaction Processing), включая тесты TPC-A, TPC-B, TPC-C,TPC-D и TPC-E. Хотя упомянутые тесты TPC не являются непосредственно тестами для оценки производительности баз данных, системы реляционных баз данных- ключевые компоненты любой системы обработки транзакций.
Следует отметить, что, как и любой другой тест, ни один тест TPC не может измерить производительность системы, которая применима для любой возможной среды обработки транзакций, но эти тесты действительно могут помочь пользователю справедливо сравнивать похожие системы. Однако, когда пользователь делает покупку или планирует решение о покупке, он должен понимать, что никакой тест не может заменить его конкретную прикладную задачу.
Охарактеризовать нагрузку, генерируемую приложением базы данных, невозможно без детальной информации о том, что же в действительности приложение делает. Даже имея подобные сведения, приходится делать множество предположений о том, как сама СУБД будет обращаться к данным, насколько эффективным может оказаться дисковый кэш СУБД при выполнении определенных транзакций, или даже о том, какова может быть смесь транзакций.
На сегодня в промышленности приняты следующие типы характеристик нагрузки, генерируемой приложением базы данных: "легкая", "средняя","тяжелая" и "очень тяжелая". Категория "легкая" приравнивается к рабочим нагрузкам, которые доминируют в операциях, подобным транзакциям дебет/кредит, определенным в оценочных тестах TPC-A. Нагрузками "средней" тяжести считаются транзакции, определенные стандартом теста TPC-C. Тяжелыми рабочими нагрузками считаются нагрузки, которые ассоциируются с очень большими приложениями, такими как Oracle*Financials. Такие нагрузки по крайней мере в 5-10 раз тяжелее, чем принятые в тесте TCP-A.
Основным классом приложений, которые попадают в категорию "оченьтяжелой" нагрузки, являются системы поддержки принятия решений. Из-за очень больших различий в характере самих запросов к системе поддержки принятия решений, администраторы баз данных или самой СУБД сталкиваются с серьезными проблемами по обеспечению широкомасштабной оптимизации. Запросы к системе поддержки принятия решений часто приводят к формированию существенно большего числа запросов к нижележащей системе из-за необходимости выполнения многонаправленных соединений, агрегирования, сортировки и т. п. Тест TPC-D был специально разработан для оценки работы приложений поддержки принятия решений.
Подробно о структуре тестов TPC см. [4].
Хотя многих пользователей часто интересуют некоторые рекомендации по выбору конфигурации той или иной системы, полезность этих рекомендаций в значительной степени зависит от анализа самого приложения. Эффективность работы самого приложения и СУБД намного важнее, чем конфигурация хост-машины. Имеются буквально сотни примеров небольших изменений, проведенных в приложении или в схеме базы данных, которые обеспечивали 100- или 1000-кратное увеличение производительности системы. На общую производительность системы весьма существенное воздействие может оказывать хорошо продуманная индексация. После начальной инсталляции системы обязательно нужно произвести сбор статистики об ее работе, чтобы выяснить необходимость внесения изменений в базу данных. Часто оказывается возможным улучшить производительность приложения путем реорганизации базы данных даже без обращения к исходному коду приложения.
Другим соображением, которому уделяется недостаточно внимания, но которое часто оказывает огромное воздействие на результирующую производительность системы, являются конфликты по внутренним блокировкам. Если выбрана неоптимальная стратегия блокировок, то система может оказаться очень плохо работающей. Следует также отметить, что каждая СУБД имеет огромное число настраиваемых параметров, и некоторые из них могут серьезно воздействовать на общую производительность системы.
Ниже перечислены вопросы, ответы на которые позволяют обобщить процесс выбора конфигурации сервера СУБД.
В большинстве прикладных систем СУБД можно выделить три логических части: пользовательский интерфейс (средства представления), обеспечивающий функции ввода и отображения данных; некоторую прикладную обработку, характерную для данной предметной области; и собственно сервисы СУБД. Пользовательский интерфейс и прикладная обработка обычно объединены в одном двоичном коде, хотя некоторые из наиболее продвинутых приложений теперь обеспечивают многопотоковую фронтальную обработку, отделенную от средств представления.
Если в системе можно реализовать модель вычислений клиент-сервер, отделяющую фронтальную (прикладную) обработку и средства представления от поставщика услуг СУБД, ее использование обычно обеспечивает существенное улучшение общей производительности системы. Такая организация системы позволяет наиболее важному ресурсу (серверу СУБД) работать без помех на своей собственной хост-машине. Это в первую очередь справедливо для систем, в которых работа средств представления связана с управлением сотнями или тысячами терминалов.
Использование мониторов обработки транзакций является одним из методов достижения более высокой производительности для имеющейся конфигурации, особенно в режиме клиент-сервер (см. [5]). TP-мониторы представляют собой промежуточный слой программного обеспечения, который располагается между приложением и системой или системами СУБД. При этом приложение должно быть модифицировано так, чтобы оно могло выдавать транзакции, написанные на языке монитора транзакций, а не обращаться прямо к базе данных посредством обычных механизмов (подобных различным формам встроенного SQL). Программисты прикладных систем являются также ответственными за составление файла описания, который отображает транзакции в определенные обращения к базе данных народном языке обращений нижележащей СУБД (почти для всех СУБД под Unix это SQL).
Использование мониторов транзакций практически не накладывает каких-либо ограничений на многообразие или сложность запросов доступа к нижележащей СУБД. Помимо достижения определенной гибкости за счет использования TP-мониторовтакая организация оказывается выгодной и с точки зрения увеличения производительности системы. TP-монитор всегда представляет собой многопотоковую программу. Поскольку TP-монитор открывает свое собственное соединение с СУБД, одновременно устраняя необходимость выполнения каждым прикладным процессом прямых запросов к СУБД, число одновременно работающих пользователей СУБД существенно сокращается. В подавляющем большинстве случаев СУБД обслуживает только одного "пользователя"- TP-монитор.
TP-мониторы позволяют также улучшить производительность за счет сокращения объема информации, пересылаемой между СУБД и прикладным процессом. Поскольку определенную часть каждой транзакции составляют только минимально требуемые данные, общий объем пересылки данных обычно может быть сокращен. Это особенно важно, когда клиент и сервер соединены между собой посредством достаточно занятой сети и/или сети с относительно узкой полосой пропускания, например глобальной сети на спутниковых каналах связи.
Известно, что производительность любого процессора зависит от трех параметров: такта (или частоты) синхронизации, среднего количества тактов на команду и количества выполняемых команд. Таким образом, помимо тактовой частоты на производительность оказывают существенное влияние система команд и внутренняя организация процессора. Практически все поставщики компьютерной техники проводят испытания своих изделий для определения правильности выбранных архитектурных решений. Например, в таблице 2 представлены некоторые результаты измерений, полученные при прогоне теста TPC-C, построенного на базе коммерческой СУБД, на системе RISC System/6000 Model 590 (процессор POWER2) компании IBM. В таблице приняты следующие обозначения: FXU-блок обработки команд с фиксированной точкой, ICU блок обработки команд управления, FPU блок обработки команд с плавающей точкой.
Таблица 2.
Анализ этих результатов может привести к лучшему пониманию характеристик ЦП на тестах TCP-C, которые, в свою очередь, с осторожностью можно было бы обобщить на более широкую область приложений баз данных, которую представляет данный тест.
Эти результаты показывают, что в тесте TPC-C доминируют команды FXU(операции манипуляции с целыми числами и операции вычисления адресов),довольно интенсивно используются команды перехода (ICU), а команды плавающей точки (FPU) практически не используются. Такие результаты следовало ожидать, поскольку общеизвестно, что в программном коде СУБД для преобразования адресов, необходимого при обработке указателей, интенсивно используется целочисленная арифметика. Заметим, что в архитектуре POWER2 предусмотрено два целочисленных устройства. Второй FXU обрабатывает примерно треть целочисленных операций (при этом примерно половину времени, когда занят первый FXU, второй FPU также занят). Такая организация процессора дает почти 50% увеличение пропускной способности целочисленного кода по сравнению с процессором POWER(предыдущая версия архитектуры), в котором было всего один FPU, хотя исполняемый код СУБД не перекомпилировался. Таким образом, наличие в POWER2 двух целочисленных устройств существенно сокращает среднее количество тактов на выполнение одной команды (CPI) на рабочей нагрузке.
Почти все операции ICU представляют собой операции перехода, причем примерно треть из них составляют операции условного перехода. Почти равное соотношение выполняемых и невыполняемых условных переходов, а также небольшое число команд перехода по значению счетчика правильно отражают реализацию операторов перехода if-then-else, которые, как и следовало ожидать, доминируют в этой рабочей нагрузке. Средний размер базового блока (последовательности команд, выполняемых между двумя выполняемыми переходами) очень небольшой. Таким образом, данная рабочая нагрузка существенно отличается от нагрузки, реализующей алгоритмы из области научно-технических приложений с интенсивными вычислениями, которая связана с многократным повторением итераций циклов, включающих достаточно длинные последовательности программного кода, и дает значительно большее количество выполняемых переходов, больший процент команд перехода по значению счетчика и больший размер базового блока.
Коэффициент промахов кэша команд (I-кэша) размером 32 Kбайт довольно низок, хотя и выше, чем коэффициент промахов для многих других рабочих нагрузок. Коэффициент промахов существенно сокращается благодаря большому размеру строки I-кэша (128 байт) и локальности кода. Наличие достаточно большого кэша данных (D-кэша) емкостью 256 Кбайт объясняет наблюдающийся низкий коэффициент промахов по данным.
Таким образом, результаты подобных испытаний позволяют разработчикам процессоров оценить эффективность функциональной организации ЦП. В современных суперскалярных процессорах Intel и RISC-процессорах (Ultra SPARC, PA-8000,MIPS R10000, PowerPC 604/620 и DEC Alpha) практически повсеместно используются параллельно работающие блоки целочисленной арифметики, предусмотрены развитые средства прогнозирования направления переходов и большие по объему кэши команд и данных. Сегодня производительность этих процессоров находится на одном уровне с производительностью самых быстрых мэйнфреймов. Тактовая частота RISC-процессоров достигла 500 МГц, а общая производительность на стандартных оценочных тестах сравнима (рис. 1).
В настоящее время стандартным средством увеличения производительности системы является симметричная мультипроцессорная обработка (SMP), предполагающая использование многими процессорами одной общей памяти и одной операционной системы, которая управляет всеми процессорами и аппаратными средствами. В современных системах SMP наиболее актуальным вопросом является создание высокопроизводительной подсистемы памяти для обеспечения высокоскоростных процессоров данными и командами. Общее решение этой проблемы заключается в использовании большой высокоскоростной кэш-памяти, т. е. создании иерархии памяти между процессорами и разделяемой общей памятью, а также общесистемной шины с высокой пропускной способностью.
В общем случае потребление процессорных ресурсов очень сильно варьируется в зависимости от используемого приложения, СУБД, особенностей отдельных пользователей и даже от времени дня. Например, результаты теста TPC-A 1994года показывали, что восьмипроцессорный SPARCserver 1000 компании Sun способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. (Эти результаты были получены на многопотоковом сервере OracleVersion 7, работающим в режиме клиент-сервер, причем в качестве фронтальной системы использовался монитор обработки транзакций Tuxedo/T.) Следует отметить, что такие высокие показатели были достигнуты специалистами компаний Sun и Oracle путем очень тщательной настройки ОС Solaris, СУБД Oracle и самого оценочного теста. Возможности этих специалистов по настройке системы, очевидно, значительно превосходят возможности большинства пользователей. Более реалистическая верхняя граница числа пользователей на процессор, возможно, составляет порядка 100-200 пользователей на один процессор SuperSPARC 50 МГц, даже для легких транзакций типа TPC-A. Более крупные приложения, естественно, приводят к меньшему числу пользователей на процессор (соответствующие результаты представлены в таблице 3).
Таблица 3.
Примерное число поддерживаемых пользователей на ЦП.
Следует отметить, что процессор Super-SPARC 50 МГц уже снят с производства, и нынешнее поколение процессоров Sun, в частности, UltraSPARC II 250 МГц, имеет почти на порядок большую производительность. Тем не менее результаты таблицы 3 весьма поучительны. Например, они показывают, что ни операционная система Solaris 2, ни СУБД не масштабируются линейно (то же самое происходит и с конкурирующими операционными системами), хотя со временем по мере дальнейшей настройки ОС и СУБД имеется определенный прогресс в этом направлении.
Среди различных компонентов аппаратуры сервера СУБД конфигурация памяти системы обычно имеет самое большое воздействие на ее производительность. Хотя для многих людей память представляется только хранилищем выполняемых программ, большая часть основной памяти в системах СУБД используется в качестве буфера (кэша) данных, позволяющего во многих случаях устранить необходимость выполнения физического ввода-вывода с диска. Поскольку обращение к основной памяти выполняется примерно в 30000 раз быстрее, чем обращение к быстрому диску, минимизация дискового ввода-вывода является первостепенно важной задачей. Не будет преувеличением сказать, что "возня"с другими конфигурационными параметрами бесполезна, если в системе не хватает основной памяти. К счастью, обычно ошибки по конфигурации памяти сравнительно легко исправляются.
Поставщики СУБД называют буферы данных по-разному, но все они выполняют одну и ту же функцию. Компания Oracle, например, называет эту память Глобальной Областью Системы (SGA System Global Area), в то время как Sybase называет ее Кэшем Разделяемых Данных (Shared Data Cashe). Обычно буфер реализуется как большой массив разделяемой памяти, и его размер определяется специальным параметром в управляющем файле или таблицах СУБД. Размер памяти, необходимый для организации дискового кэша СУБД, меняется в широких пределах от приложения к приложению.
Возможно, самым простым и наиболее полезным является эмпирическое правило, которое называется "правилом пяти минут". Существующее в настоящее время соотношение между ценами подсистемы памяти и дисковой подсистемы показывает, что экономически целесообразно кэшировать данные, к которым осуществляются обращения более одного раза каждые пять минут. Это означает, что данные, к которым обращения происходят более часто, чем один раз впять минут, должны кэшироваться в основной памяти. Соответственно, чтобы оценить размер кэша данных необходимо просуммировать объемы всех данных, которые приложение предполагает использовать более часто, чем один раз в пять минут на уровне всей системы. Поэтому при определении необходимого объема основной памяти рассчитывают, по крайней мере, на такой размер кэша данных. Дополнительно обычно резервируют еще 5-10% для размещения верхних уровней индексов B-деревьев, хранимых процедур и другой управляющей информации СУБД.
Каждая коммерческая СУБД обеспечивает механизм для определения стоимости или преимуществ изменения размера различных кэшей СУБД. Когда система инсталлирована и начинает работать, необходимо использовать эти механизмы для определения эффекта от изменения размеров кэша ввода-вывода СУБД.
Хотя основной целью СУБД на макроуровне является управление томами данных, которые по определению имеют очень большой объем и неизбежно во много раз превышают объем основной памяти, проведенные исследования показали, что доступ к данным в общем случае подчиняется правилу "90/10": 90%всех обращений выполняются к 10% данных. Более того, оказалось, что к "горячим" данным, обращения к которым составляют 90% всех обращений, снова применимо правило "90/10". Таким образом, примерно 80% всех обращений к данным связаны с доступом к примерно 1% агрегированных данных. Следует отметить, что это отношение включает обращения к внутренним метаданным СУБД (включающих индексы B-деревьев и т. п.), обращения к которым обычно скрыты от прикладного программиста. Хотя желательно иметь коэффициент попаданий в кэш примерно на уровне 95%, по экономическим соображениям невозможно слепо обеспечить объем кэша в памяти, позволяющий разместить 10% всех данных: даже для скромных баз данных объемом 5 Гбайт это потребовало бы увеличения размера основной памяти до 500 Мбайт. Однако обычно всегда возможно обеспечить кэш объемом в 1% всех данных даже для очень больших баз данных. Максимальный объем основной памяти современных серверов может быть очень большим. Например, в серверах DEC AlphaServer 8400 он достигает 28 Гбайт, в серверах ChallengeXL компании Silicon Graphics - 16 Гбайт, а в серверах Enterprise 6000 компании Sun Microsystems - 30 Гбайт. Таким образом, эти серверы могут работать с базами данных объемом более одного терабайта (при наличии баз данных такого размера для поддержки неизбежно большого числа пользовательских приложений и т. д. очевидно также потребуется существенная часть этой памяти).
Естественно, конфигурация системы должна обеспечивать также пространство для традиционного использования памяти. В СУБД на базе Unix и NT всегда необходимо обеспечить по крайней мере 16 Мбайт для базовой операционной системы. Далее необходимо предусмотреть пространство объемом 2-4 Мбайт для ряда программ СУБД (программ ведения журнала, проверки согласованного состояния, архиваторов и т. п.) и достаточно пространства для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1-2 Мбайт, но иногда они могут достигать 16-20 Мбайт. Операционная система обеспечивает режим разделения двоичных кодов между множеством пользующихся ими процессов, поэтому необходимо резервировать пространство только для одной копии. Пространство для размещения самого кода сервера СУБД зависит от его архитектуры.
Для многопроцессорных систем существует также эмпирическое правило, которое гласит, что неразумно конфигурировать менее, чем примерно 64 Мбайт памяти на процессор. Обрабатываемая каждым ЦП дополнительная информация требует выделения некоторого пространства для того, чтобы обойти интенсивную фрагментацию памяти.
Система Teradata DBC/1024 первой рассеяла представление о том, что микропроцессоры не могут управлять очень большим числом дисковых накопителей (так называемыми" большими фермами дисков"). В ряде организаций даже самые большие мэйнфреймы служат только в качестве фронтальных систем к кластеру Teradata. Этот кластер включает несколько сотен процессоров Intel 486, которые управляют доступом к нескольким тысячам дисков SCSI. Многие крупные организации розничной торговли используют такие многотерабайтные дисковые фермы для анализа своей деятельности по продаже и оптимизации учета товаров. Эти системы обеспечивают очень высокую производительность даже при очень интенсивной обработке данных в системах принятия решений.
Еще сравнительно недавно системы на базе персональных компьютеров были ограничены необходимостью совместимости с шиной PC-AT, которая обеспечивала скорость ввода-вывода всего несколькими мегабайтами в секунду; это меньше, чем скорость передачи данных одного современного диска. Современные серверы, построенные на базе процессоров Intel и RISC-процессоров, оснащаются шинами SBus, PCI и MicroChannel cо скоростью передачи данных 100, 132 и 160 Мбайт/с, соответственно, а общая пропускная способность их подсистем ввода-вывода ограничивается лишь возможностями применяемой системной шины и находится в диапазоне 0,6-2,5 Гбайт/с.
Таким образом, дисковые архитектуры современных серверов имеют очень высокую производительность. Современные "малые" Fast/ Wide/DifferentialSCSI-диски обеспечивают скорость передачи данных до 12,5 Мбайт/с, а измерения скорости массивов таких дисков превысили уровень 60 Мбайт/с. Современные диски SCSI являются столь же надежными, что и их собратья с мэйнфреймов, но примерно в два раза быстрее и примерно в 10 раз дешевле.
Если все обстоит так хорошо, то какие же проблемы связаны с реализацией дискового ввода-вывода в СУБД и выбором конфигурации дисковой подсистемы? Рассмотрим их по порядку.
Без понимания приложения, стратегии индексации, принятой администратором базы данных, а также механизмов поиска и хранения СУБД сложно сделать точное утверждение о том, какого типа доступа к диску данная транзакция будет навязывать системе. Однако можно предположить, что любая транзакция, которая находит небольшое число специально поименованных записей из индексированной таблицы "по индексному ключу", будет представлять собой операцию произвольного доступа к диску. Обработка запросов, которые содержат целый ряд значений ключей, может приводить к некоторой комбинации произвольного и последовательного доступа, в зависимости от имеющей место индексации.
Напомним, что любое обновление базы данных связано и с обновлением всех затронутых индексов, а также с выполнением записи в журнал. К сожалению, вся эта техника уходит далеко за рамки данной статьи, требуя основательного понимания работы конкретной используемой СУБД, сложной природы запросов и методов оптимизации запросов. Оценка требований к выполнению дисковых операций оказывается неточной без детальной информации о том, как СУБД хранит данные.
Одной из наиболее общих проблем в СУБД является обеспечение большой емкости дисковой памяти для хранения данных при достаточной пропускной способности дисковой подсистемы. На большинстве серверов при выполнении обращений к диску доминируют операции произвольного доступа. Сегодня на рынке имеется множество дисков, но их производительность при выполнении операций произвольного доступа почти одна и та же: 65-70 операций в секунду!
По этим причинам наилучшие возможности при организации ввода-вывода почти всегда достигаются при использовании наименьшего по емкости диска, даже когда больший диск имеет превосходные спецификации по всем параметрам. Например, в 1994 году сервер SPARCserver 1000 мог оснащаться дисками емкостью535 Мбайт, 1,05 Гбайт и 2,1 Гбайт. Как видно из таблицы 4 для заданного объема дисковой памяти (16 Гбайт), общая пропускная способность дисковой подсистемы существенно выше при использовании дисков 535 Мбайт (больше чем в три раза).
Таблица 4.
Емкость ввода-вывода для памяти 16 Гбайт.
Применение дисков такой малой емкости не всегда практично, поскольку общие требования к емкости дисковой подсистемы могут привести к использованию дисков большей емкости, или, возможно, в системе окажется недостаточно доступных слотов периферийной шины для конфигурирования необходимого числа главных адаптеров SCSI. Тем не менее было бы серьезной ошибкой подбирать для системы дисковые накопители исключительно исходя из требуемой общей емкости дисковой памяти. Хотя эта проблема не нова, со временем она становится все более серьезной, поскольку емкость дисковых накопителей и требования к общей емкости дисковой памяти начинают увеличиваться значительно более быстрыми темпами, чем скорость доступа к дискам.
Первоначально при разработке файловых систем Unix и DOS не ставилась задача обеспечения высокопроизводительного дискового ввода-вывода. В традиционной файловой системе Unix, в отличие от экстентных систем типа OS/360 и VMS, данные отображаются на диск в виде дерева небольших блоков, они копируются по крайней мере дважды (поскольку перемещаются через буферный пул), и все операции ввода-вывода выполняются как синхронные запросы. В современных версиях Unix эти недостатки давно уже учтены, и в них реализованы возможности организации асинхронного и не буферизованного ввода-вывода.
Кроме того, для удовлетворения нужд интенсивных по вводу-выводу приложений почти все системы Unix обеспечивают интерфейс "чистых" дисков. Системный администратор может определять зоны диска, которые выделяются приложению (эти зоны выглядят как файлы). Затем приложение может выполнять прямые операции Get_Block() и Put_Block для чтения и записи в такие файлы. Этот интерфейс имеет малые накладные расходы.
Большинство СУБД позволяют администратору системы выбрать способ размещения файлов СУБД (на "чистых" дисках или в стандартной файловой системе Unix). Некоторые системы, наиболее известными из которых являются Ingres и Interbase, навязывают использование файловой системы Unix. Для систем, которые допускают выбор указанных возможностей, приходится оценивать целый ряд разных критериев.
Хранение данных в файловой системе оказывается менее эффективным (отличие составляет, по крайней мере, 10%), поскольку при выполнении каждого обращения к диску со стороны СУБД в работу включается дополнительный слой системного ПО. Поскольку в больших СУБД часто одним из ограничивающих ресурсов является мощность процессора, использование "чистых" разделов (raw partition)улучшает производительность системы при пиковой нагрузке. Только по этой причине большинство администраторов баз данных обычно предпочитают хранение данных на "чистых" разделах дисков.
Хранение данных в файловой системе приводит также к определенной потере емкости памяти. Файловая система Unix потребляет примерно 10% от форматированной емкости дисков для метаданных о файлах и файловой системе. Более того, файловая система резервирует 10% оставшегося пространства, чтобы обеспечить быстрый поиск свободного пространства в случае расширения файлов. Если СУБД работает с данными через файловую систему, то по сравнению с "чистым" диском емкость дисковой памяти в целом уменьшается на 19%.
Имеется несколько важных причин, по которым в СУБД используется хранение данных в файловой системе. Большинство из них связано с обеспечением гибкости или относится к разряду более знакомой для пользователя технологии.
Во-первых, и, что, возможно, наиболее важно, использование файловой системы позволяет работать с памятью с помощью стандартных утилит Unix. Например, стандартные утилиты Unix ufsdump и ufsrestore могут использоваться для того, чтобы производить надежное резервное копирование и восстановление памяти СУБД. К тому же гораздо проще осуществлять манипулирование отдельными частями базы данных. Например, можно осуществлять прямое перемещение таблицы с одного диска на другой, даже если используются диски разного размера и типа. Хотя каждый из поставщиков СУБД предлагает свои собственные внутренние утилиты резервного копирования и восстановления, все они различны. Более того, некоторые из них выполняются настолько медленно, что заказчики часто применяют копирование физических томов (т. е. используют команду dd(1))со всеми присущими такому копированию сложностями. Хранение данных в файловой системе позволяет выполнять единообразные, надежные процедуры для того, чтобы работать через систему и сеть. При этом, если необходимо, могут также использоваться инструментальные средства поставщиков СУБД.
Обычно пользователи рассматривают СУБД как средство хранения и последующего поиска своих данных и вовсе не задумываются о том, что же в действительности хранится на диске. На практике программное обеспечение СУБД поддерживает значительное количество дополнительной информации. Было бы серьезной ошибкой предполагать, что для размещения заданного количества данных пользователя потребуется тот же самый объем дискового пространства. Схема базы данных, табличные индексы, B-деревья узлов каталогов, временные таблицы, заранее выделенное пространство для хеш-таблиц и индексов, пространство для сортировки, файлы журнала, архивы и множество других данных все это включается в дисковое пространство системы.
Если отсутствует более точная информация (обычный случай при покупке новой системы), то разумно было бы предусмотреть примерно удвоенный объем дискового пространства по сравнению с объемом "чистых" данных. Это обеспечивает некоторую гибкость для создания индексов и т. п., и в итоге позволяет улучшить производительность приложения. Хотя коэффициент2, на первый взгляд, кажется чрезмерным, следует, например, иметь в виду, что индексация, навязываемая предложенным тестом TPC-D, потребляет более400 Мбайт. При этом объем "чистых" данных составляет примерно650 Мбайт. При использовании устанавливаемых по умолчанию параметров памяти СУБД Oracle объем "чистых" данных, необходимых для реализации теста TPC-C, увеличивается на 30% при хранении их в базе данных Oracle даже без индексации. Поэтому можно легко потребовать для системы даже гораздо больше, чем 100% дополнительного пространства.
Другим фактором, влияющим на конфигурацию подсистемы ввода-вывода, является предполагаемое распределение данных по дискам. Даже минимальная по объему система должна иметь по крайней мере четыре диска: один для операционной системы и области подкачки (swap), один для данных, один для журнала и один для индексов. В более крупных системах приходится учитывать и ряд дополнительных возможностей, например использование зеркальных дисков, механизмов расщепления и перекрытия ресурсов. Вообще говоря, наиболее продуктивными достаточно эффективным по стоимости способом распределения данных является обеспечение всех основных логических сущностей отдельным набором дисков.
Хотя технически возможно объединить по несколько логических функций на одних и тех же (физических или логических) дисках, для подсистемы ввода-вывода это оказывается очень разрушительным и почти всегда приводит к неудовлетворительной производительности. В частности, может оказаться, что процесс формирования журнала, который должен писаться синхронно, в действительности будет выполняться в режиме произвольного, а не последовательного доступа к диску. Уже только это одно будет существенно задерживать каждую транзакцию обновления базы данных.
Кроме того, выполнение запросов, выбирающих записи из таблицы данных путем последовательного сканирования индекса, будет связано с сильно увеличенным временем ожидания ввода-вывода. Обычно сканирование индекса выполняется последовательно, но в данном случае каретка диска должна перемещаться для поиска каждой записи данных между выборками индексов. В результате происходит произвольный доступ к индексу, который предполагался последовательным. Если таблица данных, индекс и журнал находятся на отдельных дисках, то произвольный доступ к диску осуществляется только при выборке данных из таблицы, и результирующая производительность увеличивается вдвое.
Наконец, следует отметить, что объединение разных функций на одних и тех же физических ресурсах приводит к резкому увеличению времени подвода головок на диске. Хотя время позиционирования в спецификациях дисковых накопителей обычно приводится как одно число, в действительности длительность позиционирования сильно зависит от конкретного перемещения головок. Приводимое в спецификациях время позиционирования представляет собой сумму времен всех возможных позиционирований головок, деленное на количество возможных позиционирований. Это не то время, которое затрачивается при выполнении "типичного" позиционирования. Сама физика процесса перемещения дисковой каретки определяет, что позиционирование на короткое расстояние занимает гораздо меньше времени, чем на длинное. Позиционирование на смежный цилиндр занимает всего несколько миллисекунд, в то время как позиционирование на полный ход каретки длится значительно больше времени, чем приводимое в спецификациях среднее время позиционирования. Например, для диска 2,1Гбайт позиционирование головки на соседний цилиндр обычно занимает 1,7мс, но длится 23 мс для полного хода каретки (в 13 раз дольше). Поэтому длительное позиционирование головок, возникающее при последовательности обращений к двум разным частям диска, необходимо по возможности исключать.
При выборе конфигурации подсистемы ввода-вывода должно быть уделено внимание не только максимальной емкости ее компонентов, но также уровню использования (загруженности) каждого ресурса. Большинство параметров, используемых для описания емкости ресурсов, так или иначе связаны с пропускной способностью. Например, шина SCSI характеризуется пропускной способностью в 10 Мбайт/с. Это скорость пересылки битов по шине. Такой параметр не дает информации о том, насколько занята сама шина, и, следовательно, о том, сколько времени будет потрачено на обслуживание данного запроса. Приводить в качестве параметра ресурса рейтинг максимальной пропускной способности все равно, что говорить, - предел скорости автомагистрали равен 130 км в час: если въезды и съезды с нее так перегружены, что это занимает длительное время, то общая скорость, вероятно, будет намного ниже установленного предела.
Точно такие же принципы применимы к различным периферийным устройствами периферийным шинам. В частности, это справедливо и для шин SCSI. Экспериментальные результаты показывают, что если должна поддерживаться пиковая производительность, то степень загруженности шины SCSI должна поддерживаться на уровне 40%.Аналогичным образом, степень загрузки дисков должна поддерживаться на уровне60%. Диски могут выдерживать значительно большую степень загрузки, чем шина SCSI, поскольку во встроенных дисковых контроллерах имеется интеллект и средства буферизации. Это позволяет координировать работу буферов дорожек, каретки диска и очереди запросов такими способами, которые невозможны на достаточно примитивных главных адаптерах шины SCSI.
Обычно нельзя оценить среднюю степень загрузки дисков или шины SCSI до тех пор, пока система не начнет работать. В результате достаточно приемлемой оказывается такая конфигурация, которая позволяет распределить часто используемые данные и индексы по стольким дискам и шинам SCSI, насколько позволяют бюджет и технические ограничения. Для данных, доступ к которым происходит не очень часто, например только во время ночной пакетной обработки (или других полуархивных данных, подобных транзакциям годовой давности), можно рекомендовать как можно более плотную упаковку на накопителях.
Как только система начнет работать, можно измерить действительную степень загрузки дисков и соответствующим образом перераспределить данные. Как указывалось выше, перераспределение данных должно выполняться с учетом других параметров доступа к диску: везде надо поддерживать баланс.
В контексте СУБД имеется по крайней мере два механизма для распределения данных по дисковым накопителям. Для эффективного распределения доступа к данным все известные СУБД имеют возможность осуществлять конкатенацию нескольких дисковых накопителей или файлов Unix. (В СУБД Ingres, например, реализовано и истинное расщепление дисков, ограниченное стандартным размером чередования 16 Кбайт.) Похожие возможности (помимо горячего резервирования и расщепления дисков) предлагают и многие специальные пакеты, которые можно рассматривать как интегральную часть файловых систем Unix (например, Online: DiskSuite компании Sun). Файловая система NT моделирует файловую систему VMS. Она включает экстентные файлы, возможности прямого и асинхронного ввода-вывода, зеркалирования и расщепления дисков.
Если работа с таблицей ограничивается возможностями подсистемы ввода-вывода, необходимо исследовать запросы, которые вызывают ввод-вывод. Если эти запросы реализуют произвольный доступ к дискам, например если многие пользователи независимо запрашивают индивидуальные записи, то имеющиеся возможности конкатенации дисков в СУБД полностью адекватны распределению нагрузки доступа по множеству дисков (при достаточно полном заполнении пространства таблицы).Если обращения по своей природе последовательны, в частности если один или несколько пользователей должны просматривать каждую строку таблицы, то больше подходит механизм расщепления дисков.
Обычно СУБД делят таблицу на несколько относительно больших сегментов и размещают данные равномерно по этим сегментам. Главное отличие между конкатенацией СУБД и функцией расщепления заключается в размещении смежных данных. Когда диски конкатенируются друг с другом, последовательное сканирование представляет собой тяжелую нагрузку для каждого из дисков, но эта нагрузка носит последовательный характер (только один диск участвует в обслуживании запроса). Истинное расщепление дисков осуществляет деление данных по гораздо более мелким границам, позволяя тем самым всем дискам участвовать в обслуживании даже сравнительно небольшого запроса. Как результат при использовании расщепления загрузка дисков при выполнении последовательного доступа существенно уменьшается. К архивным и журнальным файлам всегда осуществляется последовательный доступ, и они являются хорошими кандидатами для расщепления, если реализация обращений к таким файлам ограничивает общую производительность системы.
По мере роста размеров и важности баз данных процедуры резервного копирования, которые выполняются с блокировкой доступа к СУБД, становятся практически неприемлемыми. При реализации резервного копирования в оперативном режиме(режиме on-line) могут возникнуть достаточно сложные вопросы по конфигурированию соответствующих средств, поскольку резервное копирование больших томов данных, находящихся в базах данных, приводит к очень интенсивной работе подсистемы ввода-вывода. Резервное копирование в оперативном режиме часто вызывает очень высокий уровень загрузки дисков и шины SCSI, что приводит к низкой производительности приложений. Поэтому особое внимание обычно уделяется конфигурациям всех устройств, вовлеченных в процессы резервного копирования.
Если СУБД работает в режиме клиент-сервер, то сеть или сети, соединяющие клиентов с сервером, должны быть адекватно оборудованы. К счастью, большинство клиентов работают с вполне определенными фрагментами данных: индивидуальными счетами, единицами хранящихся на складе изделий, историей индивидуальных счетов и т. п. В этих условиях скорость сети, соединяющей клиентов и серверы, редко оказывается ограничивающим фактором. Отдельной сети Ethernet или Token Ring обычно достаточно для обслуживания 100-200 клиентов. Однако по очевидным причинам стоит более внимательно наблюдать за загрузкой сети, особенно когда число клиентов превышает примерно 20 на один сегмент Ethernet. Сети Token Ring могут поддерживать несколько большую нагрузку, чем сети Ethernet, благодаря своей устойчивости к деградации под нагрузкой. Но даже если с пропускной способностью сети не возникает никаких вопросов, проблемы задержки часто приводят к тому, что более удобной и полезной оказывается установка отдельной, выделенной сети между фронтальной системой и сервером СУБД.
Однако в ряде случаев возможностей сетей Ethernet или Token Ring может оказаться недостаточно. Чаще всего это случается, когда данные хранятся в базе в виде очень больших массивов. Например, в медицинских базах данных часто хранятся образы рентгеновских снимков, поскольку они могут быть легко объединены с другими данными истории болезни пациента; эти образы рентгеновских снимков часто бывают размером в 3-5 Мбайт. Другими примерами приложений с интенсивным использованием данных являются системы хранения/выборки документов, САПР в области механики и системы мультимедиа. В этих случаях наиболее подходящей сетевой средой является FDDI, хотя в сравнительно ближайшем будущем она, может быть, будет заменена на ATM или Ethernet 100 Мбит.
Для систем, требующих большей пропускной способности сети, чем обеспечивают Ethernet или Token Ring, по существу до конца 1994 года FDDI была единственным выбором. Хотя концентраторы FDDI имеют значительно большую стоимость по сравнению с хабами Ethernet, установка выделенной сети между фронтальной системой и сервером СУБД оказывается достаточно простой и недорогой. Как определено в стандарте FDDI, минимальная сеть FDDI состоит только из двух систем, соединенных между собой с помощью единственного кабеля. Никаких концентраторов не требуется.
В последнее время резко увеличилось число приложений, в которых фронтальные системы и серверы СУБД могут или должны размещаться в географически разнесенных местах. Такие системы должны соединяться между собой с помощью глобальных сетей. Обычно средой передачи данных для таких сетей являются арендованные линии с синхронными последовательными интерфейсами. Эти линии обычно работают со скоростями 56-64 Кбит/с, 1,5-2,0 Мбит/с и 45 Мбит/с. Хотя скорость передачи данных в такой среде значительно ниже, чем обычные скорости локальных сетей, подобных Ethernet, природа последовательных линий такова, что они могут поддерживать очень высокий уровень загрузки. Линия T1 предлагает пропускную способность 1,544 Мбайт/с (2.048 Мбит/с за пределами США). По сравнению с 3,5 Мбит/с, обеспечиваемых Ethernet в обычном окружении, линия T1 предлагает пропускную способность, которая количественно практически не отличается от Ethernet. Дробные линии T3 часто доступны со скоростями 10-20 Мбит/с, очевидно соперничая с сетями Ethernet и Token Ring. В ряде случаев можно найти приложения, которые могут работать успешно в конфигурации клиент-сервер даже через сеть со скоростью 56 Кбит/с.
Для традиционных бизнес-приложений трафик конфигурации клиент-сервер обычно содержит сравнительно низкий объем данных, пересылаемых между фронтальной системой и сервером СУБД, и для них более низкая пропускная способность сети может оказаться достаточной. В большинстве случаев задержка сети не является большой проблемой, однако если глобальная сеть имеет особенно большую протяженность или если сама среда передачи данных имеет очень большую задержку (например спутниковые каналы связи), приложение должно быть протестировано для определения его чувствительности к задержкам пакетов.
Для сокращения трафика клиент-сервер до абсолютного минимума могут использоваться мониторы обработки транзакций.
Общей ошибкой пользователей является представление о том, что сетевой трафик, связанный с терминальными серверами, может перегрузить Ethernet. Это неправильно. Рассмотрим, например, 64-портовый сетевой терминальный сервер, который может управлять каждым портом, работающим со скоростью38400 бод, или 38400 символов в секунду. (В каждом байте данных содержится8 бит информации, но рейтинг бод включает биты старта и стопа.) Если каждый порт работает на полной скорости 38 400 бод, то всего за одну секунду посети будет пересылаться 2 457 600 байт данных (или примерно 1,9 Мбит, т.е. около 20% максимальной загрузки Ethernet) с главной системы в терминальный сервер для дальнейшего распределения. Конечно, имеются некоторые накладные расходы (дополнительные байты TCP/IP), связанные с этим уровнем трафика, но они составляют примерно 50 байт на пакет, т. е. примерно 4% для этого уровня трафика. Это сценарий наихудшего случая, например, когда на полной скорости работают 64 принтера. Типичный же уровень трафика намного ниже: один 2000-символьный экран может отображаться один раз в минуту. При этих условиях 64-портовый терминальный сервер обрабатывает примерно 35 байт в секунду на один порт или всего примерно 2 Кбайт/с.
Операции по вводу символов с клавиатуры терминала можно вообще не рассматривать, поскольку даже самая быстрая машинистка печатает только 20 символов в секунду(более типичный случай 1,0-1,5 символов в секунду). Даже если операции ввода обрабатываются в режиме cbreak, наибольшая нагрузка, которая будет генерироваться всеми пользователями, может составлять 1300 символов в секунду(по 20 символов в секунду на каждый порт при 64 портах). После учета максимальных накладных расходов TCP/IP это дает общий поток в 80 Кбайт/с. Типичные нагрузки(64 порта по 1,5 символа в секунду) будут составлять порядка 15 Кбайт/сс учетом накладных расходов.
По определению семантики оператора SQL COMMIT_WORK любая СУБД должна гарантировать, что все обновления базы данных должны направляться и фиксироваться в стабильной памяти (т. е. любой памяти, которая обеспечивает устойчивое хранение данных даже в условиях сбоев системы или отказов питания). Чтобы СУБД могла дать такую гарантию, она должна выдавать для выполнения, по крайней мере, некоторые из своих операций записи синхронно. Во время выполнения таких записей операционная система блокируется и не возвращает управление вызвавшей программе до тех пор, пока данные не будут зафиксированы в стабильной памяти. Хотя эта стратегия очень надежна, вместе с тем она приводит к существенному замедлению операций, поскольку при выполнении синхронных записей обязательно требуется, чтобы данные были записаны непосредственно на дорожку диска. Синхронная запись на "чистый" диск занимает примерно 20 мс, асинхронная запись в файловую систему может занять в несколько раз больше времени (если должны быть выполнены обновления в косвенные блоки или блоки с двойной косвенностью).
Обычно СУБД осуществляют синхронную запись только в свои журналы; в случае отказа системы сама база данных может быть реконструирована из синхронно записанного журнала. Иногда система в целом становится узким горлом в процессе заполнения журнала. Обычно это случается в среде тяжелой обработки транзакций, которая выполняет многочисленные обновления базы данных (приложения, выполняющие только чтение базы данных, подобные системам поддержки принятия решений, осуществляют немного записей в журнал). Этот эффект еще более усиливается при использовании для журнальных дисков зеркальных пар. В этих случаях для ускорения процесса журнализации часто полезно использовать PrestoServe или NVSIMM. Фиксация записей в немеханических NVRAM, устанавливаемых на PrestoServe или в NVSIMM, может существенно расширить узкое горло в некоторых системах.
Поскольку обычно базы данных бывают очень большими, и в них хранится исключительно важная информация, правильная организация резервного копирования данных является очень важным вопросом. Объем вовлеченных в этот процесс данных обычно огромен, особенно по отношению к размеру и обычной скорости устройств резервного копирования. Просто непрактично осуществлять дамп базы данных объемом 20 Гбайт на магнитную ленту 4 мм, работающую со скоростью500 Кбайт/с: это займет примерно 12 часов. В этой цифре не учтены даже такие важные для работы системы соображения, как обеспечение согласованного состояния базы данных и готовность системы.
Составить расписание для резервного копирования системы, которая используется, главным образом, в течение нормального рабочего времени, обычно сравнительно просто. Для выполнения процедур резервного копирования после завершения рабочего дня часто используются скрипты. В некоторых организациях эти процедуры выполняются автоматически даже без привлечения обслуживающего персонала, в других в неурочное время используют операторов. Для выполнения автоматического резервного копирования без привлечения обслуживающего персонала требуется возможность его проведения в рабочем режиме (режиме on-line).
Если система должна находиться в рабочем режиме 24 часа в сутки или если время, необходимое для выполнения резервного копирования превышает размер доступного окна (временного интервала), то планирование операций резервного копирования и конфигурирование соответствующих средств значительно усложняются.
В некоторых случаях необходимо выполнять резервное копирование "врежиме on-line", т. е. в то время, когда база данных находится в активном состоянии с подключенными и работающими пользователями.
При выполнении резервного копирования базы данных предполагается, что она находится в согласованном состоянии, т. е. все зафиксированные обновления базы данных не только занесены в журнал, но и записаны также в таблицы базы данных. При реализации резервного копирования в режиме on-line возникает проблема: чтобы резервные копии оказались согласованными, после того как достигнута точка согласованного состояния базы данных и начинается резервное копирование, все обновления базы данных должны выполняться без обновления таблиц самой базы до тех пор, пока не завершится ее полное копирование. Большинство основных СУБД обеспечивают возможность резервного копирования в режиме on-line.
Продолжительность процедур резервного копирования, возможно, является наиболее важным вопросом для организаций с большими базами данных (объемом более 10 Гбайт), и выбор методики резервного копирования может определяться именно этим. Резервное копирование небольших баз данных легко осуществляется при наличии всего одного накопителя на магнитной ленте Exabyte или DAT. Хотя многие выпускаемые в настоящее время накопители на МЛ позволяют копировать данные со скоростью примерно 1,25 Гбайт в час, для больших баз данных это, очевидно, неприемлемо. Для увеличения пропускной способности несколько устройств могут работать параллельно, хотя конфликты по ресурсам делают этот способ недостаточно эффективным при использовании одновременно более трех-четырех НМЛ.
Некоторые НМЛ на ленте 8 мм с аппаратной компрессией способны обеспечивать скорость до 6 Гбайт/с, т. е. более чем вдвое превышают скорость стандартных устройств. Часть из этих устройств имеют емкость до 40 Гбайт, но более типичной является емкость 10-14 Гбайт. Для очень больших баз данных в качестве устройств резервного копирования применяются библиотеки, построенные на базе стандартных накопителей. В этом случае немаловажными являются такие параметры, как количество устройств чтения/записи в библиотеке, количество используемых лент, наличие устройства чтения BarCode для быстрого поиска нужной ленты. Современные ленточные библиотеки имеют емкость более одного терабайта (двух терабайт с аппаратной компрессией) и обеспечивают скорость копирования до 40 Гбайт в час.
Если недоступно устройство, которое поддерживает аппаратную компрессию, то стоит рассмотреть возможность использования программной компрессии. Скорость резервного копирования обычно определяется скоростью физической ленты, поэтому любой метод, сокращающий количество данных, которые необходимо записать на ленту, должен исследоваться, особенно при использовании быстрых ЦП. Базы данных являются хорошими кандидатами для компрессии, поскольку большинство таблиц и строк включают значительную часть свободного пространства(обычно используются даже коэффициенты заполнения, обеспечивающие определенный процент свободного пространства с целью увеличения производительности).Некоторые таблицы могут содержать также текст или разбросанные поля двоичных данных и готовы для компрессии.
Перспективным средством резервного копирования и архивирования информации считаются также магнитооптические устройства. Правда, пока они имеют сравнительно небольшую вместимость (до 2,6 Гбайт) и сравнительно высокую стоимость носителей.
Простым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный зеркальный диск. Если зеркальная копия сделана непосредственно после контрольной точки, или после того, как база данных выключена, она действительно становится дисковой резервной копией on-line, которая сама может быть скопирована в любое удобное время. Можно даже выполнить рестарт базы данных, чтобы продолжить нормальную обработку, хотя с меньшей избыточностью. Если доступно достаточное количество дисковых накопителей, то может быть использован и второй набор зеркальных дисков, что позволяет сохранить полное зеркалирование, даже когда один набор зеркальных дисков отключается (во время нормальных операций диски будут зеркалироваться по трем направлениям). В этом случае резервное копирование в режиме on-line может продолжаться после копирования на ленту, что обеспечивает в случае необходимости очень быстрое восстановление. Этот дополнительный набор зеркальных дисков мог бы быть заново подключен перед следующей контрольной точкой, обеспечив достаточно времени (примерно 30 минут), которое позволит этому набору зеркальных дисков синхронизоваться с зеркальными дисками, работавшими в режиме on-line.
Большинство пользователей выполняют полное резервное копирование ежедневно. Полагая, что резервное копирование выполняется на тот случай, когда понадобится восстановление, важно рассмотреть составляющие времени восстановления. Оно включает время перезаписи (обычно с ленты) и время, которое требуется для того, чтобы выполнить изменения, внесенные в базу данных с момента резервного копирования. Учитывая необходимость средств такой "прокрутки" вперед, очень важно зеркалировать журналы и журналы архивов, которые и делают этот процесс возможным.
В рабочей среде, где большое количество транзакций выполняют записи в базу данных, время, требуемое для выполнения "прокрутки" вперед от последней контрольной точки может существенно увеличить общее время восстановления. Это соображение само по себе существенно для определения частоты резервного копирования.
Выполнение процедур резервного копирования должно соответствующим образом отслеживаться, чтобы гарантировать, что они завершились успешно. Также важно документировать и тестировать процедуры восстановления. Момент аварии- не слишком удачное время для обнаружения того, что в стратегии резервного копирования пропущены некоторые ключевые элементы.
Результаты испытаний многих систем на тестах TPC-A, TPC-B, TPC-C и TPC-D продемонстрировали, что на сегодняшний день имеются все предпосылки (необходимая производительность и соответствующее ПО) для полного переноса приложений оперативной обработки транзакций и систем поддержки принятия решений с мэйнфреймов на системы, построенные на базе микропроцессоров. При этом одной из актуальных задач является выбор аппаратно-программной платформы и конфигурации системы.
Оценка конфигурации все еще остается некоторым видом искусства, но к ней можно подойти с научных позиций. Для выполнения анализа конфигурации система (под которой понимается весь комплекс компьютеров, периферийных устройств, сетей и программного обеспечения) должна рассматриваться как ряд соединенных друг с другом компонентов. Ограничения производительности некоторой конфигурации по любому направлению (например, в части организации дискового ввода-вывода) обычно могут быть предсказаны исходя из анализа наиболее слабых компонентов.
Поскольку современные комплексы почти всегда включают несколько работающих совместно систем, точная оценка полной конфигурации требует ее рассмотрения как на макроскопическом уровне (уровне сети), так и на микроскопическом(уровне компонентов или подсистем).
1. M.T. Franklin, E.H. Welbon. POWER2: Performance Measurement and Analysis of TPC-C, COMPCON 94, IEEE 1994.
2. J. Gray, C. Nyberg. Desktop Batch Processing, IEEE 1994.
3. Digital" s 21164 Reaches 500 MHz, Microprocessor Report, V. 10,# 9, July, 1996.
4. А.А. Волков. Тесты TPC.- СУБД, #2, 1995.
5. Г.М. Ладыженский. Tuxedo System: разработка систем клиент-сервер. - СУБД, # 1-2,1996.
В.З. Шнитман,Системы Управления Базами Данных · # 5-6/96