Содержание


«Экстремальные» базы данных: Cамые большие и самые быстрые

Чему учит нас опыт работы с «экстремальными» базами данных

Comments

Серия контента:

Этот контент является частью # из серии # статей:

Следите за выходом новых статей этой серии.

Этот контент является частью серии:

Следите за выходом новых статей этой серии.

Читать статью в нашем интерактивном цифровом формате!

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

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

Что значит «сверхбольшая»

Неуклонный рост информационных потоков требует соответствующего увеличения общедоступных и коммерческих баз данных. Всего четыре года назад по данным WinterCorp самыми крупными в мире считались базы данных с объемом хранилища порядка 100 ТБ. База Yahoo! стала первой базой данных за десятилетнюю историю исследований, которая преодолела рубеж в 100 ТБ.

Какая же база данных в наше время, когда объемы хранимой цифровой информации постоянно растут, может претендовать на определение «сверхбольшая»? Общего стандарта распределения баз данных по размерам не существует. К тому же, необходимо иметь в виду, что размер хранилища данных не является сегодня основной характеристикой базы данных, не менее важным фактором является ее управляемость. Одно из возможных определений «сверхбольшой» базы принадлежит доктору Роберту Холлебеку (Robert Hollebeek), профессору физики университета Пенсильвании, одному из основателей проекта National Scalable Cluster Project и обладателю нескольких национальных премий за разработки в области распределенных кластерных систем и исследования данных. Холлебек утверждает, что пять лет назад база данных объемом в несколько терабайт могла претендовать на звание «сверхбольшой». Сегодня для этого требуется наличие хранилища объемом в несколько петабайт. «Возможно и другое определение сверхбольшой базы данных – это база, чей индекс не помещается в физической памяти, даже в терабайтной памяти суперкомпьютера или компьютерного кластера», - продолжает Холлебек. База данных с индексами такого порядка является «сверхбольшой». Использование «сверхбольших» баз данных порождает ряд проблем с точки зрения производительности и администрирования.

Холлебек также утверждает, что «сверхбольшой» может считаться такая база данных, для которой трудно подобрать нужный объем аппаратных ресурсов. «Если у вас тысячи дисков или серверная, полная стоек с параллельными машинами, то такой системой становится трудно управлять».

Мануэль Гомес Бюрриель (Manuel Gomez Burriel), лауреат программы IBM Information Champion и сотрудник Испанской конфедерации сберегательных банков Confederacion Espanola de Cajas de Ahorros (CECA), согласен с тем, что управляемость может использоваться в качестве критерия, позволяющего определить, какие базы данных являются «сверхбольшими», а какие – вполне обычными крупными базами данных. «Стандартные задачи администрирования перестают укладываться в определенные временные окна», – говорит Гомес. Восстановление базы данных в случае сбоя может занять несколько часов, в то время, как необходимо уложиться в несколько минут. Производительность также оказывается под вопросом, так как база данных слишком велика и никакая ее более или менее значительная часть не может быть загружена в оперативный кэш. Обработка вполне стандартных запросов приложений на получение данных может потребовать совершенно неприемлемое количество циклов ЦПУ.

Портреты базы данных

Опыт в сфере управления данными, полученный при детальном изучении архитектуры и принципов работы одной «сверхбольшой» базы, может с успехом использоваться при работе с другими базами данных, крупными и не очень. Холлебек был ведущим техническим специалистом Национального цифрового архива маммографии (NDMA, National Digital Mammography Archive), системы, рассчитанной на базу данных, увеличивающуюся на 28 петабайт в год. Благодаря фондам, выделенным Национальным институтом здравоохранения США (U.S. National Institutes of Health), NDMA разработал распределенную сеть систем для хранения медицинских данных, снимков и результатов исследований. Система использовалась в качестве хранилища результатов маммографии, снимков, полученных в результате магнитно-резонансного исследования и других данных, которые соответствовали каждому случаю заболевания и могли составлять до гигабайта данных. В архиве хранились данные миллионов пациентов. Помимо вопросов хранения и организации доступа к большим объемам информации, NDMA пришлось столкнуться с проблемой несвязанных данных, хранящихся в географически распределенных системах – задачей, которую приходится решать практически всем глобальным предприятиям. Для того чтобы связать четыре научно-исследовательских медицинских центра, участвующих в проекте, NDMA создал защищенные линии для передачи зашифрованных данных. Каждый медицинский центр имел свою точку входа с аппаратным обеспечением для шифрации данных. Данные по сети передавались по специальному протоколу, предназначенному для работы с большими блоками информации.

«Наш проект был весьма масштабным, и мы не могли позволить себе потерять какую-либо медицинскую информацию. Нам требовалась сверхнадежная технология, гарантирующая высокую производительность и параллелизм, так как наша структура основывалась на использовании кластеров параллельных машин», – рассказывает Холлебек. «Система должна была обладать высокой отказоустойчивостью, поскольку мы не могли допустить, потери или сбоя индексных таблиц». Для индексных таблиц NDMA использовал программное обеспечение IBM DB2 Parallel Edition. Графические данные хранились в одноуровневых базах данных на параллельных дисковых массивах под управлением «родных» файловых средств операционной системы, в качестве которой был выбран Linux.

Уроки NDMA

Основываясь на своем опыте работы в NDMA, Холлебек выработал несколько общих рекомендаций для работы со «сверхбольшими» базами данных, соединенными с помощью глобальных сетей (WAN):

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

Что значит «сверхбыстрая»

Точно так же, как со временем изменяются наши представления о «сверхбольших» базах данных, понятие «сверхбыстрой» базы изменяется по мере того, как развитие технологий расширяет границы возможного. «Обычно скорость работы базы данных измеряется количеством транзакций в секунду. При этом миллион транзакций в секунду является очень высокой скоростью. Однако с появлением новых технологий понятие «транзакция» определяет лишь один вполне стандартный класс обращений к базе данных», – говорит Карл Олофсон (Carl Olofson), вице-президент по исследованиям рынка решений для разработки и развертывания приложений компании IDC. «В будущем появятся новые классы обращений, стирающие различия между базой данных и памятью. К тому времени извлечение данных из базы будет означать перенаправленный доступ к определенным адресам памяти, а не формальное обращение к базе данных и выполнение транзакции. Безусловно, новые классы обращений действительно будут сверхбыстрыми». Говоря об общем определении «сверхбыстрых» баз, Олофсон поясняет, что «цель любой системы – обеспечить такое быстродействие базы данных, которое не снижало бы скорость работы приложения, т.е. обеспечить скорость доступа к данным на уровне скорости работы приложения».

Такого же мнения придерживается и Гомес, определяя «сверхбыструю» базу данных как «достаточно быструю для того, чтобы предоставлять необходимую информацию в соответствии с согласованными с клиентами SLA». «Самые быстрые базы данных обращаются непосредственно к данным в памяти, если это возможно. Одно из наших приложений, функционирующее как часть платежной системы, использует IMS и Fast Path Solution, а также корпоративную подсистему хранения данных и обеспечивает время отклика менее чем 20 миллисекунд на одну транзакцию, и это при условии, что приложение использует до 14 баз данных для получения клиентской информации», – продолжает Гомес.

Секундная задержка – это слишком долго

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

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

Подобная скорость операций предъявляет высокие требования к быстродействию внутренних баз данных, которые, как правило, образуют многоуровневую систему хранения и доступа к данным. Во многих случаях в качестве внутренней базы данных используется базы данных на мэйнфреймах, например IMS, иерархическая система управления базами данных IBM на мэйнфреймах. В качестве первоначальной высокоскоростной среды обработки данных используется оперативный кэш, а в качестве основной базы для хранения данных – многоуровневая структура на мэйнфреймах. Клиенты, нуждающиеся в сверхскоростных финансовых системах, являются основными инвесторами подобных многоуровневых решений.

Новейшие разработки для взрывного роста производительности баз данных

Очевидно, что мере появления и развития новых технологий, требования к быстродействию систем будут только возрастать, так что производители продолжают искать новые способы повышения быстродействия баз данных. Одно из наиболее популярных сегодня направлений исследований сосредоточено на решении проблемы традиционно слабого звена в цепи передачи данных – жесткого диска. Решения, использующие кэширование данных в оперативной памяти, такие как IBM solidDB, переносят операции по работе с данными из сравнительно медленной памяти на жестком диске в сравнительно быструю RAM, значительно сокращая тем самым время отклика. Более подробный обзор баз данных solidDB вы можете найти в статье «solidDB and the Secrets of Speed» в этом же выпуске.

Другое многообещающее решение основано на использовании SSD (solid-state drive) или Flash-памяти, которая в настоящее время превратилась в своеобразную прослойку между оперативной и дисковой памятью. По мере удешевления Flash-памяти, возможности и преимущества ее использования в качестве хранилища баз данных среднего размера неуклонно возрастают (дискуссию о возможностях повышения производительности DB2 за счет использования SSD вы можете найти в статье «Unleashing the Value of Solid-State Drives for DB2 Workloads», опубликованной в этом выпуске).

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

Наконец, ряд разработчиков используют принципиально иной подход, так называемую потоковую обработку данных (stream processing). Суть этого метода состоит в том, что данные обрабатываются и анализируются в процессе их получения, не дожидаясь, пока они будут сохранены в базе данных. Такой подход используется в IBM InfoSphere Streams, что позволяет отслеживать одновременно несколько потоков данных и выполнять практически мгновенный анализ, обновляя аналитические данные по мере поступления новой информации. Подробное описание InfoSphere Streams в действии вы можете найти в статье "Smarter is: Boosting the IQ of Galway Bay", опубликованной в журнале IBM Data Management, выпуск 3, 2009.

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=587344
ArticleTitle=«Экстремальные» базы данных: Cамые большие и самые быстрые
publish-date=11152010