Управление банком данных белков и нуклеиновых кислот при помощи DB2 pureXML

Банк данных белков и нуклеиновых кислот (Protein Data Bank – PDB) – это уникальный всемирный репозиторий данных о структурах белков. Данные PDB доступны в XML-формате, что обеспечивает гибкость, расширяемость и простоту обмена данными в сообществе исследователей-биологов. Анализ данных, хранящихся в PDB, помогает объяснять причины болезней, разрабатывать новые лекарства, изучать взаимодействия между различными белками. При этом одной из важнейших проблем является эффективное хранение и выборка этой информации с целью поиска нужных данных и их взаимосвязей. В этой статье рассматриваются способы использования гибридных возможностей DB2® (поддержка реляционных функций и функций pureXML®) для управления данными PDB и их анализа.

Герд Андерс, исследователь в области биоинформатики, IBM

Герд Андерс (Gerd Anders) – фотографияГерд Андерс (Gerd Anders) получил степень по вычислительной технике в Университете Гумбольдта, Берлин. Специализируется на биоинформатике и использовании системы баз данных для эффективного управления и обработки очень больших объемов данных в биологии. База PDB, основанная на DB2, – это важная составляющая его докторской диссертации, ставшая фундаментом для создания нескольких управляемых DB2 приложений и использования всего потенциала PDB. Кроме того, он занимался тестированием бета-версии DB2 9.5 для Linux, UNIX и Windows.



Маттиас Никола, технический специалист, IBM

Доктор Никола (Nicola) является ведущим техническим специалистом по производительности DB2/XML в Лаборатории IBM в Силиконовой Долине (Silicon Valley Lab). Он работает над всеми аспектами производительности XML в DB2, включая XQuery, SQL/XML и все возможности, присущие XML в DB2. Доктор Никола тесно сотрудничает с коллективами разработчиков DB2 XML, также как и с заказчиками и деловыми партнерами, использующими XML, помогая им в проектировании, реализации и оптимизации решений на XML. До начала работы в IBM Доктор Никола работал над производительностью информационных хранилищ в Informix Software. Он также участвовал в течение четырех лет в исследовательских и промышленных проектах по распределенным и реплицированным базам данных. Он получил докторскую степень по вычислительной технике в 1999 в Политехническом Университете Аахена, Германия.



25.04.2012

Введение

Банк данных белков и нуклеиновых кислот (PDB.org) – это всемирный архив данных о структурах биологических молекул, в основном белков. PDB управляется несколькими уполномоченными организациями, ответственными за пополнение, поддержку, обработку и свободное предоставление биологических данных научному сообществу. Для обеспечения гибкости, расширяемости и простоты обмена данные PDB хранятся в XML-формате. Этот XML-формат определен схемой XML Schema, известной как Protein Data Bank Markup Language (PDBML).

В состав хранимой структурной информации входят 3D-координаты атомов молекулы или молекул, из которых состоит белок. Эти координаты называются также 3-D-структурой или третичной структурой. Третичная структура белка тесно связана с его функцией. Таким образом, знание третичной структуры часто помогает понять функцию белка. Например, третичная структура может быть полезна для объяснения причин болезней или при разработке новых лекарств. Третичная структура может также использоваться для поиска в PDB взаимосвязей между белками.


Проблема

По состоянию на декабрь 2010 года в репозитории Protein Data Bank находилось 70000 записей (XML-документов), содержащих более 500 миллионов координат атомов. Общий размер несжатых данных составлял более 750 ГБ. Отдельные XML-документы в PDB имеют размер от нескольких мегабайт до более чем 1 ГБ. Поскольку в последние годы репозиторий быстро пополняется (рисунок 1), ожидается значительное увеличение его размеров. Поэтому поиск и анализ этой информации становится все более проблематичным.

Рисунок 1. Рост PDB за последние 20 лет
Рост PDB за последние 20 лет

Типичным подходом к анализу данных PDB является написание специального приложения или набора сценариев, выполняющих поиск PDBML-документов для конкретного узкоспециализированного исследования. Недостатки такого подхода:

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

Для решения этих проблем была выбрана СУБД DB2 V9.7.3 с pureXML, в первую очередь в связи с ее масштабируемостью и XML-функциями, позволяющими обрабатывать большие объемы PDBML-документов. Кроме того, DB2 бесплатна для некоммерческого использования по программе IBM Academic Initiative. Нашей целью являлось сохранение PDB-информации в эффективной схеме базы данных, использование реляционных и XML-индексов для высокопроизводительного поиска, использование XQuery и SQL/XML для создания сложных запросов на извлечение информации из PDB.


Содержимое Protein Data Bank

Перед обсуждением дизайна базы данных DB2 для PDB полезно понять, что представляют собой данные PDB.

Третичная структура белка определяется экспериментально, преимущественно методом рентгеновской дифракции или рентгеновской кристаллографии. Другим менее распространенным методом является ЯМР (ядерный магнитный резонанс) или ЯМР-спектроскопия. Используемые методы определения структуры белка приводят к различиям в генерируемых XML-документах, что проявляется главным образом в размерах XML-файлов.

Белки являются динамичными молекулами, т.е. их третичные структуры могут незначительно меняться, например, в зависимости от среды. В связи с этим методом ЯМР обычно определяется несколько экземпляров (моделей), содержащих немного смещенные третичные структуры для одного и того же белка. В результате XML-файлы с данными о белках, сгенерированные методами ЯМР, могут быть очень большими (от 100 МБ до 1 ГБ и более). Далее вы увидите, как и зачем мы используем в DB2 сегментирование по диапазону значений (range partitioning) для отделения первой модели (модели по умолчанию) белка от ее разновидностей.

В листинге 1 показан фрагмент одного PDBML-документа. В нем представлены четыре из 177 категорий информации, которые могут появляться в таком документе, включая авторов исследования и используемый экспериментальный метод (<PDBx:exptlCategory>). Атрибут entry_id представляет уникальный PDB-идентификатор для данного документа.

Листинг 1. Фрагмент примера PDBML-документа (1BBZ.xml)
...
<PDBx:audit_authorCategory>
  <PDBx:audit_author pdbx_ordinal="1">
    <PDBx:name>Pisabarro, M.T.</PDBx:name>
  </PDBx:audit_author>
  ...
</PDBx:audit_authorCategory>
...
<PDBx:structCategory>
  <PDBx:struct entry_id="1BBZ">
    <PDBx:pdbx_descriptor>ABL TYROSINE KINASE, PEPTIDE P41
    </PDBx:pdbx_descriptor>
    <PDBx:title>CRYSTAL STRUCTURE OF THE ABL-SH3 DOMAIN COMPLEXED WITH
                A DESIGNED HIGH-AFFINITY PEPTIDE LIGAND: IMPLICATIONS FOR
                SH3-LIGAND INTERACTIONS
    </PDBx:title>
  </PDBx:struct>
</PDBx:structCategory>
...
<PDBx:struct_keywordsCategory>
  <PDBx:struct_keywords entry_id="1BBZ">
    <PDBx:pdbx_keywords>COMPLEX(TRANSFERASE/PEPTIDE)
    </PDBx:pdbx_keywords>
    <PDBx:text>COMPLEX (TRANSFERASE-PEPTIDE), SIGNAL TRANSDUCTION,SH3 DOMAIN, 
               COMPLEX (TRANSFERASE-PEPTIDE) complex
    </PDBx:text>
  </PDBx:struct_keywords>
</PDBx:struct_keywordsCategory>
...
<PDBx:exptlCategory>
  <PDBx:exptl entry_id="1BBZ" method="X-RAY DIFFRACTION">
    <PDBx:crystals_number>1</PDBx:crystals_number>
  </PDBx:exptl>
</PDBx:exptlCategory>
...

Тестовая база данных

По причине ограниченности времени и ресурсов мы решили использовать только подмножество всего объема данных PDB, чтобы смоделировать и оценить хранение, индексацию и выполнение запросов к PDBML-документам в базе данных DB2. Итак, мы используем репрезентативную выборку, состоящую из 6029 документов общим размером 83 ГБ, что составляет примерно 10% общего объема PDBML-архива по состоянию на декабрь 2010 года. Этот набор документов содержит примерно 1.7 миллиарда XML-элементов, из которых примерно 1.54 миллиарда описывают третичные структуры посредством координат атомов и другой информации.

Репрезентативная выборка PDBML-документов должна точно отражать отношение количества документов с информацией о молекулах, сгенерированных методом рентгеновской дифракции (меньшие по размеру документы, составляющие 83% от общего объема документов), к количеству документов, полученных методом ЯМР (более крупные по размеру документы, составляющие 16% общего объема документов). Это гарантирует тестирование запросов и конфигурации базы данных на реалистичной совокупности больших и малых документов.

В качестве сервера базы данных для данного исследования был выбран Sun X4600 M2 с восемью двухъядерными процессорами (AMD Opteron 8220) и 256 ГБ основной памяти. Использовалась 64-разрядная операционная система Ubuntu Linux®. Система хранения состояла из 10 жестких дисков (по 698 ГБ каждый; 7200 об/мин), организованных в один логический том (RAID 5) при помощи аппаратного контроллера.


Рекомендации по дизайну базы данных для PDB

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

Гибридная XML/реляционная модель хранилища

PDBML-документы в настоящее время содержат до 177 категорий информации, большинство из которых не обязательны. Большое число необязательных PDBML-элементов делает документы очень гибкими и изменчивыми. Полностью реляционная модель базы данных потребовала бы использования сотен таблиц для представления PDBML. Такая реляционная схема базы данных для PDB, показанная на рисунке 2, была разработана в 2005 году. Сложность этой схемы, состоящей более чем из 400 таблиц и 3000 столбцов, поражает. Такую схему чрезвычайно трудно понять, а к такой базе данных трудно написать запрос, поскольку одна запись PDB разбивается и распределяется по сотням таблиц, поэтому пользователям трудно определить, какая информация в каких таблицах находится. Поэтому хранение большей части PDBML-информации в ее оригинальном XML-формате в одном XML-столбце приводит в результате к намного более простому дизайну базы данных и оставляет данные в естественном для пользователя формате.

Рисунок 2. Диаграмма полностью реляционной схемы базы данных для PDBML
Схема полностью реляционной схемы базы данных для PDBML

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

Листинг 2. Координаты атома в PDBML-документе
<PDBx:atom_siteCategory>
  <PDBx:atom_site id="1">
    <PDBx:B_iso_or_equiv>37.41</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>1.039</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.834</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.876</PDBx:Cartn_z>
    <PDBx:auth_asym_id>A</PDBx:auth_asym_id>
    <PDBx:auth_atom_id>N</PDBx:auth_atom_id>
    <PDBx:auth_comp_id>ASN</PDBx:auth_comp_id>
    <PDBx:auth_seq_id>1</PDBx:auth_seq_id>
    <PDBx:group_PDB>ATOM</PDBx:group_PDB>
    <PDBx:label_alt_id xsi:nil="true" />
    <PDBx:label_asym_id>A</PDBx:label_asym_id>
    <PDBx:label_atom_id>N</PDBx:label_atom_id>
    <PDBx:label_comp_id>ASN</PDBx:label_comp_id>
    <PDBx:label_entity_id>1</PDBx:label_entity_id>
    <PDBx:label_seq_id>1</PDBx:label_seq_id>
    <PDBx:occupancy>1.00</PDBx:occupancy>
    <PDBx:pdbx_PDB_model_num>1</PDBx:pdbx_PDB_model_num>
    <PDBx:type_symbol>N</PDBx:type_symbol>
  </PDBx:atom_site>
  <PDBx:atom_site id="2">
    <PDBx:B_iso_or_equiv>36.15</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.213</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.205</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.364</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  <PDBx:atom_site id="3">
    <PDBx:B_iso_or_equiv>33.97</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.549</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.779</PDBx:Cartn_y>
    <PDBx:Cartn_z>16.986</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  ...
</PDBx:atom_siteCategory>

Однообразная и регулярная структура информации об атоме делает ее идеальной для хранения в традиционных реляционных таблицах. Фактически координаты атома и метки не являются иерархическими данными, для которых наилучшим выбором является XML. Поэтому мы остановились на гибридной схеме базы данных, хранящей информацию atom_site в реляционной таблице, а оставшийся PDBML-документ с удаленным разделом <atom_siteCategory> - в XML-столбце. Это дает несколько преимуществ:

  • Сокращенный PDBML-документ намного меньше по размеру, что повышает производительность вставки и загрузки, а также производительность XML-запросов. Синтаксический анализ XML при вставке или загрузке сокращается примерно на 90%.
  • Информация об атомах занимает меньше места в реляционном столбце, чем их подробное XML-представление.
  • Данные об атомах могут запрашиваться традиционными реляционными методами, которые для неиерархических данных более эффективны, чем навигация по XML-дереву.
  • Поскольку каждый атом представляется отдельной строкой, можно использовать индексы для ускорения поиска конкретных атомов в данной PDBML-записи.

Выбранная схема базы данных состоит из двух таблиц, приведенных в листинге 3. В первой (xmlrpdb.pdbxml) каждой PDB-записи соответствует одну строка. Эта таблица состоит всего из двух столбцов:

  • Первичный ключ pdb_id хранит четырехсимвольный идентификатор PDB-записи из XML-атрибута entry_id.
  • XML-столбец pdbxml_file хранит весь PDBML-документ, за исключением <atom_siteCategory>.

Во второй таблице (xmlrpdb.atom_site) каждой координате атома (т.е. каждому элементу <atom_site> в PDBML-документе) соответствует одна реляционная строка. Столбец pdb_id – это внешний ключ, связывающий координаты атома с соответствующим PDBML-документом в таблице pdbxml.

Обе таблицы хранятся в табличной области с размером страницы 32 КБ для максимизации производительности аналитических запросов, читающих большое количество строк.

Листинг 3. Гибридная XML/реляционная схема базы данных для PDB в DB2
CREATE TABLE xmlrpdb.pdbxml (
  pdb_id             CHAR(4) NOT NULL,
  pdbxml_file        XML NOT NULL,
  PRIMARY KEY (PDB_ID))
IN ts_data32k INDEX IN ts_index32k;

CREATE TABLE xmlrpdb.atom_site (
  pdb_id                CHAR(4) NOT NULL,
  atom_site_id          INTEGER NOT NULL,
  auth_asym_id          VARCHAR(10) WITH DEFAULT NULL,
  auth_atom_id          VARCHAR(20) NOT NULL,
  auth_comp_id          VARCHAR(3) NOT NULL,
  auth_seq_id           VARCHAR(20) NOT NULL,
  b_iso_or_equiv        DECIMAL(7,3) NOT NULL,
  b_iso_or_equiv_esd    DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_x               DECIMAL(7,3) NOT NULL,
  cartn_x_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_y               DECIMAL(7,3) NOT NULL,
  cartn_y_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_z               DECIMAL(7,3) NOT NULL,
  cartn_z_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  group_pdb             VARCHAR(10) NOT NULL,
  label_alt_id          VARCHAR(10) WITH DEFAULT NULL,
  label_asym_id         VARCHAR(10) WITH DEFAULT NULL,
  label_atom_id         VARCHAR(20) WITH DEFAULT NULL,
  label_comp_id      VARCHAR(10) NOT NULL,
  label_entity_id       SMALLINT NOT NULL,
  label_seq_id          SMALLINT WITH DEFAULT NULL,
  occupancy             DECIMAL(7,3) NOT NULL,
  occupancy_esd         DECIMAL(7,3) WITH DEFAULT NULL,
  pdbx_pdb_atom_name    VARCHAR(10) WITH DEFAULT NULL,
  pdbx_pdb_ins_code     VARCHAR(10) WITH DEFAULT NULL,
  pdbx_PDB_model_num SMALLINT NOT NULL,
  type_symbol           VARCHAR(10) WITH DEFAULT NULL,
  PRIMARY KEY (pdb_id, atom_site_id),
  FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),
  CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
) IN ts_atom_data_32k INDEX IN ts_atom_index32k;

При желании можно определить в таблице pdbxml ограничения CHECK, чтобы гарантировать соответствие четырехсимвольного идентификатора стандарту PDB. Первый символ должен быть цифрой в интервале от 1 до 9, а следующие три символа должны быть цифрой в интервале от 0 до 9 или заглавной буквой в интервале от A до Z (см. листинг 4).

Листинг 4. Ограничения CHECK для проверки корректности значений pdb_id
ALTER TABLE xmlrpdb.pdbxml
  ADD CHECK (SUBSTR(pdb_id, 1, 1) BETWEEN '1' AND '9')
  ADD CHECK ((SUBSTR(pdb_id, 2, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 2, 1) BETWEEN 'A' AND 'Z'))
  ADD CHECK ((SUBSTR(pdb_id, 3, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 3, 1) BETWEEN 'A' AND 'Z'))
  ADD CHECK ((SUBSTR(pdb_id, 4, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 4, 1) BETWEEN 'A' AND 'Z'));

Заполнение гибридной схемы базы данных

Концептуальный процесс вставки PDBML-документа в нашу гибридную схему базы данных проиллюстрирован на рисунке 3. Данные <atom_siteCategory> необходимо извлечь и удалить из XML-документа и вставить в реляционную таблицу atom_site (голубая). Сам сокращенный документ вставляется в таблицу pdbxml. Этот процесс называется отделением данных atom_site.

Рисунок 3. Гибридное хранилище PDBML-документов с отделением данных atom_site
Гибридное хранилище PDBML-документов с отделением данных atom_site

Большие объемы данных требуют высокой производительности процесса разделения (заполнения гибридной схемы базы данных). В связи с этим ресурсоемкий анализ XML необходимо свести к минимуму. Если вернуться к координатам атомов в XML-формате (см. листинг 2), можно увидеть, что 94.5% символов представляют собой разметку и только 5.5% – это реальные значения. Т.е. отношение разметки к значениям очень велико, а это означает, что для извлечения относительно небольшого количества полезных данных надо выполнить большой объем работы по анализу XML. Вскоре вы поймете, как это соображение повлияло на наш выбор способа заполнения обеих таблиц.

Одним из вариантов заполнения реляционной таблицы atom_site является использование выражений INSERT с функцией XMLTABLE. Такое выражение может выполнять анализ всего PDBML-документа и извлекать информацию об атомах для вставки в виде реляционных строк. Кроме того, XQuery-выражение Update может удалить поддерево <atom_siteCategory> из каждого PDBML-документа, вставляемого в таблицу pdbxml. Такое XQuery-выражение Update может также быть частью выражения INSERT, и в этом случае раздел <atom_siteCategory> удаляется до записи его в XML-столбец вместо выполнения отдельного действия после вставки.

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

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

Предварительная обработка набора данных, состоящего из 6029 PDBML-документов, сжатых в gzip-архивы (т.е. 83 ГБ в разархивированном виде), и загрузка подготовленных данных в таблицы pdbxml и atom_site заняли всего лишь 1 час и 44 минуты. Препроцессор можно загрузить в разделе Загрузка.

Сжатие

Учитывая объем данных в PDB-архиве, а также его быстрое увеличение, полезно хранить в DB2 данные в сжатом виде. Это уменьшит занимаемое пространство и улучшит производительность. Несмотря на то, что сжатие (и распаковка) в DB2 создает дополнительную нагрузку на процессор, оно уменьшает число физических операций ввода/вывода, необходимых для чтения с диска определенного объема данных. Более того, сжатые страницы табличной области DB2 остаются сжатыми в буферном пуле в основной памяти. В результате в оперативной памяти сохраняется больший объем данных, что повышает результативность буферного пула и коэффициент использования доступной оперативной памяти. Мы обнаружили, что преимущества для системы ввода/вывода и оперативной памяти перевешивают дополнительные затраты ресурсов процессора и приводят к более высокой производительности всей системы.

Для сжатия обеих таблиц мы использовали следующие команды (см. листинг 5):

Листинг 5. Разрешение сжатия и реорганизация таблиц
ALTER TABLE xmlrpdb.pdbxml COMPRESS YES;
REORG TABLE xmlrpdb.pdbxml LONGLOBDATA RESETDICTIONARY;

ALTER TABLE xmlrpdb.atom_site COMPRESS YES;
REORG TABLE xmlrpdb.atom_site LONGLOBDATA RESETDICTIONARY;

Уменьшение занимаемого пространства отражено в таблице 1. После сжатия информации, содержащейся в 6029 PDBML-документах, число страниц для ее хранения уменьшается на 67.4% (т.е. в три раза по сравнению с несжатой информацией).

Таблица 1. Экономия места, достигаемая путем сжатия
До сжатияПосле сжатияЭкономия
xmlrpdb.pdbxml176256 страниц44736 страниц74.6%
xmlrpdb.atom_site264960 страниц99264 страницы62.5%
Всего441216 страниц144000 страниц67.4%

При размере страницы 32 КБ окончательный размер хранилища, содержащего 144000 страниц, занимает 4.4 ГБ, т.е. всего лишь 5.3% от объема оригинальных необработанных данных, равного 83 ГБ. Если экстраполировать эту пропорцию на общий размер PDB-архива, можно определить, что для хранения 0.75 ТБ информации PDB в DB2 хватило бы всего около 40.7 ГБ дискового пространства плюс некоторый объем для индексов.

Такая гигантская экономия является следствием двух факторов. Во-первых, большое отношение объема разметки к объему данных в информации об атомах устраняется преобразованием координат атомов в реляционный формат на этапе предварительной обработки. Во-вторых, сжатие таблиц DB2 уменьшает размер оставшихся XML-документов и реляционных данных в три раза.

Сегментирование базы данных

Несмотря на значительное уменьшение занимаемого пространства, объем данных PDB постоянно и быстро растет. Распределив данные по нескольким сегментам базы данных, чтобы все сегменты работали со своими данными одновременно, можно уменьшить время реакции на сложные аналитические запросы. Эти сегменты базы данных могут размещаться на одной и той же машине и использовать всю процессорную мощность многоядерной системы или на нескольких машинах без общих ресурсов. Функциональность DB2 Database Partitioning Feature (DPF) доступна в IBM InfoSphere® Warehouse, программном пакете, содержащем DB2 с расширенными возможностями, такими как дополнительные средства проектирования, создания отчетов и управления базами данных.

При использовании DPF мы рекомендуем распределять данные таблиц pdbxml и atom_site по сегментам базы данных путем хеширования значений столбца pdb_id. Для этого нужно добавить оператор DISTRIBUTE BY HASH(pdb_id) в соответствующее выражение CREATE TABLE. Большое число несовпадающих значений в столбце pdb_id гарантирует относительно равномерное распределение строк по сегментам базы данных. Распределение обеих таблиц путем хеширования их ключа соединения (pdb_id) гарантирует также, что все строки с атомами для данного PDBML-документа будут храниться в том же сегменте базы данных, что и сам PDBML-документ. Такое совместное размещение означает, что соединения между двумя таблицами всегда будут выполняться внутри сегмента базы данных и никогда не потребуют перемещения данных между сегментами.

Сегментирование по диапазонам значений

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

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

Мы решили сегментировать таблицу atom_site по диапазонам значений столбца pdbx_PDB_model_num по следующей причине: как вы помните, третичная структура белка может быть экспериментально определена методом ЯМР, который выдает несколько третичных структур для одного и того же белка. Эти вариации называются моделями и пронумерованы в поле pdbx_PDB_model_num. Значение pdbx_PDB_model_num = 1 указывает на то, что это первая (по умолчанию) модель белка. Дополнительные вариации не являются моделями по умолчанию и имеют значение pdbx_PDB_model_num >= 2. Белки, структура которых определенна методом дифракции рентгеновских лучей, имеют только одну модель с pdbx_PDB_model_num = 1.

В листинге 6 показано расширенное определение таблицы atom_site с сегментированием по диапазонам значений. Все координаты атомов, принадлежащие первой модели (pdbx_PDB_model_num = 1), хранятся в одном сегменте, тогда как все другие вариации (pdbx_PDB_model_num >= 2) хранятся в другом сегменте. Несмотря на то, что в настоящее время только 16% всех белков в PDB имеют вариации, сгенерированные ЯМР, количество этих вариаций настолько велико, что оба раздела имеют примерно одинаковое число записей.

Листинг 6. Определение таблицы с сегментированием по диапазонам значений
CREATE TABLE xmlrpdb.atom_site (
  pdb_id             CHAR(4) NOT NULL,
  ...
  pdbx_PDB_model_num SMALLINT NOT NULL,
  type_symbol           VARCHAR(10) WITH DEFAULT NULL,
  PRIMARY KEY (pdb_id, atom_site_id),
  FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),
  CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
)
-- IN ts_atom_data_32k
INDEX IN ts_atom_index32k
PARTITION BY RANGE (pdbx_PDB_model_num)
(
  PARTITION DEF_MODELS      STARTING (1) ENDING (1) IN TS_ATOM_DATA1_32K,
  PARTITION NON_DEF_MODELS  STARTING (2) ENDING (MAXVALUE) IN TS_ATOM_DATA2_32K
);

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

Многомерная кластеризация

В дополнение к сегментированию по диапазонам значений можно использовать многомерную кластеризацию (Multi-Dimensional Clustering – MDC) для кластеризации строк в таблице на основе одного или нескольких столбцов. Строки с одинаковыми значениями в кластерных столбцах физически хранятся в одной и той же ячейке хранилища. Это может значительно повысить производительность запросов, ограничивающих и выбирающих данные по одному или нескольким кластерным измерениям. Как и DPF, функциональность MDC доступна в IBM InfoSphere Warehouse.

Выбор кластерных столбцов должен основываться на ожидаемой рабочей нагрузке от запросов, чтобы кластеризация поддерживала наиболее частые и наиболее критичные запросы. Например, многие запросы к PDB могут искать данные об атомах по участвующим в них аминокислотам. Следовательно, может быть эффективна кластеризация таблицы atom_site по столбцу label_comp_id, который в большинстве документов содержит трехсимвольный код аминокислоты. Для реализации такой кластеризации добавьте во второе выражение CREATE TABLE в листинге 3 следующий оператор: ORGANIZE BY DIMENSIONS(label_comp_id).

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

Запросы к PDB и производительность

В данном сценарии обсуждаются два примера запросов, демонстрирующих:

  • Простоту выполнения даже сложного анализа данных PDB.
  • Преимущества принятых решений по дизайну базы данных, описанных в предыдущих разделах.

Запрос, приведенный в листинге 7, выбирает PDB-идентификатор, разрешающую способность и описание из всех записей PDB, в которых экспериментальным методом является X-RAY DIFFRACTION, и разрешающая способность (ls_d_res_high) меньше 2.5. Разрешающая способность выражается в ангстремах (1Å = 0.1 нанометра) и служит показателем качества анализа атомных структур. Структуры с разрешающей способностью менее 2Å являются структурами с высоким разрешением (т.е. положение их атомов может быть определено очень точно). Структуры с разрешающей способностью больше 3Å являются недостаточно точными и обычно игнорируются.

Листинг 7. Запрос первых 10 записей с наилучшей разрешающей способностью, с данными, полученными методом рентгеновской дифракции
SELECT pdb_id, x.resolution, x.pdbx_descriptor
FROM xmlrpdb.pdbxml,
  XMLTABLE
  ('$PDBXML_FILE/*:datablock/*:refineCategory/*:refine[
   @pdbx_refine_id = "X-RAY DIFFRACTION" and *:ls_d_res_high <= 2.5 ]'
  COLUMNS
    resolution      DEC(9,5)      PATH '*:ls_d_res_high',
    pdbx_descriptor VARCHAR(2000) PATH '../../*:structCategory/*:struct/*:pdbx_descriptor'
  ) AS x
-- WHERE
--   upper(x.pdbx_descriptor) LIKE '%UNKNOWN%' or
--   upper(x.pdbx_descriptor) LIKE '%UNCHARACTERIZED%'
ORDER BY x.resolution
FETCH FIRST 10 ROWS ONLY;

Результат этого запроса показан в листинге 8. Одним из преимуществ использования DB2 pureXML по сравнению со специализированным кодом является простота изменения SQL/XML-запросов для уточнения поиска. Например, листинг 7 содержит три закомментированные строки с дополнительным оператором WHERE. Эти строки можно использовать для дальнейшей фильтрации дескриптора, чтобы найти структуры, которые еще не описаны или которые не удалось описать.

Листинг 8. Результат работы запроса, приведенного в листинге 7
PDB_ID RESOLUTION  PDBX_DESCRIPTOR 
------ ----------- -------------------------------------------------
2VB1       0.65000 LYSOZYME C (E.C.3.2.1.17)
2B97       0.75000 Hydrophobin II
2OV0       0.75000 PROTEIN
2I16       0.81000 Aldose reductase (E.C.1.1.1.21)
2I17       0.81000 Aldose reductase (E.C.1.1.1.21)
2HS1       0.84000 HIV-1 Protease V32I mutant (EC 3.4.23.16)
2F01       0.85000 Streptavidin               
2OL9       0.85000 SNQNNF peptide from human prion residues 170-175
2PF8       0.85000 Aldose reductase (E.C.1.1.1.21)
2P74       0.88000 Beta-lactamase CTX-M-9a (E.C.3.5.2.6)

  10 record(s) selected.

Предикаты запроса, приведенного в листинге 7, имеют малую селективность, поэтому необходимо сканирование всей таблицы pdbxml. В таблице 2 приведены итоговые показатели производительности этого запроса для двух наших решений: отделения atom_site и сжатия. В нашей среде таблица сканировалась с ограничением скорости ввода/вывода. Сжатие DB2 смягчило ограничение подсистемы ввода/вывода и уменьшило время выполнения запроса более чем на 40% (с 244 до 128 секунд). Извлечение данных atom_site в отдельную реляционную таблицу уменьшило размер таблицы pdbxml, что улучшило производительность запросов почти в 4.5 раза, со 138 до 31 секунды.

Таблица 2. Время реакции (без индексов) на запрос, приведенный в листинге 7
Отделение atom_siteСжатиеВремя реакции
НетНет244 секунды
НетДа138 секунд
ДаДа31 секунда

В листинге 9 приведен еще один пример запроса, определяющего частоту появления различных атомов (или ионов) в различных смесях. Оператор WHERE сужает поиск до так называемых гетероатомов и учитывает только первую модель каждого белка.

Листинг 9. Анализ частоты появления гетероатомов
SELECT label_atom_id                   AS "Atom", 
       COALESCE(label_comp_id, 'none') AS "Compound", 
       COUNT(*)                        AS "Occurrences"
FROM xmlrpdb.atom_site
WHERE group_PDB = 'HETATM'
  AND pdbx_PDB_model_num = 1
GROUP BY label_atom_id, label_comp_id
ORDER BY COUNT(*),label_comp_id DESC;

Подмножество полученных строк показано в листинге 10. Наиболее часто обнаруживаемым химическим соединением является вода (HOH), одним из атомов которой является кислородом (O). Полученное число атомов водорода, обозначенное H1 и H2 для HOH, ниже, поскольку обнаружение водорода требует более высокой разрешающей способности, которая не всегда достигается.

(Человеческий) гемоглобин – это белок, состоящий из нескольких молекул, каждая из которых может взаимодействовать с небелковым соединением, называемым гемом (heme). Гем (HEM) – это многоатомная небелковая органическая структура, способная размещать в своем центре ион железа (FE). Этот ион железа, в свою очередь, играет ключевую роль в связывании кислорода. Результат, приведенный в листинге 10, демонстрирует, что железо часто обнаруживается вместе с гем-соединениями. Хотя это довольно простой пример, он демонстрирует, насколько эффективным становится поиск осмысленных корреляций в PDB-данных и насколько проще понять функцию белков и их взаимодействие на молекулярном уровне.

Листинг 10. Подмножество результатов запроса из листинга 9
Atom     Compound        Occurrences
-------- --------------  -------------------------
O        HOH             1571965
MG       MG              7159
...
H1       HOH             1858
H2       HOH             1858
ZN       ZN              1664
...
CL       CL              1318
CA       CA              1295
...
FE      HEM           379
NA       HEM             379

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

Таблица 3. Время реакции (без индексов) на запрос, приведенный в листинге 9
Отделение atom_siteСжатиеСегментирование по диапазонам значенийMDCВремя реакции
ДаДаНетНет38.7 секунды
ДаДаДаНет25.8 секунды
ДаДаДаДа5.5 секунды

Заключение

В данной статье рассматривалось использование функций управления реляционными и pureXML-данными в DB2 для эффективного хранения и выборки данных Protein Data Bank (PDB). Учитывая особенности, свойственные данным о белках, мы разработали оптимальную гибридную схему базы данных. Для наилучшей производительности и минимального потребления дискового пространства мы рекомендуем использовать сегментирование базы данных, сегментирование по диапазонам значений, сжатие и многомерную кластеризацию. Кроме того, можно еще больше повысить производительность запросов при помощи комбинации XML-индексов и реляционных индексов. База PDB, основанная на DB2, продолжает использоваться в исследованиях, например, для поиска во всем банке PDB определенных взаимодействий белков и для объяснения некоторых необычных взаимодействий на структурном уровне.

Благодарности

Разработка основанной на DB2 базы PDB была осуществлена в исследовательской группе Structural Bioinformatics Марией Терезой Писабарро (Maria Teresa Pisabarro) из Центра биотехнологий Дрезденского технического университета (Германия). Проект финансируется за счет стипендии, предоставленной фондом соучредителя SAP Клауса Чира (Klaus Tschira). Также авторы выражают благодарность Хенрику Лёзеру (Henrik Loeser) за помощь в работе и Берлинскому институту биологии медицинских систем (BIMSB) Центра молекулярной медицины им. Макса Дельбрюка (MDC) в Берлине-Бухе (Германия) за предоставление сервера.


Загрузка

ОписаниеИмяРазмер
Препроцессор на C++ и примеры запросов к DB2db2pdb_download.zip965 КБ

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, XML
ArticleID=811786
ArticleTitle=Управление банком данных белков и нуклеиновых кислот при помощи DB2 pureXML
publish-date=04252012