СУБД

Хранилища данных (ХД) для бизнеса ценны прежде всего возможностью всестороннего анализа находящейся в них информации с целью выявления разного рода связей и закономерностей, а также для формирования отчетности. Однако запросы к СУБД со стороны приложений оперативного управления, таких, как бухгалтерский и складской учет, и аналитических приложений существенно различаются (см. врезку "О природе запросов"). Практически все современные СУБД, например IBM DB/2, MS SQL Server, Oracle Database, создавались для применения в первую очередь в приложениях оперативного управления, где и проявляют себя наилучшим образом. Но их производительность существенно снижается на аналитических задачах, причем тем значительнее, чем больший объем данных требуется обработать. В ряде случаев это приводит к практической невозможности выполнить анализ слишком большого количества информации.

О природе запросов

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

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

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

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

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

Диски, строки и столбцы

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

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

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

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

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

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

    

Компания Sybase (www.sybase.ru) предлагает для решения этих проблем воспользоваться при создании ХД ее СУДБ Sybase IQ. Эта система специально создана для работы с аналитическими приложениями, что обеспечивает ей максимальную производительность на таких задачах. Так, по словам технического специалиста Sybase Андрея Хромова, при тестировании Sybase IQ в одной московской страховой компании, использующей СУБД Oracle 9i, были получены следующие результаты: размер базы данных (две основные таблицы на 23 и 11 млн. записей соответственно и несколько дополнительных сравнительно небольших таблиц с общим объемом исходных, так называемых "сырых", данных 7,9 Гб) сократился почти в 4,3 раза (в Oracle он составил 25,6 Гб, а в Sybase IQ - 5,9 Гб), а время выполнения запросов - от 7 до 187 крат (выполнялись запросы типа "сальдо по счету на дату по субсчетам, по валюте", "обороты по счету за период по субсчетам, по валюте"; время их выполнения в Oracle колебалось от 26 до 906 с, в Sybase IQ - от 0,7 до 9,3 с).

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

Мнение эксперта

Дмитрий Безруков, директор лаборатории решений компании "ФОРС - Центр разработки" (www.fdc.ru), занимающейся разработкой и внедрением решений на основе технологий Oracle, так прокомментировал показатели, заявленные фирмой Sybase: " При выполнении аналитических задач система Sybase IQ действительно обладает неоспоримыми достоинствами по сравнению с традиционными СУБД. Вместе с тем она значительно проигрывает им при оперативной обработке транзакций (OLTP). Там, где большому количеству пользователей требуется одновременно осуществлять массированный ввод данных и хранить их, СУБД Oracle по праву является номером один в мире. Однако нельзя забывать, что производительность системы во многом зависит от того, как организован поиск информации. Если правильно структурировать данные, оптимально организовать поисковые структуры в таблицах (индексы bitmap, materialized views и др.) и грамотно произвести их секционирование, то СУБД Oracle отнюдь не будет уступать Sybase IQ. На наш взгляд, для полной корректности сравнения следовало бы провести более глубокое тестирование этих двух систем при условии изменяющихся параметров".

Однако спрашивать, что лучше: Sybase IQ или, к примеру, Oracle Database, примерно так же корректно, как сравнивать самосвал и лимузин: у них разный круг применения, и достоинства Sybase IQ при обработке запросов, характерных для аналитических задач, станут недостатками при попытке применить ее в оперативных приложениях, для которых прекрасно подходят традиционные СУБД. Просто для каждой задачи нужно использовать наиболее подходящий инструмент.