Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

Ralex. We do the work.
На рынке с 1999го года. Средняя ценовая категория. Ориентация на эффективность решений.
Ознакомтесь с нашим портфолио
Узнайте больше о услугах
Свяжитесь с нами:
E-mail: [email protected]
Tel: (044) 587 - 84 - 78
Custom web design & дизайн и разработка сайта "под ключ"
Креативный, эффективный дизайн. Система управления сайтом (СУС).
Custom flexible разработка систем электронной коммерции
Система e-commerce разрабатывается под индивидуальные потребности. Гибкая функциональность.
Search Engine Optimzation & оптимизация под поисковые системы (SEO)
Постоянная оптимизация и мониторинг сайта в поисковых системах. Достигаем результата быстро и эффективно
Custom logo design & дизайн логотипа и фирменного стиля
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.
профессиональная рекламная фотография
креативно, смело, качественно
Custom logo design & рекламный креатив. дизайн рекламы
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.

Управління банком даних білків і нуклеїнових кислот за допомогою DB2 pureXML

  1. проблема
  2. Малюнок 1. Зростання PDB за останні 20 років
  3. Вміст Protein Data Bank
  4. Лістинг 1. Фрагмент прикладу PDBML-документа (1BBZ.xml)
  5. Тестова база даних
  6. Рекомендації по дизайну бази даних для PDB
  7. Гібридна XML / реляційна модель сховища
  8. Малюнок 2. Діаграма повністю реляційної схеми бази даних для PDBML
  9. Лістинг 2. Координати атома в PDBML-документі
  10. Лістинг 3. Гібридна XML / реляційна схема бази даних для PDB в DB2
  11. Лістинг 4. Обмеження CHECK для перевірки коректності значень pdb_id
  12. Заповнення гібридної схеми бази даних
  13. Малюнок 3. Гібридний сховище PDBML-документів з відділенням даних atom_site
  14. стиснення
  15. Лістинг 5. Дозвіл стиснення і реорганізація таблиць
  16. Таблиця 1. Економія місця, что досягається Шляхом стисненого
  17. Сегментування бази даних
  18. Сегментування за діапазонами значень
  19. Лістинг 6. Визначення таблиці з сегментированием за діапазонами значень
  20. багатовимірна кластеризация
  21. Запити до PDB і продуктивність
  22. Лістинг 7. Запит перших 10 записів з найкращого роздільною здатністю, з даними, отриманими методом...
  23. Лістинг 8. Результат роботи запиту, наведеного в лістингу 7
  24. Таблиця 2. Час реакції (без індексів) на запит, наведений у лістингу 7
  25. Лістинг 9. Аналіз частоти появи гетероатомов
  26. Лістинг 10. Підмножина результатів запиту з лістингу 9
  27. Таблиця 3. Час реакції (без індексів) на запит, наведений у лістингу 9
  28. Висновок
  29. Подякою
  30. Ресурси для скачування

Наша взаимовыгодная связь https://banwar.org/

Банк даних білків і нуклеїнових кислот ( 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

Типовим підходом до аналізу даних 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, MT </ 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-даних є координати атома і пов'язані з ними мітки, які слідують одноманітною регулярної структурі, що повторюється для кожного атома в молекулі, як показано в лістингу 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> ... </ PD Bx: 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

Великі обсяги даних вимагають високої продуктивності процесу поділу (заповнення гібридної схеми бази даних). У зв'язку з цим ресурсномісткий аналіз 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.pdbxml 176256 сторінок 44736 сторінок 74.6% xmlrpdb.atom_site 264960 сторінок 99264 Сторінки 62.5% Всього 441 216 сторінок 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 (EC3.2.1.17) 2B97 0.75000 Hydrophobin II 2OV0 0.75000 PROTEIN 2I16 0.81000 Aldose reductase (EC1.1.1.21) 2I17 0.81000 Aldose reductase (EC1.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 (EC1.1.1.21) 2P74 0.88000 Beta-lactamase CTX-M-9a (EC3.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 тисячу шістсот шістьдесят чотири ... 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) в Берліні-Буху (Німеччина) за надання сервера.

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

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Категории
  • Биология
  • Математика
  • Краеведению
  • Лечебная
  • Наука
  • Физике
  • Природоведение
  • Информатика
  • Новости

  • Новости
    https://banwar.org/
    Наша взаимовыгодная связь https://banwar.org/. Запустив новый сайт, "Пари Матч" обещает своим клиентам незабываемый опыт и возможность выиграть крупные суммы.


    Наши клиенты
    Клиенты

    Быстрая связь

    Тел.: (044) 587-84-78
    E-mail: [email protected]

    Имя:
    E-mail:
    Телефон:
    Вопрос\Комментарий: