Quản lý Ngân hàng dữ liệu Protein với DB2 pureXML
lượt xem 5
download
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...
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: Quản lý Ngân hàng dữ liệu Protein với DB2 pureXML
- 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. 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.
- Hì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.
- 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 () đã 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) ... Pisabarro, M.T. ... ... ABL TYROSINE KINASE, PEPTIDE P41 CRYSTAL STRUCTURE OF THE ABL-SH3 DOMAIN COMPLEXED WITH A DESIGNED HIGH-AFFINITY PEPTIDE LIGAND: IMPLICATIONS FOR SH3-LIGAND INTERACTIONS ... COMPLEX(TRANSFERASE/PEPTIDE) COMPLEX (TRANSFERASE-PEPTIDE), SIGNAL TRANSDUCTION,SH3 DOMAIN, COMPLEX (TRANSFERASE-PEPTIDE) complex ...
- 1 ... 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. 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 37.41 1.039 16.834 18.876 A N ASN 1 ATOM A
- N ASN 1 1 1.00 1 N 36.15 -0.213 16.205 18.364 ... 33.97 -0.549 16.779 16.986 ... ... 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ỏ 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ừ .
- 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ử 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ự
- đầ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 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
- 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 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 đượ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. 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.
- 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. Liệt kê 6. Định nghĩa bảng với phân vùng theo phạm vi 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. Liệt kê 7. Truy vấn 10 bản ghi hàng đầu có độ phân giải tia X tốt nhất 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
- 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. Bảng 2. Thời gian đáp ứng (không có các chỉ mục) của truy vấn trong Liệt kê 7 Phân chia trang nguyên tử Nén Thời gian đáp ứng Không Không244 giây Không Có 138 giây Có Có 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. Liệt kê 9. Phân tích về các sự xuất hiện của nguyên tử khác loại 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.
- Liệt kê 10. Tập con của kết quả được truy vấn trong Liệt kê 9 tạo ra 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. Bảng 3. Các thời gian đáp ứng (không có các chỉ mục) của truy vấn trong Liệt kê 9 Phân chia trang nguyên tửNénPhân vùng theo phạm vi MDC Thời gian đáp ứng Có Có Không Không38,7 giây Có Có Có Không25,8 giây Có Có Có Có 5,5 giây 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.
CÓ THỂ BẠN MUỐN DOWNLOAD
-
HỌC SQL SERVER 2000
61 p | 2264 | 828
-
Tài liệu sql server 2005
101 p | 1224 | 521
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 1 - GV. Cao Thị Nhâm (HV Ngân hàng)
26 p | 323 | 79
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 2 - GV. Cao Thị Nhâm (HV Ngân hàng)
33 p | 259 | 75
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 4 - GV. Cao Thị Nhâm (HV Ngân hàng)
30 p | 232 | 69
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 6 - GV. Cao Thị Nhâm (HV Ngân hàng)
43 p | 194 | 64
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 5 - GV. Cao Thị Nhâm (HV Ngân hàng)
24 p | 182 | 59
-
Bài giảng Quản trị cơ sở dữ liệu Oracle: Chương 3 - GV. Cao Thị Nhâm (HV Ngân hàng)
14 p | 187 | 55
-
Bài giảng Quản trị cơ sở dữ liệu Oracle - GV. Cao Thị Nhâm (HV Ngân hàng)
9 p | 259 | 43
-
Cách thức lưu trữ dữ liệu trong data center
2 p | 261 | 43
-
Bài giảng cơ sở dữ liệu - chương 1 - ĐH KHTN Tp.HCM
46 p | 381 | 38
-
Giới Thiệu về SQL Server
45 p | 175 | 27
-
Bài 1: Giới thiệu tổng quan về SQL Server 2000
44 p | 170 | 26
-
Bài giảng Phát triển hệ thống thông tin kinh tế: Chương 6 (tt) - Học viện Ngân hàng
26 p | 53 | 9
-
Bài giảng Phát triển hệ thống thông tin kinh tế: Chương 6 - Học viện Ngân hàng
27 p | 59 | 8
-
Mã hóa và quản lý dữ liệu nhạy cảm trên ổ đĩa Flash
3 p | 96 | 4
-
Quản lý dữ liệu thông minh trong lĩnh vực ngân hàng và các giải pháp
9 p | 25 | 3
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn