Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Майкл Стоунбрейкер: Моя десятка основных утверждений о хранилищах данных

Оригинал: Michael Stonebraker. My Top 10 Assertions About Data Warehouses. BLOG@CACM, August 26, 2010
От переводчика: малый катехизис патриарха баз данных

Среди десяти утверждений, содержащихся в этой заметке Майкла Стоунбрейкера, нет каких-либо открытий. Все они понятны и практически неоспоримы. Однако, по всей видимости, с ними согласны не все игроки рынка хранилищ данных, коль скоро автор решил их опубликовать. Во всяком случае, на мой взгляд, эта "горячая" десятка утверждений должна быть чрезвычайно полезна многочисленным разработчикам и пользователям хранилищ данных. Кстати, заметку Стоунбрейкера можно было бы считать планом-проспектом новой книги, посвященной хранилищам данных. Кто знает, может быть автор ее еще и напишет...

Сергей Кузнецов

Хранилища данных и бизнес-аналитика лежат в основе все более расширяющихся маркетинговых войн, которые, по-видимому, активизировались после недавнего выпуска компанией Oracle программно-аппаратного комплекса Exadata. В этой заметке представлена моя реакция на эту ситуацию в виде десятки основных утверждений на данную тему. Прошу заметить, что я имею финансовые интересы в нескольких компаниях, специализирующихся в области технологии баз данных, и это может оказывать влияние на мои соображения. Это всегда следует иметь в виду.

Утверждение 1. Схемы "звезда" и "снежинка" полезны в мире хранилищ данных.

Коротко говоря, в хранилище данных хранится крупная коллекция фактов. Подавляющее большинство этих фактов относится к категории "5W" (who (кто), what (что), where (где), when (когда), why (почему)), и каждый факт сопровождается набором атрибутов. Например, в типичной компании розничной торговли сохраняются факты об исторических транзакциях: о клиентах (кто), о розничных магазинах (где), о времени продажи (когда), о купленных продуктах (что), о времени продажи (когда), а также атрибуты покупки (например, цена, налог с продажи, использованные кредитные карты и т.д.).

Такие данные следует организовывать так, как показано на рис. 1:

Рис. 1. Диаграмма схемы "звезда".

Такая схема называется схемой "звезда" (star schema) с центральной таблицей фактов (Fact) и окружающими ее таблицами измерений (Dimension). Если бы магазины организовывались в виде групп, то в схеме "звезда" появилась бы еще одна таблица между таблицами Store и Fact, и она превратилась бы в схему "снежинка" (snowflake schema). Схемы "звезда" и "снежинка" понятны, просты, позволяют легко распараллеливать работы и обычно обеспечивают очень высокую производительность приложений систем управления базами данных (СУБД).

Если вы являетесь проектировщиком хранилища данных и предлагаете что-либо, отличное от схемы "снежинка", то, вероятно, вам стоит пересмотреть свое решение.

Однако часто появляются схемы с большим числом атрибутов в таблице фактов; 40 атрибутов – это обычная практика, а нередко встречаются и 200 атрибутов. Администраторам современных хранилищ данных приходится "вставать на голову", чтобы заставить работать с такими "толстыми" таблицами фактов имеющиеся у них реляционные СУБД (РСУБД). Это приводит к моему второму утверждению.

Утверждение 2. Со временем на рынке хранилищ данных будут доминировать поколоночные хранилища, вытеснив хранилища таблиц по строкам

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

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

По этим причинам со временем поколоночные хранилища, очевидно, выиграют. Заметим, что почти во всех традиционных РСУБД (включая Oracle, SQLServer, Postgres, MySQL и DB2) таблицы хранятся по строкам. Кроме того, в системах, в которых реализуется кодирование отдельных блоков в стиле PAX (наберите в своем Web-браузере "Anastassia Ailamaki", чтобы получить список публикаций на эту тему), таких как Exadata, всего лишь меняется внутренняя структура блока, что не отменяет указанных выше преимуществ поколоночного хранения таблиц.

Утверждение 3. Подавляющее большинство хранилищ данных не претендует на использование основной или флэш-памяти.

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

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

Утверждение 4. На этом рынке будут повсеместно распространены системы массивно-параллельной обработки (massively parallel processor, MPP).

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

Утверждение 5. Осмысленны только системы, лишенные "ручек управления" ("no knobs").

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

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

Утверждение 6. Специализированные системы (appiance) должны быть "только программными".

За свою 40-летнюю карьеру профессионала в области СУБД мне так и не удалось увидеть какую-либо специализированную аппаратную архитектуру (так называемую машину баз данных), которой удалось бы выиграть.

Другими словами, вы можете купить процессор общего назначения у основных поставщиков микропроцессоров или специализированный процессор у какого-либо поставщика машин баз данных. Поскольку объем производства у поставщиков процессоров общего назначения в 10000, а то в 100000 больше, чем у поставщиков специализированной аппаратуры, их цены на порядки ниже. Чтобы победить в соревновании за соотношение "цена-производительность", поставщик специализированного оборудования должен обеспечить превосходство в скорости своих аппаратных средств, по крайней мере, в 20-30 раз.

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

Иначе говоря, я думаю, что работа по созданию специализированной системы состоит в комлектовании – заблаговременном конфигурировании аппаратуры общего назначения и заблаговременной установки на ней СУБД. Это приводит к получению чисто программной специализированной системы.

Утверждение 7. При наличии гибридных рабочих нагрузок "безразмерный" подход ("one-size fits all") не обеспечивает достижения наивысшей эффективности.

Возможны два варианта поддержки рабочей нагрузки, частично являющейся транзакционной (online transaction processing, OLTP), а частично аналитической:

  1. использовать СУБД общего назначения для хранения данных обоих видов;
  2. использовать две системы, сервер OLTP и сервер хранилищ данных, соединенные высокоскоростной аппаратурой обмена данными, которая позволяет перемещать операционные данные в хранилище данных.

Хранилища таблиц по строкам не подходят для приложений хранилищ данных (см. Утверждение 1). Поколоночные хранилища оптимизируются для хранилищ данных и не подходят для OLTP. Так что ни один из этих подходов не является кандидатом в "безразмерное" решение. Наоборот, имеется ряд интересных идей насчет того, как можно ускорить OLTP, включая SQL-ориентированные системы баз данных в основной памяти, более эффективное использование кэшей основной памяти, системы с примененем флэш-памяти и т.д. Я полагаю, что включение поколоночного хранилища в двухсистемную конфигурацию обеспечит решение, примерно в 50 раз более быстрое, чем решение 1. Другими словами, каждая из двух специализированных систем может оказаться в 50 раз быстрее, чем "безразмерная" система в решении 1.

Возможностью 50-кратного ускорения нельзя пренебрегать.

Утверждение 8. Практически для всех установок хранилищ данных требуется высокий уровень доступности (high availability, HA).

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

Вместо этого в большинстве установок используются репликация и переключение на резервную систему при повреждении основной копии данных (в стиле Tandem computers). После этого поврежденную копию можно восстановить путем выполнения фоновой задачи. Т.е. для восстановления используется HA, а не журнал. Очевидно, что для этого требуется поддержка HA со стороны СУБД; в противном случае приходится обременять DBA кодированием аналогичных средств вручную. Кроме того, если тактика восстановления базируется на репликации, исчезает потребность в ведении журнала. Тем самым, устраняется источник накладных расходов.

Утверждение 9. В СУБД следует обеспечивать оперативную поддержку расширения набора ресурсов (online reprovisioning).

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

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

Утверждение 10. В мире СУБД виртуализация часто приводит к появлению проблем производительности.

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

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

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

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

То же замечание применимо и к сетям хранения данных (storage area network, SAN). Если массивно-параллельная СУБД работает с SAN, то локальный ввод/вывод заменяется удаленным вводом/выводом с использованием какой-нибудь соединительной сети, поддерживаемой поставщиком SAN. И в этом случае тоже могут потребоваться значительные расходы.

Комментарии

Саша, Fri Dec 21 19:00:25 2012:
Очень интересно. Спасибо!
К., Tue Jan 18 19:03:56 2011:
Павел, согласен с вами. А что думаете по поводу ООП? Майкл написал в свое время статью о нем. Есть на ЦИТе.
Павел, Tue Jan 18 15:36:09 2011:
Вначале отнесся со скепсисом к очередному "пророчеству гуру". Но когда внимательно изучил текст, то согласился в основном со всеми тезисами. Полезная выжимка из опыта конкретного человека. Я даже задумался о том, что "облачные системы" популяризируются на радость производителям железа, для них повышение стоимости только в радость.
аноним, Sun Nov 7 14:46:06 2010:
Майкл прав, почти во всем я с ним согласен. Единственное, что меня озадачило, это прогноз о доминировании поколоночных БД. Надо подумать над этим.
Vladisgol, Sat Nov 6 13:38:36 2010:
2 Анон, Сбт 06 Ноя 2010 11:52:48:
> Анон, эти перспективы совершенно очевидны для любого, мало-мальски шарящего в предметной области.

Что это? Рекурсия?
аноним, Sat Nov 6 13:37:41 2010:
2 Анон, Сбт 06 Ноя 2010 11:52:48:
> Анон, эти перспективы совершенно очевидны для любого, мало-мальски шарящего в предметной области.
Анон, Sat Nov 6 11:52:48 2010:
Анон, эти перспективы совершенно очевидны для любого, мало-мальски шарящего в предметной области.
аноним, Sun Oct 17 19:16:56 2010:
Десять причин по которым я выбираю "Тайд".
аноним, Sun Oct 17 18:30:52 2010:
Перспективы, прямо скажем, не сильно розовые. Пляски с бубном не отменяются.
аноним, Sun Oct 17 17:40:01 2010:
Спасибо.

Ваш комментарий

Имя:

Текст комментария (HTML-теги не допускаются):

Новости мира IT:

Архив новостей

Последние комментарии:

Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...