Quản lý Ngân hàng dữ liệu Protein với DB2 pureXML 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.. Về đầu
Trang 1Quản lý Ngân hàng dữ liệu Protein với DB2 pureXML
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
Trang 2Hình 1 Tăng trưởng của PDB trong vòng 20 năm qua
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
Trang 3Cấ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
Liệt kê 1 Đoạn trích của một tài liệu PDBML mẫu (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>
Trang 4
<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
Trang 5mộ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
Hình 2 Sơ đồ của một lược đồ cơ sở dữ liệu quan hệ đầy đủ với PDBML
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
Liệt kê 2 Các tọa độ nguyên tử trong 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>
Trang 6<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>
Trang 7Bả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
Liệt kê 3 Lược đồ cơ sở dữ liệu quan hệ/XML lại cho PDB trong 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;
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ự
Trang 8đầ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)
Liệt kê 4 Các ràng buộc CHECK để thực thi các giá trị pdb_id thích hợp
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)
Hình 3 Lưu trữ lai của một tài liệu PDBML có phân chia dữ liệu atom_site
Trang 9Do 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
Trang 10Các lệnh sau trong Liệt kê 5 đã được sử dụng để nén cả hai bảng
Liệt kê 5 Kích hoạt nén và các bảng REORG
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)
Bảng 1 Tiết kiệm dung lượng lưu trữ bằng nén dữ liệu
Trước khi nén Sau khi nén Tiết kiệm
xmlrpdb.pdbxml 176.256 trang 44.736 trang 74,6%
xmlrpdb.atom_site264.960 trang 99.264 trang 62,5%
Total 441.216 trang 144.000 trang67,4%
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
