Что такое аналитический сервер Sybase IQ.

добавлено: 15 апр 11
понравилось:0
просмотров: 3856
комментов: 0

теги:

Автор: AnyaNartova

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


Предпосылки

Итак, давайте начнем с самого начала, а именно с того момента, когда в компании начинают возникать задачи, связанные с аналитической обработкой данных. Начинается все это обычно с необходимости создавать отчеты по результатам деятельности компании. Поначалу все это выглядит довольно просто: ну чего там – посчитал суммы, вывел общие показатели за указанный период, ну там формулы кое-какие кое-где более сложные применил. Да, где-то приходится поднапрячься и подумать, но в целом – ничего, в общем-то, сложного. По началу.
Дальше компания проходит через серию стадий, связанных с увеличением объема данных и сложности отчетов, и на собственной шкуре изучает как «хорошо» аналитические запросы влияют на текущую работу пользователей. IT служба, в свою очередь, строит море индексов/агрегатов, занимается глубоким тюнингом базы, отлаживает очередные отчеты, результаты каждого запуска которых порой приходится ждать по нескольку часов… короче – полный набор удовольствий.
Где-то в середине всего этого процесса созревает понимание – OLTP нагрузка с запуском аналитических отчетов не сочетается ну никак, - нужно отделять одно от другого и выносить аналитику на отдельный сервер. И на первом этапе это действительно спасает ситуацию: оперативная база работает, как положено, отчетный сервер с завидной регулярностью генерирует свои отчеты. Все счастливы.
Надо отметить, что это решение не сильно сокращает объем работы IT службы. Им приходится держать теперь уже два сервера, заниматься переносом данных, по-прежнему строить море индексов и агрегатов (только теперь еще и на отчетном сервере) и тратить тот же громадный объем времени на построение отчетов (помним, что многие из них отрабатывают по нескольку часов). Да, им не приходится заниматься совмещением очень слабо совместимых между собой вещей и это несомненный плюс.
Какое-то время все это живет в таком состоянии, но при этом происходит параллельно две вещи: с одной стороны растет объем данных, увеличивается время на перенос данных из оперативной базы в хранилище и время, необходимое на построение отчетов. Необходимость построения большого числа индексов и агрегатов на отчетном сервере еще больше увеличивает объемы базы, приводя к так называемому эффекту «взрыва данных», - когда за счет наличия огромного числа дополнительных структур, объем базы в хранилище увеличивается по сравнению с исходным в несколько раз. И вот мы уже вынуждены покупать более дорогие сервера и дисковые стойки, заниматься охлаждением всего этого добра… Это все стоит денег.
Второй параллельный процесс – рост аппетитов заказчика. Как минимум, - увеличивается количество и сложность требуемых отчетов, что требует от IT службы очередных усилий по их реализации. Однако сегодня этого уже недостаточно – сейчас заказчик хочет иметь возможность работы с данными в свободном режиме, задавая те вопросы, которые ему хочется. Иными словами, - он хочет ad hoc запросы. Как говорят – за ваши деньги все чего вы хотите, и были придуманы системы, которые представляют данные пользователю в удобном для его понимания виде и предлагают ему возможность вертеть ими, как тому заблагорассудится. Я говорю о всевозможных системах типа Business Objects, MicroStrategy и т.п. Такому инструменту довольно просто подвесить базу на неопределенное время, если он настроен на прямую работу со всем объемом данных хранилища. Это происходит потому, что такому инструменту ничего не стоит создать запрос, который объединит в себе море таблиц и кучу группировок и сортировок, операторов not in, ну и, конечно же, обязательно не попадет в индексы!
Вот здесь мы и приходим к преобразованию данных в хранилище таким образом, чтобы их было удобно анализировать, хранению только агрегатов, а не детальных данных, потому что все хранить дорого, и использовать сложно, выделению отдельных витрин данных по предметным областям, построению OLAP кубов… короче ко всему тому, что из себя представляет современная аналитика. Все это дорого, долго и сложно.
Между тем, если взглянуть на проблему немного под другим углом, можно увидеть одну очень небольшую, но вместе с тем очень важную деталь. Давайте повнимательнее взглянем, в чем заключается принципиальное различие в характере работы базы, которая занимается обработкой текущей бизнес-транзакции (OLTP нагрузка) и базой, которая считает аналитические запросы (DSS нагрузка).
В OLTP системе обновление базы данных происходит немедленно после получения бизнес-транзакции: поступление заказа сокращает остаток на складе, продажа акций обновляет их цену, происходит подтверждение резервации авиабилетов. Транзакционная обработка сохраняет бизнес-записи актуальными на момент поступления или передачи транзакции в систему. В подавляющем большинстве случаев для выполнения этих операций нам нужна точечная информация о каком-то конкретном предмете или явлении, но при этом нам нужны все данные по нему. Иными словами OLTP нагрузка характеризуется очень частыми обновлениями и изменениями данных, и точечными выборками данных, при которых достается вся строка.
Аналитические приложения отличаются от OLTP. В первую очередь они сосредоточены на чтении данных, а не на их обновлении и изменении, и, как правило, имеют дело со сложными запросами, выполняемыми по большому объему данных. В качестве примеров могут выступать сложные отчеты, агрегация данных (анализ, выборка по целевым группам и т.п.), сложная продвинутая аналитика и т.п. Аналитические запросы обычно фильтруются по ряду условий и выбирают данные из нескольких таблиц, но, обычно, в качестве результата запрашивается только небольшое число колонок.
В OLTP базах работа ведется со строками данных. В памяти информация располагается построчно, - т.е. данные, относящиеся к одной строке располагаются рядом. И это вполне понятно, поскольку транзакционные системы обычно имеют дело со строками и работают практически со всеми атрибутами строки. Если мы имеем дело с аналитическим запросом, то нам нужна лишь небольшая часть этой строки, но при этом мы имеем дело со всеми строками таблицы. Если такой запрос не попадает в индексы, для него не создано представление, то это чрезвычайно дорогая операция для БД, - в первую очередь с точки зрения нагрузки на подсистему ввода/вывода, потому что для прочтения нужных данных, база вынуждена тянуть за собой все данные строки даже тогда, когда они ей совершенно не нужны. Ввод/вывод – это бутылочное горлышко с точки зрения производительности СУБД.
Вот в этом месте и возникает идея развернуть базу перпендикулярно и сохранять данные не по строкам, а по колонкам. То есть на странице, рядом друг с другом будут располагаться не данные одной строки, а данные одной колонки таблицы. Если мы так сделаем, то сразу получим:
  • Возможность сохранять и читать каждую колонку в отдельности;
  • Поскольку данные одного типа, они легко сожмутся;
  • В запросах не придется выбирать лишние данные, что существенно сократит нагрузку на ввод вывод;
  • Данные можно сразу хранить в виде индексов.
    Именно с этих идей и начался сервер Sybase IQ.

    Результат

    Произошло это в начале 90х готов прошлого века. Sybase IQ был разработан компанией Expressway, которая была приобретена Sybase в 1994 году. При создании сервера разработчики поставили себе цель – сделать движок для эффективной обработки огромных объемов данных, - задачи повторить традиционную транзакционную СУБД не ставилось. Именно это обстоятельство позволила уйти от общепринятых норм, и реализовать принципиально иную архитектуру, - что и дало существенный выигрыш в производительности и эффективности хранения данных (в первую очередь – это та самая пресловутая организация данных по колонкам, сжатие данных и особенность построения индексов). Однако, то что было сделано на тот момент, представляло собой некий академический вариант, не очень пригодный для использования широким кругом пользователей. Именно поэтому, Sybase провел ряд работ, сутью которых являлось «натягивание» на существующий аналитический движок интерфейса стандартной СУБД. Дабы не изобретать велосипед, для этой цели была взята уже существующая на данный момент база – Sybase ASA. Получившийся гибрид и является тем, что сейчас называется Sybase IQ – аналитический движок внутри и стандартная СУБД с обычным знакомым интерфейсом снаружи. Разумеется, с тех пор много воды утекло, и много чего было сделано и добавлено, но принципиальная основа, отличающая данное решение была заложена еще тогда.
    Итак, что же мы имеем в итоге, так сказать, на практике?
    Самое главное – это конечно скорость. Время обработки аналитических запросов на порядки ниже, чем в традиционных базах. При этом не требуется дополнительная настройка сервера для того чтобы задать какой-нибудь очередной непредвиденный вопрос, - поскольку принцип индексирования в Sybase IQ таков, что для правильного построения индексов не обязательно знать какие будут запросы – достаточно информации о самих данных. В результате мы имеем возможность ad hoc анализа, и таковую возможность имеют довольно большое количество пользователей параллельно. Если мощности не хватает, то достаточно просто добавить очередной узел в кластер (он называется IQ Multiplex) и все. Масштабируется Sybase IQ легко и практически не теряет при этом в производительности (заявлено, что максимальное количество узлов - 12000), да и железо для этого потребуется самое обычное, что тоже немаловажно.
    Второе – это объем данных, который получается в итоге. Поскольку данные, хранящиеся по колонкам, сжимаются легко и эффективно, объем данных в Sybase IQ после постройки всех индексов не превышает, а, как правило, меньше, чем исходный объем сырых данных. Причем реально существуют примеры, когда коэффициент сжатия достигал 85%. По этому поводу сервер в свое время попал в книгу рекордов Гиннеса, - загрузили в базу 1PB (петабайт) сырых данных, и в результате получилось 160TB, а после постройки всех индексов получилось 260TB. Здесь стоит задуматься, сколько денег можно сэкономить на одних дисковых стойках.
    Третье – это простота администрирования: нет необходимости в подстройке базы под конкретные запросы, нет необходимости обновления статистики, кластер делается легко, масштабирование организуется легко. За счет серьезного увеличения скорости исполняемых запросов, проще становится разрабатывать отчеты.
    Ну вот, это собственно, основные моменты. Конечно, есть еще много всего – в первую очередь это индексы, нужно освятить немаловажный вопрос загрузки данных, конечно IQ устанавливается на различные операционные системы, умеет работать с разными соединениями (ODBC, JDBC, Open Client, Oledb), поддерживает различные среды разработки (C, C++, Java, PHP, Perl, Python, и .NET). Конечно, с момента создания сервер не стоял на месте, было очень много чего добавлено и расширено.

    Итог

    Отдельный вопрос – оправдал ли себя такой подход? И здесь я могу с уверенностью сказать, - да, оправдал. 28 января 2011 года Gartner опубликовал свой ежегодный отчет по рынку СУБД для хранилищ данных: «Magic Quadrant for Data Warehouse Database Management Systems». Sybase IQ в лидирующем квадранте, второй год подряд. Буквально через несколько дней свой отчет выпустил IDC, и там сервер тоже среди лидеров.
    Этот факт доказывает, что решение признано и его рассматривают как серьезного конкурента, как во всем мире, так и в СНГ.
    Лично мне, очень приятно видеть, что принципиально иной подход к построению аналитической СУБД с каждым годом оправдывает себя все больше и больше. Хранение данных по колонкам, сжатие данных и уникальные технологии индексирования – это три столпа из которых зародилась и на которых держится Sybase IQ. Когда мы в начале нового тысячелетия начали предлагать IQ в России и СНГ, поначалу нам пришлось столкнуться с тотальным непониманием и недоверием. Заверения из разряда «размер базы со всеми индексами будет меньше, чем размер исходных данных», «в нашей СУБД скорость исполнения запросов увеличивается в десятки, а иногда и в сотни раз», «вы сможете выполнять любые, непредусмотренные заранее запросы» - все это воспринималось как нечто из области фантастики, и нам раз за разом приходилось доказывать свои слова на практике.
    Сегодня, подобными фразами уже никого не удивишь. В своем отчете Gartner, перечисляя ожидания пользователей в 2010 году и анализируя тенденции рынка в ближайшем будущем, указывает более широкое индексирование и хранение данных по колонкам в качестве отдельного пункта. А это означает, что наши усилия не прошли даром: преимущество такого подхода при решении аналитических задач стало настолько очевидным, и востребованным пользователями, что сегодня появился целый ряд решений-новичков в этой области, а многие поставщики СУБД начинают включать возможность хранения данных по колонкам в свои решения.
    Ну что тут можно сказать? Мы в лидерах и это очень приятно. Среди решений с поколоночным методом хранения – мы уже не единственные, но мы – первые, и не только в историческом смысле этого слова, но и на практике. Почему? Потому что мало расположить данные по колонкам, нужно еще научиться сжимать данные, правильно их индексировать, создавать правильные схемы данных в такой СУБД и еще много чего делать правильно. Научиться все это, прочувствовать все это, можно только пройдя длинный путь и став экспертом в решениях с хранением данных по колонкам, - только это дает возможность освоить все тонкости этого подхода и понимание того, как извлечь максимум из такой архитектуры. Мы этот путь прошли.
  • Комментарии




    Необходимо войти на сайт, чтобы оставлять комментарии