Giới thiệu

PDB (PDB.org) là một kho lưu trữ dữ liệu cấu trúc về các phân tử sinh học, chủ yếu là các protein, có quy mô toàn cầu. PDB (Ngân hàng dữ liệu Protein) do một số tổ chức thành viên có trách nhiệm quản lý cho phép ký gửi, bảo trì, xử lý và cung cấp miễn phí dữ liệu sinh học này cho cộng đồng khoa học. Để tạo ra việc trao đổi dữ liệu linh hoạt, có khả năng mở rộng và dễ dàng, dữ liệu PDB có sẵn theo định dạng XML. Định dạng XML này do một Lược đồ XML có tên là Protein Data Bank Markup Language (PDBML - Ngôn ngữ đánh dấu của Ngân hàng dữ liệu Protein) quy định.

Thông tin cấu trúc gồm có các tọa độ 3-D của các nguyên tử của một hay nhiều phân tử mà một protein chứa chúng. Các tọa độ nguyên tử này cũng được gọi là cấu trúc 3-D hoặc cấu trúc cấp ba. Cấu trúc cấp ba của một protein gắn chặt với chức năng của nó. Vì vậy, việc hiểu rõ cấu trúc cấp ba thường giúp hiểu rõ chức năng bên trong của protein. Ví dụ, cấu trúc cấp ba có thể có ích để giải thích các bệnh tật hoặc phát triển các loại thuốc mới. Cấu trúc cấp ba cũng có thể được khai thác để tìm kiếm PDB với các tương tác giữa các protein.

Về đầu trang

Thách thức

Tính đến tháng 12 năm 2010, kho lưu trữ của PDB đã lưu giữ 70.000 mục (các tài liệu XML) với hơn 500 triệu tọa độ nguyên tử. Tổng dung lượng chưa nén là hơn 750 GB. Các tài liệu XML riêng lẻ trong PDB có dung lượng khác nhau từ một vài MB đến hơn 1 GB. Dựa trên sự tăng trưởng nhanh chóng của kho lưu trữ PDB trong những năm gần đây (Hình 1), dự kiến dung lượng của PDB sẽ tiếp tục tăng lên đáng kể. Do đó, việc tìm kiếm và phân tích thông tin này càng trở nên thách thức hơn.

Một cách tiếp cận điển hình để phân tích dữ liệu PDB là viết một ứng dụng tùy chỉnh hoặc một tập kịch bản lệnh để tìm kiếm tài liệu PDBML cho một câu hỏi nghiên cứu rất cụ thể. Các nhược điểm của cách tiếp cận này có tính đến các thực tế sau:

• Việc phát triển mã tùy chỉnh, mỗi khi đang tiến hành nghiên cứu mới, dùng rất nhiều lao động và tốn thời gian.
• Hiệu năng thường kém vì tất cả tài liệu cần được phân tích cú pháp và được tìm kiếm, ngay cả khi chỉ có một tập con của chúng chứa thông tin liên quan.
• Thường rất khó để tái sử dụng hoặc kết hợp mã tùy chỉnh hiện có để soạn các truy vấn mới hoặc khác nhau dựa vào dữ liệu PDB.

DB2 V9.7.3 với pureXML đã được chọn để giải quyết những thách thức này, chủ yếu là do DB2 có khả năng mở rộng và có các khả năng XML cần thiết để xử lý các khối lượng tài liệu PDBML dự kiến. Ngoài ra, DB2 có sẵn miễn phí để sử dụng phi thương mại thông qua chương trình Sáng kiến học đường của IBM (IBM Academic Initiative). Mục đích là lưu trữ thông tin PDB trong một lược đồ cơ sở dữ liệu hiệu quả, khai thác các chỉ mục quan hệ và XML để tìm kiếm có hiệu quả và sử dụng XQuery và SQL/XML để biểu diễn truy vấn phức tạp dựa vào thông tin PDB.

Về đầu trang

Nội dung của PDB

Trước khi chúng ta thảo luận về thiết kế cơ sở dữ liệu DB2 cho PDB, việc hiểu rõ thêm một chút về dữ liệu PDB là rất có ích.

Cấu trúc cấp ba của một protein được xác định (được giải), qua thực nghiệm, chủ yếu theo một phương pháp gọi là Nhiễu xạ qua tia X hoặc Phép khảo sát tinh thể học bằng tia X. Một phương pháp khác thường ít được sử dụng hơn là Giải pháp NMR (Cộng hưởng từ hạt nhân) hoặc Quang phổ NMR. Có nhiều phương pháp để xác định (giải) cấu trúc protein dẫn đến sự khác biệt về cách mô tả một cấu trúc protein trong các tài liệu XML đã tạo ra, đặc biệt được phản ánh bằng kích thước tệp XML.

Các protein là các phân tử động, có nghĩa là cấu trúc cấp ba của chúng có thể thay đổi chút ít, ví dụ như tùy thuộc vào môi trường của chúng. Do những biến thể này, Cộng hưởng từ hạt nhân (NMR) xác định chi tiết nhiều cá thể (nhiều mô hình) mô tả các cấu trúc cấp ba có thay đổi chút ít cho cùng một protein. Do đó, các tệp XML có dữ liệu protein do Cộng hưởng từ hạt nhân tạo ra có thể có kích thước rất lớn, ví dụ như 100 MB đến 1 GB hoặc lớn hơn nữa. Ngoài ra, bạn sẽ thấy sau trong bài này cách và lý do tại sao chúng ta sử dụng các phân vùng khác nhau của DB2 để tách mô hình (mặc định) đầu tiên của một protein khỏi những biến thể của nó.

Liệt kê 1 Liệt kê 1 cho thấy một đoạn trích từ một tài liệu PDBML. Bạn có thể thấy bốn trong số 177 thể loại thông tin, có thể xuất hiện trong tài liệu này, bao gồm cả các tác giả của nghiên cứu và phương pháp thử nghiệm (<PDBx:exptlCategory>) đã sử dụng. Thuộc tính entry_id mô tả mã định danh PDB duy nhất cho tài liệu này.

...
<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>
...

Về đầu trang

Cơ sở dữ liệu thử nghiệm

Do các ràng buộc về thời gian và tài nguyên, chúng ta quyết định chỉ sử dụng một tập con của tổng khối lượng dữ liệu PDB có sẵn để tạo nguyên mẫu và đánh giá lưu trữ, lập chỉ mục và truy vấn các tài liệu PDBML trong một cơ sở dữ liệu DB2. Do đó, hãy chọn một mẫu tiêu biểu cho 6.029 tài liệu, có dung lượng 83 GB và chiếm khoảng 10% tổng dung lượng lưu trữ của PDBML vào tháng 12 năm 2010. Tập tài liệu này có chứa khoảng 1,7 tỷ phần tử XML, trong đó có khoảng 1,54 tỷ phần tử mô tả các cấu trúc protein cấp ba thông qua các tọa độ nguyên tử và thông tin khác.

Một mẫu tiêu biểu cho các tài liệu PDBML phải phản ánh chính xác tỷ lệ các tài liệu có thông tin phân tử do Nhiễu xạ qua tia X tạo ra (các tài liệu nhỏ hơn, chiếm 83% của tất cả các tài liệu) so với Giải pháp NMR (các tài liệu lớn hơn, chiếm 16% của tất cả các tài liệu). Điều này đảm bảo rằng cấu hình và các truy vấn cơ sở dữ liệu được thử nghiệm có một sự kết hợp thực tế giữa các tài liệu nhỏ và lớn.

Máy chủ cơ sở dữ liệu có sẵn cho nghiên cứu này là Sun X4600 M2 với tám bộ xử lý lõi kép (AMD Opteron 8220) và bộ nhớ chính 256GB. Hệ điều hành Linux® Ubuntu 64-bit. Thiết bị lưu trữ có 10 ổ đĩa cứng (mỗi ổ có dung lượng 698 GB; tốc độ 7200 rpm), được tổ chức thành một khối logic (RAID 5) với một bộ điều khiển phần cứng.

Về đầu trang

Các khuyến cáo thiết kế cơ sở dữ liệu cho PDB

Phần này mô tả một tập các khuyến cáo thiết kế cơ sở dữ liệu, dẫn đến sự trợ giúp cơ sở dữ liệu đơn giản và hiệu quả để lưu trữ và phân tích dữ liệu PDB. Những khuyến cáo này tập trung vào lược đồ cơ sở dữ liệu, việc lựa chọn giữa lưu trữ XML và quan hệ, định nghĩa các chỉ mục và tổ chức dữ liệu vật lý với các tùy chọn phân vùng và phân cụm.

Lưu trữ Quan hệ/XML lai

Tài liệu PDBML hiện đang chứa tới 177 thể loại thông tin, hầu hết trong số đó là tùy chọn. Phần lớn các phần tử PDBML tùy chọn cho phép các tài liệu rất linh hoạt và rất dễ thay đổi. Một lược đồ cơ sở dữ liệu quan hệ đầy đủ sẽ yêu cầu hàng trăm bảng để đại diện cho PDBML. Một lược đồ cơ sở dữ liệu quan hệ như vậy cho PDB đã được phát triển vào năm 2005 và được hiển thị trong Hình 2. Với hơn 400 bảng và hơn 3.000 cột, lược đồ này rất phức tạp. Để hiểu và truy vấn một lược đồ cơ sở dữ liệu như vậy là vô cùng khó khăn vì một mục PDB đơn lẻ được chia nhỏ và rải rác trên hàng trăm bảng, rất khó cho người dùng biết được thông tin nào nằm trong bảng nào. Vì vậy, việc giữ cho hầu hết thông tin PDBML theo định dạng XML ban đầu của nó và lưu trữ nó trong một cột XML duy nhất dẫn đến một thiết kế cơ sở dữ liệu đơn giản hơn nhiều và vẫn duy trì dữ liệu theo một định dạng mà người dùng hiểu được một cách tự nhiên.

Một ngoại lệ đáng chú ý đối với tính hay thay đổi của dữ liệu PDBML là các tọa độ nguyên tử và các nhãn có liên quan của chúng, theo một cấu trúc phẳng và có quy tắc được lặp lại cho mỗi nguyên tử trong một phân tử, như minh họa trong Liệt kê 2. Do các protein thường có hàng ngàn hoặc hàng chục ngàn nguyên tử, nên các tọa độ nguyên tử thường mô tả 90% hoặc nhiều hơn về một tài liệu 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>

Cấu trúc phẳng và có quy tắc của thông tin nguyên tử tạo ra một sự ăn khớp hoàn toàn với các bảng quan hệ truyền thống. Trong thực tế, các tọa độ nguyên tử và các nhãn là dữ liệu không phân cấp mà XML không phải là sự lựa chọn tốt nhất với chúng. Vì vậy, chúng ta chọn một lược đồ cơ sở dữ liệu lai, lưu trữ thông tin atom_site (trang_nguyên tử) trong một bảng quan hệ và lưu trữ phần còn lại của mỗi tài liệu PDBML trong một cột XML, nhưng loại bỏ <atom_siteCategory> khỏi tài liệu. Điều này có nhiều ưu điểm:

• Các tài liệu PDBML đã thu nhỏ hơn nhiều, giúp cải thiện hiệu năng chèn và tải, cũng như hiệu năng truy vấn XML. Cố gắng phân tích cú pháp XML khi chèn hoặc tải được giảm khoảng 90%.
• Thông tin nguyên tử chiếm ít không gian trong các cột quan hệ hơn so với mô tả XML dài dòng của chúng.
• Dữ liệu nguyên tử có thể được truy vấn bằng các phương pháp quan hệ truyền thống, với dữ liệu không phân cấp thì các phương pháp này có hiệu quả hơn so với tìm kiếm XML.
• Vì mỗi nguyên tử được biểu diễn trong một hàng riêng, nên các chỉ mục có thể giúp tăng tốc độ tìm kiếm các nguyên tử cụ thể trong một mục PDBML nhất định.

Lược đồ cơ sở dữ liệu được chọn có hai bảng, được hiển thị trong Liệt kê 3. Bảng đầu tiên (xmlrpdb.pdbxml) có một hàng cho mỗi mục PDB. Bảng này chỉ có hai cột:

• Cột khóa chính pdb_id giữ mã định danh bốn ký tự của mục PDB trong thuộc tính XML entry_id.
• Cột XML pdbxml_file giữ toàn bộ tài liệu PDBML trừ <atom_siteCategory>.

Bảng thứ hai (xmlrpdb.atom_site) có một hàng quan hệ cho mỗi tọa độ nguyên tử (tức là, với mỗi phần tử <atom_site> trong một tài liệu PDBML). Cột pdb_id là khóa ngoài liên kết các tọa độ nguyên tử với tài liệu PDBML tương ứng trong bảng pdbxml.

Cả hai bảng được lưu trữ trong các vùng bảng có kích thước trang 32-KB để tối đa hóa các truy vấn phân tích hiệu năng để đọc một số lượng lớn các hàng.

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;

Theo tùy chọn, CHECK các ràng buộc pdbxml (Kiểm tra) có thể được định nghĩa trên bảng pdbxml để đảm bảo rằng mã định danh bốn ký tự của PDB phù hợp với tiêu chuẩn PDB. Ký tự đầu tiên phải là một số từ 1 đến 9 và ba ký tự tiếp theo phải là số giữa 0 và 9 hoặc ký tự chữ hoa giữa A và Z (xem Liệt kê 4).

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'));

Điền vào lược đồ cơ sở dữ liệu lai

Quá trình dựa trên khái niệm về chèn một tài liệu PDBML vào lược đồ cơ sở dữ liệu lai của chúng ta được minh họa trong Hình 3. Dữ liệu <atom_siteCategory> cần được trích xuất và loại bỏ khỏi tài liệu XML và được chèn vào bảng quan hệ atom_site (màu xanh). Tài liệu thu nhỏ này tự nó được chèn vào bảng pdbxml. Chúng ta gọi quá trình này là sự phân chia trang nguyên tử (atom site).

Do khối lượng dữ liệu rất lớn, nên sự phân chia trang nguyên tử (việc điền vào lược đồ cơ sở dữ liệu lai) cần có hiệu năng cao. Do đó, cần làm giảm việc phân tích cú pháp XML tốn kém càng nhiều càng tốt. Xem lại các tọa độ nguyên tử theo định dạng XML trong Liệt kê 2, chúng ta thấy rằng 94,5% các ký tự được đánh dấu và chỉ có 5,5% của ký tự là những giá trị thực tế. Do đó, tỷ lệ đánh dấu so với giá trị là rất cao, có nghĩa là có thể yêu cầu phân tích cú pháp XML rất nhiều để trích xuất một lượng dữ liệu có thể sử dụng được tương đối nhỏ. Bạn sẽ hiểu ngay việc xem xét này đã ảnh hưởng đến quyết định của chúng ta như thế nào về cách điền vào hai bảng.

Một tùy chọn để điền vào bảng atom_site quan hệ là sử dụng các câu lệnh INSERT có chức năng XMLTABLE. Một câu lệnh như vậy có thể phân tích toàn bộ tài liệu PDBML và trích xuất thông tin nguyên tử để chèn vào làm các hàng quan hệ. Ngoài ra, một biểu thức XQuery Update (Cập nhật Xquery) có thể xóa cây con <atom_siteCategory> khỏi mỗi tài liệu PDBML đã chèn vào bảng pdbxml. Một biểu thức XQuery Update như vậy cũng có thể thuộc về một câu lệnh INSERT sao cho <atom_siteCategory> được loại bỏ trước khi viết nó vào cột XML, hơn là thực hiện một bước riêng sau khi chèn.

Một tùy chọn khác là sử dụng một bộ xử lý trước chuyên dụng nằm ngoài cơ sở dữ liệu để trích xuất dữ liệu nguyên tử vào một tệp phẳng quan hệ và loại bỏ nó khỏi mỗi tài liệu PDBML. Một bộ xử lý trước như vậy đã được thực hiện trong C++ và có những lợi ích sau:

• Bộ xử lý trước có thể thêm các chú thích mong muốn vào dữ liệu, ví dụ như thông tin từ các liên kết theo trình tự và cấu trúc hay các phép chuyển đổi hình học phụ thuộc vào ứng dụng như các phép xoay vòng hoặc các chuyển dịch các tọa độ nguyên tử.
• Bộ xử lý trước có thể được thực hiện mà không cần sử dụng một trình phân tích cú pháp XML đa năng. Để thay thế, nó được thiết kế và tối ưu hóa cho cấu trúc tệp cụ thể của các tài liệu PDBML. Nó khai thác kiến thức đặc biệt về cấu trúc phẳng của dữ liệu nguyên tử, sự tồn tại của ký tự dòng mới giữa các phần tử và các đặc điểm khác. Kết quả là, bộ xử lý trước chuyên dụng chạy nhanh hơn ít nhất là 10 lần so với bất kỳ giải pháp nào có phân tích cú pháp XML.

Việc xử lý trước tập dữ liệu của 6.029 tài liệu PDBML đã nén (tức là, có dung lượng 83 GB đã giải nén) và tải dữ liệu đã chuẩn bị vào bảng pdbxml và bảng atom_site chỉ mất 1 giờ và 44 phút. Bộ xử lý trước có sẵn để tải về (xem phần Tải về).

Nén dữ liệu

Xét khối lượng dữ liệu trong kho lưu trữ PDB cũng như sự tăng trưởng nhanh chóng của nó, việc nén dữ liệu trong DB2 là rất có ích. Việc này làm giảm tiêu dùng bộ nhớ và cải thiện hiệu năng. Mặc dù nén và giải nén trong DB2 cũng tiêu dùng thêm một số chu kỳ CPU, nhưng nén dữ liệu cũng làm giảm số lượng các hoạt động Vào/Ra (I/O) vật lý cần thiết để đọc một số lượng dữ liệu nhất định từ đĩa. Hơn nữa, các trang đã nén của một vùng bảng DB2 vẫn được nén tiếp trong nhóm bộ đệm DB2 của bộ nhớ chính. Kết quả là, nén dữ liệu cho phép có nhiều dữ liệu trong bộ nhớ hơn không nén, làm tăng tỷ lệ truy cập vào nhóm bộ đệm và làm cho việc sử dụng bộ nhớ có sẵn cao hơn. Chúng ta đã thấy rằng lợi ích nén cho Vào/ra và bộ nhớ có nhiều tác dụng hơn so với chi phí bổ sung về CPU và dẫn đến hiệu năng tổng thể cao hơn.

Các lệnh sau trong Liệt kê 5 đã được sử dụng để nén cả hai bảng.

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;

Việc giảm tiêu dùng dung lượng lưu trữ được tóm tắt trong Bảng 1. Sau khi nén, thông tin đã chứa trong 6.029 tài liệu PDBML có thể được lưu trữ trong số trang ít hơn là 67,4% (tức là, dung lượng lưu trữ ít hơn ba lần so với không nén).

Với một kích thước trang 32 KB, dung lượng lưu trữ cuối cùng của 144.000 trang tương đương với 4,4 GB, chỉ bằng 5,3% của 83 GB dung lượng dữ liệu thô ban đầu. Nếu chúng ta ngoại suy tỷ lệ này thành tổng kích thước hiện tại của kho lưu trữ PDB, chúng ta thấy rằng 0,75 TB thông tin PDB sẽ được lưu trữ trong DB2 khi sử dụng chỉ khoảng 40,7 GB dung lượng lưu trữ, cộng với một số dung lượng lưu trữ cho các chỉ mục.

Việc tiết kiệm dung lượng lưu trữ rất lớn này bắt nguồn từ hai yếu tố. Đầu tiên, đã loại bỏ tỷ lệ đánh dấu cao so với giá trị trong thông tin nguyên tử bằng cách chuyển đổi các tọa độ nguyên tử sang định dạng quan hệ trong bước xử lý trước. Thứ hai, việc nén dữ liệu của DB2 rút gọn dữ liệu XML và dữ liệu quan hệ còn lại đến 3 lần.

Phân vùng cơ sở dữ liệu

Mặc dù làm giảm đáng kể việc tiêu dùng dung lượng lưu trữ, dung lượng dữ liệu PDB vẫn tiếp tục phát triển nhanh chóng. Ngoài ra, có thể làm giảm thời gian đáp ứng của các truy vấn phân tích phức tạp bằng cách trải dữ liệu trên nhiều phân vùng cơ sở dữ liệu, ví dụ tất cả các phân vùng làm việc song song với dữ liệu đã gán cho chúng. Các phân vùng cơ sở dữ liệu có thể lưu trữ trên cùng một máy tính để khai thác tất cả sức mạnh CPU của một hệ thống đa lõi hoặc chúng có thể được trải rộng trên nhiều máy tính theo một cấu hình không chia sẻ. Tính năng phân vùng Cơ sở dữ liệu DB2 (DPF) có sẵn thông qua IBM InfoSphere® Warehouse (Kho dữ liệu InfoSphere của IBM), là một gói phần mềm có chứa DB2 với các tính năng cao cấp, cũng như các công cụ thiết kế, báo cáo và quản lý cơ sở dữ liệu bổ sung.

Khi sử dụng DPF, chúng ta khuyến cáo nên phân phối dữ liệu trong bảng pdbxml và bảng atom_site trên các phân vùng cơ sở dữ liệu bằng cách chia nhỏ các giá trị của cột pdb_id. Điều này đạt được bằng cách thêm mệnh đề DISTRIBUTE BY HASH(pdb_id) vào câu lệnh CREATE TABLE tương ứng. Số lượng lớn các giá trị khác nhau trong cột pdb_id đảm bảo việc phân phối các hàng khá chính xác trên các phân vùng cơ sở dữ liệu. Việc phân phối cả hai bảng bằng cách chia nhỏ khóa nối của chúng (pdb_id) cũng đảm bảo rằng tất cả các hàng nguyên tử cho một tài liệu PDBML cụ thể được lưu trữ trong cùng phân vùng cơ sở dữ liệu như chính tài liệu PDBML đó. Sự sắp xếp này ngụ ý rằng các phép nối giữa hai bảng có thể luôn được xem xét trong mỗi phân vùng cơ sở dữ liệu và không bao giờ đòi hỏi dữ liệu đi kèm trên các phân vùng.

Phân vùng theo phạm vi

Phân vùng theo phạm vi (còn được gọi là phân vùng bảng) cho phép bạn phân vùng dữ liệu trong một bảng theo giá trị trong một cột cụ thể, sao cho các hàng có cùng một giá trị sẽ nằm trong cùng một phân vùng. Khái niệm về phân vùng theo phạm vi là trực giao với phân vùng cơ sở dữ liệu. Nếu sử dụng phân vùng cơ sở dữ liệu cùng với phân vùng theo phạm vi, các hàng trong một bảng trước tiên được chia nhỏ trên các phân vùng cơ sở dữ liệu và sau đó được phân vùng theo phạm vi trong mỗi phân vùng cơ sở dữ liệu.

Phân vùng theo phạm vi có thể dùng cho nhiều mục đích. Một mục đích là dễ nhập dữ liệu mới vào bộ nhớ và dễ lấy ra dữ liệu cũ khỏi bộ nhớ. Mục đích khác là để cải thiện hiệu năng dựa trên việc loại bỏ phân vùng khi trình tối ưu hóa truy vấn DB2 xác định rằng chỉ có một tập con của các phân vùng cần được kiểm tra để trả lời như truy vấn cụ thể. Đối với PDB, phân vùng theo phạm vi đã được triển khai để lợi dụng việc loại bỏ phân vùng, chứ không phải để đơn giản hóa vào và ra dữ liệu của bộ nhớ.

Chúng ta quyết định phân vùng theo phạm vi bảng atom_site bằng cột pdbx_PDB_model_num với lý do sau đây: Hãy nhớ rằng cấu trúc cấp ba của một protein có thể được xác định bằng thực nghiệm với một phương pháp được gọi là NMR (Cộng hưởng từ hạt nhân), tạo ra nhiều cấu trúc cấp ba cho cùng một protein. Những biến thể này được gọi là các mô hình và được trường pdbx_PDB_model_num đánh số. Một giá trị là pdbx_PDB_model_num = 1 nhận biết mô hình (mặc định) đầu tiên của một protein. Các biến thể bổ sung là các mô hình không-mặc định của cùng một protein và có pdbx_PDB_model_num >= 2. Các protein, đã được Nhiễu xạ qua tia X xác định bằng cấu trúc, có một mô hình duy nhất có pdbx_PDB_model_num = 1.

Liệt kê 6 cho thấy định nghĩa mở rộng của bảng atom_site với phân vùng theo phạm vi. Tất cả các tọa độ nguyên tử thuộc về mô hình đầu tiên (pdbx_PDB_model_num = 1) được lưu trữ trong một phân vùng, trong khi các biến thể bất kỳ (pdbx_PDB_model_num >= 2) được lưu trữ trong một phân vùng khác. Mặc dù chỉ có khoảng 16% của tất cả các protein trong PDB đang có các biến thể do NMR tạo ra, nhưng số các biến thể của chúng lớn đến mức cả hai phân vùng có xấp xỉ cùng một số lượng các bản ghi.

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 );

Chúng ta đã chọn lược đồ phân vùng theo phạm vi này vì nhiều truy vấn PDB thường phân biệt giữa các mô hình protein mặc định và không mặc định và nên có thể lợi dụng việc phân vùng. Ví dụ, một truy vấn phân tích tất cả hoặc hầu hết các mô hình mặc định chỉ cần quét phân vùng DEF_MODELS, làm giảm Vào/ra cần thiết đến một nửa.

Phân cụm nhiều chiều

Ngoài phân vùng theo phạm vi, phân cụm nhiều chiều (MDC) có thể được sử dụng để phân cụm các hàng trong một bảng dựa trên một hoặc nhiều cột. Các hàng có giá trị giống nhau trong các cột phân cụm được lưu trữ vật lý với nhau trong cùng một ngăn bộ nhớ. Điều này có thể cải thiện rất nhiều hiệu năng của các truy vấn có ràng buộc và chọn dữ liệu cùng với một hoặc nhiều chiều phân cụm. Giống như DPF, MDC cũng có sẵn qua IBM InfoSphere Warehouse.

Việc chọn phân cụm các cột cần dựa trên tải truy vấn dự kiến sao cho việc phân cụm hỗ trợ các truy vấn phổ biến nhất và quan trọng nhất. Ví dụ, nhiều truy vấn PDB có thể tìm kiếm dữ liệu nguyên tử dựa trên các axit amin đã có. Vì vậy, có thể có ích để phân cụm bảng atom_site dựa trên label_comp_id của cột, mà, trong hầu hết các tài liệu, chứa mã ba ký tự cho axit amin. Để đạt được cách phân cụm này, hãy thêm mệnh đề sau vào câu lệnh CREATE TABLE thứ hai trong Liệt kê 3: ORGANIZE BY DIMENSIONS(label_comp_id).

Một ví dụ khác là phân cụm bảng atom_site bằng cột group_PDB. Chúng ta đã đánh giá việc phân cụm này với một vài truy vấn mẫu để hạn chế việc tìm kiếm của chúng theo một giá trị group_PDB duy nhất (tức là "HETATOM") và đã nhận thấy rằng nó có thể cải thiện hiệu năng truy vấn gấp bốn lần.

Các truy vấn và hiệu năng PDB

Trong phần này, chúng ta thảo luận hai truy vấn mẫu để chứng tỏ:

• Sự dễ dàng thậm chí có thể thực hiện phân tích dữ liệu PDB phức tạp.
• Lợi ích của các quyết định thiết kế cơ sở dữ liệu được mô tả trong các phần trước.

Truy vấn trong Liệt kê 7 chọn mã định danh PDB, độ phân giải và mô tả từ tất cả các mục PDB ở đây phương pháp thực nghiệm là "X-RAY DIFFRACTION" (Nhiễu xạ qua tia X) và độ phân giải (ls_d_res_high) thấp hơn 2,5. Độ phân giải được biểu diễn bằng Ångstrøm (1Å = 0,1 nanomet) và dùng làm chỉ tiêu chất lượng để phân tích các cấu trúc nguyên tử. Các cấu trúc có độ phân giải thấp hơn 2Å là các cấu trúc có độ phân giải cao (ví dụ, các vị trí của các nguyên tử của chúng có thể được xác định rất chính xác). Các cấu trúc có độ phân giải cao hơn 3Å kém chính xác hơn và thường bị bỏ qua.

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;

Kết quả của truy vấn này được thể hiện trong Liệt kê 8. Một trong các lợi ích của việc sử dụng DB2 pureXML chứ không phải mã tùy chỉnh là dễ sửa đổi các truy vấn SQL/XML để cải thiện việc tìm kiếm. Ví dụ, Liệt kê 7 có ba dòng bình luận với một mệnh đề WHERE bổ sung. Chúng có thể được sử dụng để lọc thêm bộ mô tả để tìm ra những cấu trúc nào không được mô tả hoặc không thể được mô tả.

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.

Các biến vị ngữ trong truy vấn trong Liệt kê 7 có tính chọn lọc kém sao cho việc quét toàn bộ bảng của bảng pdbxml là bắt buộc. Bảng 2 tóm tắt hiệu năng truy vấn quét bảng này đã được lợi từ hai quyết định thiết kế của chúng ta như thế nào: nén và phân chia trang nguyên tử. Trong môi trường của chúng ta, việc quét bảng này đã đến giới hạn Vào/ra. Chức năng nén của DB2 đã làm giảm nhẹ nghẽn cổ chai Vào/ra và đã giảm thời gian chạy truy vấn hơn 40% (từ 244 xuống 128 giây). Việc trích xuất dữ liệu trang nguyên tử vào một bảng quan hệ riêng biệt sẽ giảm đáng kể kích thước của bảng pdbxml, cải thiện hiệu năng truy vấn gần 4,5 lần, từ 138 xuống 31 giây.

Liệt kê 9 cho thấy một truy vấn mẫu khác, xác định các nguyên tử khác nhau — hoặc các ion — thường xuất hiện bao nhiêu lần trong các hợp chất khác nhau. Mệnh đề WHERE hạn chế việc tìm kiếm cái gọi là các nguyên tử khác loại và chỉ xem xét mô hình đầu tiên của mỗi protein.

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;

Một tập con của các hàng kết quả được hiển thị trong Liệt kê 10. Hợp chất hóa học được phát hiện thường xuyên nhất là nước (HOH) có oxy (O) là một nguyên tử của nó. Số lượng các Hy-đro được ghi lại, được chỉ rõ là H1 và H2 cho HOH, là thấp vì việc phát hiện ra các Hy-đrô đòi hỏi có độ phân giải rất cao mà không phải lúc nào cũng đạt được.

Hê-mô-glô-bin (của con người) là một protein bao gồm nhiều phân tử và một phân tử như vậy có thể tương tác với một hợp chất không phải là protein được gọi là heme (phần hê-mô-glô-bin có chứa sắt). Heme (HEM) là một cấu trúc hữu cơ có protein, nhiều nguyên tử có khả năng đặt ion sắt (FE) ở trung tâm của nó. Ion sắt này, có sẵn của nó, là rất quan trọng để kết buộc oxy. Kết quả trong Liệt kê 10 cho thấy rằng sắt xuất hiện thường xuyên cùng với các hợp chất heme. Mặc dù đây là một ví dụ đơn giản, những nó chứng tỏ để phát hiện các mối tương quan quan trọng trong dữ liệu PDB và có được sự hiểu biết tốt hơn về chức năng của protein và tương tác ở mức phân tử đã trở nên có hiệu quả như thế nào.

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

Bảng 3 cho thấy cách thiết kế cơ sở dữ liệu của chúng ta chọn phân chia trang nguyên tử, nén, phân vùng theo phạm vi và phân cụm nhiều chiều có thể đưa ra hiệu năng tuyệt vời, ngay cả khi không có các chỉ mục truy vấn cụ thể nào tồn tại.

Về đầu trang

Tóm tắt

Bài này đã mô tả cách sử dụng các tính năng quản lý dữ liệu quan hệ và pureXML trong DB2 để lưu trữ và truy vấn có hiệu quả PDB (Ngân hàng dữ liệu Protein). Dựa vào các đặc điểm bên trong của dữ liệu protein, chúng ta đã thiết kế một lược đồ cơ sở dữ liệu lai tối ưu hóa. Để có hiệu năng tốt nhất và tiêu dùng dung lượng lưu trữ tối thiểu, chúng ta khuyến cáo sử dụng phân vùng cơ sở dữ liệu, phân vùng theo phạm vi, nén và phân cụm nhiều chiều. Ngoài ra, sự kết hợp giữa các chỉ mục XML và các chỉ mục quan hệ có thể cải thiện hiệu năng truy vấn thêm nữa. PDB dựa trên DB2 tiếp tục được sử dụng cho các nghiên cứu, ví dụ như tìm kiếm toàn bộ PDB đối với các tương tác protein cụ thể và giúp giải thích sự tương tác khác thường ở mức cấu trúc.

Lời cảm ơn

Sự phát triển PDB dựa trên DB2 đã được thực hiện trong nhóm nghiên cứu Tin sinh học cấu trúc của Maria Teresa Pisabarro, Trung tâm Công nghệ sinh học, Đại học Kỹ thuật Dresden, Đức. Quỹ của người đồng sáng lập SAP Klaus Tschira đã tài trợ một học bổng cho dự án này. Ngoài ra, nhờ sự giúp đỡ của Henrik Loeser cho công việc được mô tả trong bài này và Viện Sinh học các hệ thống y tế Berlin (BIMSB) của Trung tâm Max Delbrück (MDC) với Berlin-Buch Y học phân tử, Đức, cho việc cung cấp máy chủ sản xuất.

Về đầu trang

Tải về

Thông tin về phương thức tải

Tài nguyên

Học tập

• Truy cập vào PDB.org để biết thêm thông tin về Protein Data Bank và PDBML định dạng XML.
  
  
• Tìm hiểu thêm về PDBML định dạng XML.
  
  
• Để biết một giới thiệu về dữ liệu PDB, hãy đọc "Hiểu biết về dữ liệu PDB: Xem Các cấu trúc."
  
  
• Nhận toàn bộ tài liệu XML có đoạn trích được thể hiện trong Liệt kê 1 và 2.
  
  
• Nhận được kiến thức toàn diện về DB2 pureXML với Sách tham khảo DB2 pureXML.
  
  
• Tìm hiểu thêm về nén, phân vùng và phân cụm dữ liệu XML trong bài "Nâng cao hiểu biết nghiệp vụ và khả năng mở rộng của dữ liệu XML với các tính năng DB2 9.7 pureXML."
  
  
• Để biết thêm về các tài nguyên DB2 pureXML, hãy khám phá Wiki hỗ trợ DB2 pureXML.
  
  
• Đọc blog Cơ sở dữ liệu XML nguyên gốc để cập nhật tin tức và các lời khuyên và các thủ thuật XML mới nhất.
  
  
• Tìm hiểu về Sáng kiến học đường của IBM.
  
  
• Tìm hiểu thêm về Quản lý thông tin tại Vùng Quản lý thông tin của developerWorks. Tìm tài liệu kỹ thuật, các bài báo hướng dẫn, kiến thức, các bản tải về, thông tin sản phẩm và nhiều hơn nữa.
  
  
• Theo sát với các sự kiện kỹ thuật và webcast của developerWorks.
  
  
• Làm theo developerWorks trên Twitter.
  
  

Lấy sản phẩm và công nghệ

• Tải về bản DB2 Express-C miễn phí.
  
  
• Xây dựng dự án phát triển tiếp theo của bạn với phần mềm dùng thử của IBM, có sẵn để tải về trực tiếp từ developerWorks.
  
  

Thảo luận

• Xem các blog developerWorks và tham gia vào cộng đồng developerWorks.
  
  

Đôi nét về các tác giả

Gerd Anders có bằng khoa học máy tính của trường Đại học Humboldt ở Berlin. Ông tập trung vào tin-sinh học và sử dụng các hệ thống cơ sở dữ liệu để quản lý và xử lý có hiệu quả khối lượng dữ liệu rất lớn trong và cho khoa học đời sống. Ngân hàng dữ liệu Protein (Protein Data Bank - PDB) dựa trên DB2 là một công trình chủ yếu của luận án tiến sĩ của ông, cung cấp một cơ sở có giá trị cho một số ứng dụng hướng DB2 và khai thác toàn bộ tiềm năng của PDB. Ngoài ra, ông cũng là một nhà thử nghiệm của phiên bản beta không công khai của DB2 9.5 cho Linux, UNIX và Windows.

Matthias Nicola người lãnh đạo kỹ thuật về hiệu năng cơ sở dữ liệu XML tại Silicon Valley Lab của IBM. Công việc của ông tập trung vào tất cả các lĩnh vực về hiệu năng XML trong DB2, bao gồm XQuery, SQL/XML và tất cả các tính năng XML nguyên sơ trong DB2. Matthias Nicola cộng tác chặt chẽ với các đội phát triển XML DB2 cũng như với các khách hàng và các đối tác kinh doanh, là những người đang sử dụng XML, hỗ trợ họ trong việc thiết kế, triển khai thực hiện và tối ưu hóa các giải pháp XML. Trước khi gia nhập IBM, Matthias làm việc với hiệu năng kho dữ liệu cho Informix Software. Ông cũng đã có bốn năm làm việc trong các dự án nghiên cứu và các dự án công nghiệp trên cơ sở dữ liệu phân tán và nhân bản. Ông nhận bằng tiến sĩ khoa học máy tính vào năm 1999 ở Đại học Kỹ thuật Aachen, Đức.

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Giới thiệu
• Thách thức
• Nội dung của PDB
• Cơ sở dữ liệu thử nghiệm
• Các khuyến cáo thiết kế cơ sở dữ liệu cho PDB
• Tóm tắt
• Lời cảm ơn
• Tải về
• Tài nguyên
• Đôi nét về các tác giả
• Bình luận