소개

Protein Data Bank(PDB.org)는 생물학상의 분자(주로 단백질)와 관련된 구조적 데이터로 구성된 세계적인 아카이브이다. PDB(Protein Data Bank)는 이 생물학 데이터를 예치하고, 유지보수하고 처리하여 과학 커뮤니티에 자유롭게 제공하는 역할을 담당하는 다수의 멤버 조직에 의해 관리된다. 유연성과 확장성을 제공하고 데이터를 손쉽게 교환할 수 있게 하기 위해 PDB 데이터는 XML 형식으로 되어 있다. 이 XML 형식은 PDBML(Protein Data Bank Markup Language)이라고 하는 XML 스키마로 정의된다.

이 구조적 정보에는 단백질을 구성하는 분자의 원자에 대한 3-D 좌표가 포함되어 있다. 이러한 원자적 좌표를 3-D 구조 또는 3차 구조라고 한다. 단백질의 3차 구조는 단백질의 기능과 밀접한 관계가 있다. 따라서 3차 구조를 알면 단백질의 본질적인 기능을 수월하게 이해할 수 있다. 예를 들면, 3차 구조는 질병을 설명하거나 신약을 개발하는 데 유용하다. 3차 구조는 PDB에서 단백질 간의 상호 작용을 검색하는 데 사용될 수도 있다.

위로

문제점

2010년 12월 현재, PDB 저장소에는 5억 개가 넘는 원자적 좌표를 포함하고 있는 70,000개의 항목(XML 문서)이 있다. 압축되지 않은 전체 크기는 750GB를 초과한다. PDB에 있는 개별 XML 문서의 크기는 수 MB에서 1GB까지 다양하다. 최근 몇 년 동안 PDB 저장소가 급격하게 성장하면서(그림 1), PDB의 크기가 계속해서 상당히 증가할 것으로 예상된다. 따라서 이 정보를 검색하고 분석하는 작업이 언제나 문제가 되고 있다.

PDB 데이터를 분석하는 일반적인 방식은 PDBML 문서를 검색하는 일련의 스크립트나 사용자 정의 애플리케이션을 작성하여 매우 특별한 연구 문제를 해결하는 것이다. 이 방식에는 다음과 같은 단점이 있다.

• 새로운 연구가 시작될 때마다 사용자 정의 코드를 개발하는 작업이 시행되고 있으며 이러한 과정은 매우 노동집약적이고 시간이 많이 소비된다.
• 문서의 서브세트에만 관련 정보가 있는 경우에도 모든 문서를 구문 분석하고 검색해야 하기 때문에 성능이 좋지 않다.
• 기존 사용자 코드를 재사용하거나 결합하여 PDB 데이터를 대상으로 하는 새로운 쿼리나 다양한 쿼리를 작성하기가 어렵다.

DB2에는 예상되는 PDBML 문서의 용량을 처리하는 데 필요한 확장성과 XML 기능이 있기 때문에 이러한 문제점을 처리하기 위해 pureXML이 있는 DB2 V9.7.3이 선택되었다. 이외에도 DB2는 IBM Academic Initiative를 통해 비상업적인 용도에 한해 무료로 사용할 수 있다. 그 목적은 효과적인 데이터베이스 스키마에 PDB 정보를 저장하고, 관계형 및 XML 인덱스를 사용하여 효과적으로 검색하고, XQuery와 SQL/XML을 사용하여 PDB 정보를 대상으로 하는 훨씬 복잡한 쿼리를 표현하는 데 있었다.

위로

PDB의 컨텐츠

PDB에 적합한 DB2 데이터베이스 설계에 관해 살펴보기 전에 PDB 데이터를 조금 더 이해하는 것이 유용하다.

단백질의 3차 구조는 주로 X선 회절 또는 X선 결정이라고 하는 방법에 의해 실험적으로 결정되었다(해결됨). 이 방법보다 덜 사용되는 또 다른 방법은 Solution NMR(Nuclear Magnetic Resonance) 또는 NMR 분광이다. 생성된 XML 문서에서 단백질의 구조를 기술하는 방법은 단백질의 구조를 결정(해석)하는 방법에 따라 차이가 있으며, 특히 XML 파일의 크기에도 영향을 준다.

단백질은 동적인 분자이며, 따라서 단백질의 3차 구조는 환경에 따라 약간씩 변할 수 있다. 이러한 변화로 인해 NMR은 동일한 단백질의 약간 변화된 3차 구조를 표현하는 여러 가지 인스턴스(모델)를 방법론적으로 결정한다. 따라서, NMR로 생성된 단백질 데이터가 있는 XML 파일은 크기가 매우 커질 수 있다(예: 100MB ~ 1GB). 또한, DB2 범위 파티셔닝을 사용하여 단백질의 첫 번째(기본) 모델을 그 변종과 분리하는 방법과 그 이유를 나중에 이 기사에서 확인하게 된다.

리스트 1 에는 PDBML 문서에서 발췌한 내용이 표시되어 있다. 여기에서 연구 저자와 사용된 실험 방법(<PDBx:exptlCategory>)을 포함하여, 이러한 문서에서 나타날 수 있는 정보 범주 177개 중 4개를 확인할 수 있다. entry_id 속성은 이 문서의 고유 PDB ID를 나타낸다.

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

위로

테스트 데이터베이스

시간과 자원이 제한되어 있으므로 프로토타입을 제작하여 스토리지를 평가하고 DB2 데이터베이스에 있는 PDBML 문서를 인덱싱하고 쿼리하기 위해, 사용 가능한 전체 PDB 데이터 용량의 서브세트만 사용하기로 했다. 그러므로 6,029개의 문서 중 대표적인 샘플만 선택했으며 이에 따라 용량이 2010년 12월 현재, PDBML 아카이브 전체 용량의 10%인 83GB가 되었다. 이 문서 세트에는 XML 요소 17억 개가 포함되어 있으며 이 요소 중 154,000만 개의 요소가 원자적 좌표와 기타 정보를 사용하여 단백질의 3차 구조를 기술하고 있다.

PDBML 문서의 대표 샘플은 X선 회절에 의해 생성된 분자 정보(더 작은 문서, 모든 문서의 83%)가 있는 문서와 Solution NMR(더 큰 문서, 모든 문서의 16%)에 의해 생성된 분자 정보가 있는 문서의 비율을 정확하게 반영해야 한다. 이렇게 해야 작은 문서와 큰 문서가 혼재된 실제적 상황에서 데이터베이스 구성과 쿼리를 테스트할 수 있다.

이 연구를 위해 사용한 데이터베이스 서버는 듀얼코어 프로세스(AMD Opteron 8220)가 8개이고 기본 메모리가 256GB인 Sun X4600 M2이다. 운영 체제는 64비트 Ubuntu Linux이다. 스토리지는 하드웨어 제어기를 사용하여 하나의 논리적 볼륨(RAID5)으로 구성된 하드 드라이브(각각 698GB, 7,200rpm) 10개로 구성되었다.

위로

PDB를 위한 데이터베이스 설계 권장사항

이 섹션에서는 PDB 데이터를 저장 및 분석하는 데 필요한 간단하고 효과적인 데이터베이스를 지원하는 데 도움이 되는 일련의 데이터베이스 설계 권장사항을 설명한다. 이러한 권장사항에서는 데이터베이스 스키마, XML 및 관계형 스토리지 간의 선택, 인덱스 정의 및 파티셔닝과 클러스터링 옵션을 사용한 실제 데이터 구성을 다룬다.

하이브리드 XML/Relational 스토리지

현재 PDBML 문서에는 정보의 범주가 최대 177개까지 포함되며 범주는 대부분 선택적이다. 다수의 선택적 PDBML 요소를 이용하면 문서를 매우 유연하고 가변적으로 만들 수 있다. 완전한 관계형 데이터베이스 스키마로 PDBML을 표현하려면 테이블이 수백 개가 있어야 한다. 이러한 PDB용 관계형 데이터베이스 스키마는 2005년에 개발되었으며, 그림 2에 표시되어 있다. 400개가 넘는 테이블과 3,000개 이상의 열로 인해 이 스키마가 너무 복잡해졌다. 하나의 PDB 항목이 나누어져서 수백 개 이상의 테이블에 분산되어 있고 이로 인해 사용자가 어떤 정보가 어떤 테이블에 있는지 알기가 어렵기 때문에 이러한 데이터베이스를 이해하고 쿼리하기는 매우 어렵다. 그러므로 대부분의 PDBML 정보를 원래의 XML 형식으로 유지하고 하나의 XML 열에 저장하면 훨씬 더 단순하게 데이터베이스를 설계할 수 있고 사용자가 자연스럽게 이해할 수 있는 형식으로 데이터를 유지할 수 있다.

PDBML 데이터의 높은 변화성과 관련해서 한 가지 주목할만한 예외는 원자적 좌표와 이 좌표와 관련된 레이블이며, 리스트 2에 표시되어 있듯이 이러한 것들은 분자에 있는 모든 원자마다 반복되는 일정한 구조를 따른다. 일반적으로 단백질은 수많은 원자로 구성되며 원자적 좌표는 PDBML 문서의 90% 이상에서 표시되어 있다.

<PDBx:atom_siteCategory>
  <PDBx:atom_site id="1">
    <PDBx:B_iso_or_equiv>37.41</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>1.039</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.834</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.876</PDBx:Cartn_z>
    <PDBx:auth_asym_id>A</PDBx:auth_asym_id>
    <PDBx:auth_atom_id>N</PDBx:auth_atom_id>
    <PDBx:auth_comp_id>ASN</PDBx:auth_comp_id>
    <PDBx:auth_seq_id>1</PDBx:auth_seq_id>
    <PDBx:group_PDB>ATOM</PDBx:group_PDB>
    <PDBx:label_alt_id xsi:nil="true" />
    <PDBx:label_asym_id>A</PDBx:label_asym_id>
    <PDBx:label_atom_id>N</PDBx:label_atom_id>
    <PDBx:label_comp_id>ASN</PDBx:label_comp_id>
    <PDBx:label_entity_id>1</PDBx:label_entity_id>
    <PDBx:label_seq_id>1</PDBx:label_seq_id>
    <PDBx:occupancy>1.00</PDBx:occupancy>
    <PDBx:pdbx_PDB_model_num>1</PDBx:pdbx_PDB_model_num>
    <PDBx:type_symbol>N</PDBx:type_symbol>
  </PDBx:atom_site>
  <PDBx:atom_site id="2">
    <PDBx:B_iso_or_equiv>36.15</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.213</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.205</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.364</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  <PDBx:atom_site id="3">
    <PDBx:B_iso_or_equiv>33.97</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.549</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.779</PDBx:Cartn_y>
    <PDBx:Cartn_z>16.986</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  ...
</PDBx:atom_siteCategory>

원자 정보의 균일한 구조는 전통적인 관계형 테이블에 매우 적합하다. 사실상, 원자 좌표와 레이블은 비계층 구조적 데이터이므로 XML은 최상의 선택이 아니다. 따라서 하이브리드 데이터베이스 스키마를 사용하여 atom_site 정보는 관계형 테이블에 저장하고 나머지 각 PDBML 문서는 XML 열에 저장하되, <atom_siteCategory>는 문서에서 제거하기로 한다. 이렇게 하면 몇 가지 이점이 생긴다.

• PDBML 문서의 크기가 줄어들면 데이터베이스가 훨씬 더 작아지고 따라서 XML 쿼리의 성능뿐만 아니라 삽입 및 로드 성능이 개선된다. 데이터 삽입이나 로드와 관련된 XML 구문 분석 노력이 약 90% 감소된다.
• 원자 정보는 상세한 XML 표현에서보다 관계형 열에서 공간을 덜 차지한다.
• 비계층 구조적 데이터의 경우에는 관계형 방법을 사용하는 것이 XML 탐색보다 더 효과적이므로 원자 데이터는 전통적인 관계형 방법을 사용하여 쿼리한다.
• 각 원자는 별도의 열에서 표현되므로 인덱스를 사용하면 주어진 PDBML 항목 내에서 특정 원자를 검색하는 속도를 일부 개선할 수 있다.

리스트 3에 표시되어 있듯이 선택된 데이터베이스 스키마는 두 개의 테이블로 구성된다. 첫 번째 테이블(xmlrpdb.pdbxml)에는 각 PDB 항목을 위한 열이 하나 있다. 이 테이블에는 열이 두 개만 있다.

• 기본 키인 pdb_id에는 네 개의 문자로 구성된 PDB 항목 ID(XML 속성 entry_id)가 저장된다.
• XML 열인 pdbxml_file에는 <atom_siteCategory>를 제외한 전체 PDBML 문서가 저장된다.

두 번째 테이블(xmlrpdb.atom_site)에는 각 원자 좌표(PDBML 문서의 각 <atom_site> 요소)의 관계형 열이 포함되어 있다. pdb_id 열은 원자 좌표를 pdbxml 테이블에 있는 해당 PDBML 문서에 링크하는 외부 키이다.

다수의 열을 읽는 성능 분석적 쿼리를 최대화하기 위해 이 두 가지 테이블을 페이지 크기가 32KB인 테이블 공간에 모두 저장한다.

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 ID가 PDB 표준을 준수하도록 할 수 있다. 첫 번째 문자는 1과 9 사이에 있는 숫자이어야 하고 다음 세 개의 문자는 0과 9사이에 있는 숫자이거나 A와 Z 사이에 있는 대문자이어야 한다(리스트 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'));

하이브리드 데이터베이스 스키마 채우기

PDBML 문서를 하이브리드 데이터베이스 스키마에 삽입하는 개념적 프로세스가 그림 3에 표시되어 있다. XML 문서에서 <atom_siteCategory> 데이터를 추출하여 제거한 후, atom_site 테이블(파란색)에 삽입해야 한다. 크기가 줄어든 문서 자체는 pdbxml 테이블에 삽입된다. 이 프로세스를 원자 사이트 분리(atom site separation)라고 한다.

데이터 용량이 크기 때문에 원자 사이트 분리(하이브리드 데이터베이스 스키마를 채우는 것)를 통해 고성능을 확보해야 한다. 따라서 대가를 많이 치루어야 하는 XML 구문 분석이 가능한 만이 줄어든다. 리스트 2에 있는 XML 형식의 원자 좌표를 다시 살펴보면 문자의 94.5%는 마크업이며 5.5%만 실제 값이라는 사실을 확인할 수 있다. 따라서 마크업 대 값의 비율이 매우 높으며, 따라서 비교적 용량이 적은 사용 가능한 데이터를 추출하려면 XML 구문 분석이 많이 필요하다. 이러한 고려사항이 앞에서 언급한 두 가지 테이블을 채우는 방법을 결정하는 데 어떻게 영향을 주는지를 바로 이해하게 될 것이다.

관계형 atom_site 테이블을 채우기 위한 한 가지 옵션은 INSERT문을 XMLTABLE 함수와 함께 사용하는 것이다. 이러한 명령문은 전체 PDBML 문서를 구문 분석하여 관계형 열로서 삽입할 원자 정보를 추출한다. 이외에도 XQuery Update 표현식을 사용하여 pdbxml 테이블에 삽입된 각 PDBML 문서에서 <atom_siteCategory> 서브트리를 삭제할 수 있다. 이러한 문서를 삽입한 후에 별도의 단계를 수행하기보다는 문서를 XML 열에 쓰기 전에 <atom_siteCategory>가 제거되도록 XQuery Update 표현식을 INSERT문에 삽입할 수도 있다.

또 다른 옵션은 데이터베이스 외부에서 특수 목적의 프리프로세서를 사용하여 원자 데이터를 일반 관계형 파일로 추출하고 각 PDBML 문서에서 원자 데이터를 제거하는 것이다. 이러한 프리프로세서는 C++로 구현되었으며 다음과 같은 이점이 있다.

• 시퀀스와 구조 배열 또는 애플리케이션에 종속적인 기하학적 변환(예: 회전) 또는 원자 좌표 변환과 같은 데이터에 원하는 어노테이션을 추가할 수 있다.
• 범용 XML 구문 분석기를 사용하지 않고도 구현할 수 있다. 그 대신 PDBML 문서의 특정 파일 구조에 맞게 설계되고 최적화된다. 이 프리프로세서는 원자 데이터의 일반 구조, 요소 간에 줄 바꾸기 문자의 유무 및 기타 특성에 관한 특정 지식을 활용한다. 결과적으로 전문 프리프로세서는 XML 구문 분석을 사용하는 솔루션보다 10배 이상 빠르다.

gzip으로 압축된 6,029개의 PBML 문서(압축을 해제하면 83GB)로 구성된 데이터 세트를 전처리하고 준비된 데이터를 pdbxml 테이블과 atom_site 테이블로 로드하는 데 단지 1시간 44분이 걸릴 뿐이다. 프리프로세서는 다운로드 가능하다(다운로드 참조).

압축

PDB 아카이브의 데이터 양과 성장 속도를 고려하면 DB2 데이터를 압축하는 것이 유용하다. 이렇게 하면 스토리지 소비를 줄이고 성능을 개선할 수 있다. DB2에서 압축을 하거나 압축을 해제하면 CPU 주기가 추가로 약간 더 소비되지만, 압축을 하면 디스크에서 일정한 데이터 양을 읽는 데 필요한 실제 I/O 조작 수를 줄일 수 있다. 게다가 DB2 테이블 스페이스의 압축된 페이지는 기본 메모리의 DB2 버퍼 풀에서 압축된 상태를 유지한다. 따라서 압축을 하면 압축을 하지 않았을 때보다 더 많은 데이터가 메모리 안에 있게 되며 그 결과 버퍼 풀 히트 비율이 증가하고 사용 가능한 메모리의 활용도가 더 높아진다. 압축을 했을 때 얻게 되는 I/O 및 메모리상의 이점은 압축할 때 사용되는 추가 적인 CPU 주기를 상쇄하고도 남을 뿐만 아니라 전체 성능을 높이는 데도 기여한다.

두 가지 테이블을 압축하기 위해 리스트 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에 표시되어 있다. 압축을 한 후에는 6,029개의 PDBML 문서에 포함되어 있는 정보를 67.4%가 더 적은 페이지(즉, 압축을 하지 않았을 때보다 세 배 더 적은 공간)에 저장할 수 있다.

페이지 크기가 32KB인 경우, 144,000 페이지의 총용량은 4.4GB가 되며 원래의 원시 데이터 양인 83GB의 5.3%에 불과하다. 현재의 PDB 아카이브의 전체 크기에 이 비율을 적용하면 PDB 정보 0.75TB를 약 40.7GB의 공간과 약간의 인덱스용 공간만을 사용하여 DB2에 저장할 수 있을 것으로 보인다.

스토리지를 이렇게 많이 절약할 수 있게 된 데는 두 가지 요인 때문이다. 첫 번째, 마크업 대 원자 정보에 있는 값의 비율이 높은 문제점을 전처리 단계에서 원자 좌표를 관련 형식으로 변환하여 해결했다. 두 번째, DB2 데이터를 압축하여 남아 있는 XML과 관계형 데이터를 3분의 1로 줄였다.

데이터베이스 파티셔닝

사용되는 공간이 많이 줄어들었음에도 불구하고 PDB 데이터 양은 계속해서 빠르게 증가한다. 또한, 데이터를 다수의 데이터 파티션에 분산하고 파티션에 지정된 데이터가 모든 파티션에서 동시에 작동하도록 함으로써 복잡한 분석적 쿼리의 응답 시간을 줄일 수 있다. 이러한 데이터 파티션은 동일한 시스템에 배치하여 멀티코어 시스템의 모든 CPU 성능을 활용하게 하거나 무공유(Shared-nothing) 구성에서는 이러한 파티션을 다수의 시스템에 분산할 수 있다. DB2 DPF(Database Partitioning Feature)는 DB2와 더불어 고급 기능과 추가적인 설계, 보고 및 데이터베이스 관리 도구가 포함되어 있는 IBM InfoSphere® Warehouse를 통해 사용 가능하다.

DPF를 사용하는 경우에는 pdb_id 열의 값으로 해싱하여 pdbxml 테이블과 atom_site 테이블에 있는 데이터를 전체 데이터베이스 파티션에 분산하는 것이 좋다. 이렇게 하려면 해당 CREATE TABLE문에 DISTRIBUTE BY HASH(pdb_id) 절을 추가한다. pdb_id 열에는 개별 값이 상당히 많기 때문에 열이 데이터베이스 파티션 전체에 비교적 고르게 분산된다. 결합 키(pdb_id)로 해싱하여 두 가지 테이블을 모두 분산하면 주어진 PDBML 문서의 모든 원자 열이 동일한 데이터베이스 파티션에 PDBML 문서 자체로 저장된다. 이렇게 공동 배치를 하면 이 두 가지 테이블 간의 결합이 언제나 각 테이터베이스 파티션 내에서 평가될 수 있을 뿐만 아니라 파티션 간에 데이터를 이동할 필요도 없다.

범위 파티셔닝

범위 파티셔닝(테이블 파티셔닝)을 이용하면 같은 값이 있는 열이 동일한 파티션에 존재할 수 있게 테이블에 있는 데이터를 지정된 열에 있는 값에 따라 파티션을 분할할 수 있다. 범위 파티셔닝의 개념은 데이터베이스 파티셔닝과 관련이 없다. 데이터베이스 파티셔닝과 범위 파티셔닝은 함께 사용하면 데이터베이스 파티션 전체에서 먼저 테이블에 있는 열이 해시된 후, 각 테이터베이스 파티션 내에서 범위가 파티셔닝된다.

범위 파티셔닝은 여러 가지 목적으로 사용될 수 있다. 첫 번째 목적은 새로 작성된 데이터와 이전 데이터의 롤인과 롤아웃을 각각 더 수월하게 하는 데 있다. 두 번째 목적은 DB2 쿼리 최적화 프로그램이 파티션의 서브세트만 조사하면 특정 쿼리에 응답할 수 있다고 판별하는 경우에 파티션 제거를 기반으로 성능을 개선하는 데 있다. PDB의 경우에는 데이터의 롤인과 롤아웃을 단순화하기 보다는 파티션 제거의 이점을 활용하기 위해 범위 파티셔닝을 배치했다.

단백질의 3차 구조는 샘플 단백질의 여러 가지 3차 구조를 생성하는 NMR이라고 하는 방법을 사용하여 실험적으로 결정할 수 있으므로 pdbx_PDB_model_num 열로 atom_site 테이블을 범위 파티셔닝하기로 결정했다. 이러한 변종을 모델이라고 하며 이러한 변종의 번호는 pdbx_PDB_model_num 필드로 지정한다. pdbx_PDB_model_num= 1 값은 단백질의 첫 번째(기본) 모델을 식별한다. 추가적인 변종은 동일한 단백질의 비기본 모델이며 pdbx_PDB_model_num >= 2의 값을 갖고 있으며 X선 회절에 의해 구조적으로 결정된 단백질에는 pdbx_PDB_model_num = 1인 모델만 있다.

리스트 6 에는 범위 파티셔닝된 atom_site 테이블의 확장된 정의가 표시되어 있다. 첫 번째 모델(pdbx_PDB_model_num = 1)에 속하는 모든 원자 좌표는 하나의 파티션에 저장되는 반면 모든 변종(pdbx_PDB_model_num >= 2)은 또 다른 파티션에 저장된다. 현재, PDB에 있는 모든 단백질의 약 16%만 NMR에 의해 생성된 변종이라고 하더라도 변종의 수가 너무 많아서 두 파티션은 레코드 수가 거의 동일하다.

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 파티션만 스캔하면 되므로 필요한 I/O가 절반으로 줄어든다.

다차원 클러스터링

범위 파티셔닝 외에도 MDC(Multi-Dimensional Clustering)를 사용하여 하나 이상의 열을 기반으로 테이블에 있는 열을 클러스터링할 수 있다. 클러스터링 열의 값이 동일한 행은 실제로 동일한 스토리지 셀에 함께 저장된다. 이렇게 하면 둘 이상의 클러스터링 차원에 따라 데이터를 억제하고 선택하는 쿼리의 성능이 대폭 개선된다. DPF와 마찬가지로 MDC도 IBM InfoSphere Warehouse를 통해 사용 가능하다.

클러스터링으로 가장 일반적이고 가장 중요한 쿼리를 지원할 수 있도록 클러스터링 열을 선택할 때는 예상되는 쿼리 워크로드를 고려해야 한다. 예를 들면, 대부분의 PDB 쿼리는 관련된 아미노산을 기반으로 원자 데이터를 검색한다. 그러므로 대부분의 문서에 있는, 3개의 문자로 구성된 아미노산 코드가 포함되어 있는 label_comp_id 열을 기반으로 atom_site 테이블을 클러스터링하는 것이 좋다. 이러한 클러스터링을 실현하려면 리스트 3에 있는 두 번째 CREATE TABLE문에 ORGANIZE BY DIMENSIONS(label_comp_id) 절을 추가한다.

또 다른 예는 atom_site 테이블을 group_PDB 열로 클러스터링하는 것이다. 검색을 하나의 group_PDB 값(즉 "HETATOM")으로 제한하는 여러 가지 샘플 쿼리를 대상으로 이 클러스터링을 평가했으며 이렇게 하면 쿼리 성능이 4배 개선된다는 사실을 확인했다.

PDB 쿼리 및 성능

이 섹션에서는 다음과 같은 내용을 증명할 두 가지 샘플 쿼리를 살펴본다.

• 훨씬 더 복잡한 PDB 데이터 분석을 쉽게 수행
• 이전 섹션에서 살펴본 데이터베이스 설계 의사결정의 이점

리스트 7에 있는 쿼리는 실험적 방법이 "X선 회절"이고 해상도(ls_d_res_high)가 2.5 미만인 모든 PDB 항목에서 PDB ID, 해상도 및 설명을 선택한다. 해상도는 옹스트롱(1Å = 0.1나노미터)으로 표현되며 원자의 구조를 분석하는 데 필요한 품질 메트릭으로 역할을 한다. 해상도가 2Å 미만인 구조는 고해상도 구조이다. (즉, 원자의 위치는 매우 정확하게 결정된다.) 해상도가 3Å을 초과하는 구조는 정확성이 떨어지며 일반적으로 무시된다.

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 절이 있는 주석 행이 세 개 포함되어 있다. 이러한 행은 디스크립터를 더 필터링하여 아직 문자화되지 않았거나 문자화될 수 없는 구조를 찾는 데 사용될 수 있다.

PDB_ID RESOLUTION  PDBX_DESCRIPTOR 
------ ----------- -------------------------------------------------
2VB1       0.65000 LYSOZYME C (E.C.3.2.1.17)
2B97       0.75000 Hydrophobin II
2OV0       0.75000 PROTEIN
2I16       0.81000 Aldose reductase (E.C.1.1.1.21)
2I17       0.81000 Aldose reductase (E.C.1.1.1.21)
2HS1       0.84000 HIV-1 Protease V32I mutant (EC 3.4.23.16)
2F01       0.85000 Streptavidin               
2OL9       0.85000 SNQNNF peptide from human prion residues 170-175
2PF8       0.85000 Aldose reductase (E.C.1.1.1.21)
2P74       0.88000 Beta-lactamase CTX-M-9a (E.C.3.5.2.6)

  10 record(s) selected.

리스트 7에 있는 쿼리의 조건부는 그다지 선택적이지 않으므로 pdbxml 테이블의 전체 테이블 스캔이 필요하다. 표 2 에는 두 가지 설계 의사결정(원자 사이트 분리 및 압축)이 이 테이블 스캔 쿼리의 성능에 어떠한 이점을 제공하는지가 표시되어 있다. 이 기사와 같은 환경에서는 이 테이블 스캔은 I/O에 의해 제한되었다. DB2 데이터를 압축하여 I/O의 병목 현상을 완화했으며 쿼리 경과 시간을 40%(244초에서 128초로) 줄였다. 원자 사이트 데이터를 별도의 관계형 테이블에 추출하여 pdbxml 테이블의 크기를 대폭 줄였으며 그 결과 쿼리 성능이 거의 4.5배(138초에서 31초로) 개선되었다.

리스트 9 에는 다양한 화합물에서 다양한 원자나 이온이 얼마나 자주 발생하는지를 판별하는 또 다른 샘플 쿼리가 표시되어 있다. WHERE 절은 검색을 헤테로 원자로 제한하고 각 단백질의 첫 번째 모델만 고려한다.

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에 표시되어 있다. 가장 자주 발견되는 화합물은 산소 원자(O)가 포함되어 있는 물(HOH)이다. 수소를 발견하려면 해상도가 매우 높아야 하고 이러한 해상도는 언제나 확보할 수 있는 것이 아니기 때문에 보고된 수소(HOH의 경우 H1과 H2로 표시됨)의 수는 적다.

(인간)헤모글로빈은 다수의 분자로 구성되는 단백질이고 이러한 분자는 비단백질 화합물인 헤메와 상호 작용할 수 있다. 헤메(HEM)는 그 중심에 철(FE) 이온을 배치할 수 있는 비단백질성 유기 구조인 멀티 원자이다. 이 철 이온은 산소를 바인딩하는 데 중요한 이온이기도 하다. 리스트 10에 있는 결과에서 철 이온이 헤메 화합물에서 자주 발견된다는 사실을 확인할 수 있다. 이것은 간단한 예제이지만, 이 예제를 통해 PDB 데이터에서 의미 있는 상관성을 발견하고, 단백질이 분자 레벨에서 어떻게 기능하고 상호 작용하는지 쉽게 이해할 수 있다.

Atom     Compound        Occurrences
-------- --------------  -------------------------
O        HOH             1571965
MG       MG              7159
...
H1       HOH             1858
H2       HOH             1858
ZN       ZN              1664
...
CL       CL              1318
CA       CA              1295
...
FE      HEM           379
NA       HEM             379

표 3 에는 원자 사이트 분리, 압축, 범위 파티셔닝 및 다차원 클러스터링에 적합한 데이터베이스 설계를 선택하는 것이 쿼리에 특정된 인덱스가 존재하지 않는 경우에도 우수한 성능을 제공한다는 사실이 표시되어 있다.

위로

요약

이 기사에서는 DB2의 pureXML과 관계형 데이터 관리 기능을 사용하여 PDB를 효과적으로 저장하고 쿼리하는 방법을 설명했다. 단백질 데이터의 본질적인 특성을 기반으로 하이브리드 데이터베이스 스키마를 설계하고 최적화했다. 성능을 높이고 사용 공간을 최소화하려면 데이터베이스 파티셔닝, 범위 파티셔닝, 압축 및 다차원 클러스터링을 사용하는 것이 좋다. 이외에도 XML 인덱스와 관계형 인덱스를 조합하면 쿼리의 성능을 더 개선할 수 있다. DB2를 기반으로 하는 PDB는 전체 PDB를 검색하여 특정 단백질의 상호 작용을 파악하고 특별한 상호 작용을 구조적 레벨에서 설명하는 데 도움을 주기 위해 계속해서 사용되고 있다.

감사의 인사

DB2를 기반으로 하는 PDB의 개발은 독일에 있는 Technical University Dresden 생물공학센터의 Maria Teresa Pisabarro의 구조적 생물정보학 연구 그룹에서 수행되었다. 이 프로젝트의 재원은 SAP 공동 설립자인 Klaus Tschira의 기금에서 지원하는 장학금이다. 또한, 이 기사에 기술되어 있는 작업에 도움을 준 Henrik Loeser와, 프로덕션 서버를 제공해 준 Max Delbrück Center(MDC) for Molecular Medicine(독일 베를린 부흐)의 Berlin Institute of Medical Systems Biology(BIMSB)에 감사 드린다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

교육

• PDB와 XML 형식 PDBML에 관한 자세한 정보는 PDB.org을 참조한다.
  
  
• XML 형식 PDBML에 관해 자세히 배우자.
  
  
• PDB 데이터에 대한 소개 자료를 확인하려면 "Understanding PDB Data: Looking at Structures"를 읽어보자.
  
  
• 목록 1과 목록 2에 표시되어 있는 발췌 내용의 완전한 XML 문서를 얻자.
  
  
• DB2 pureXML Cookbook에서 DB2 pureXML의 포괄적인 지식을 얻자.
  
  
• "Enhance business insight and scalability of XML data with new DB2 9.7 pureXML features" 기사에서 XML 데이터의 압축, 파티셔닝 및 클러스터링에 관해 자세히 읽어보자.
  
  
• 더 많은 DB2 pureXML 참고자료를 확인하려면 DB2 pureXML enablement wiki를 탐색한다.
  
  
• 최신 뉴스와 XML 팁 및 트릭과 관련된 최신 정보를 얻으려면 Native XML Database 블로그를 읽어본다.
  
  
• IBM Academic Initiative에 관해 배우자.
  
  
• developerWorks Information Management 영역에서는 Information Management에 대한 정보를 제공한다. 기술 자료, 사용법 기사, 교육, 다운로드, 제품 정보 등을 찾아볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  
• Twitter의 developerWorks 페이지를 살펴보자.
  
  

제품 및 기술

• DB2 Express-C를 무료로 다운로드하자.
  
  
• developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 개발 프로젝트를 구현해 보자.
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Gerd Anders는 베를린 Humboldt University에서 전산학 학위를 취득했다. 그는 유전자정보처리와, 데이터베이스 시스템을 사용하여 생명과학 분야의 대용량 데이터를 효과적으로 관리하고 처리하는 작업을 전문으로 한다. DB2 기반 PDB는 그의 필수 박사학위 프로젝트로, 논제는 여러 가지 DB2 중심 애플리케이션에 소중한 기반을 제공하고 PDB의 전반적인 가능성을 활용하는 것이다. 이외에도 그는 Linux, UNIX 및 Windows용 DB2 9.5 의 Closed-Beta Version의 테스터이기도 하다.

Matthias Nicola는 캘리포니아 주 산호세에 있는 IBM Silicon Valley Lab의 수석 소프트웨어 엔지니어이다. 그는 DB2의 성능 및 벤치마킹, XML, 시간 데이터 관리,인 데이터베이스 분석 및 기타 신기술에 집중하고 있다. 그는 고객 및 비즈니스 파트너가 DB2 솔루션을 설계하고 최적화 및 구현하는 데 도움을 주기 위해 이들과 밀접하게 작업을 한다. 이전에는 Informix Software에서 데이터 웨어하우스의 성능과 관련된 작업을 수행했다. 그는 독일에 있는 Technical University of Aachen에서 전산학 박사학위를 취득했다.

아티클 순위

의견

위로

목차

• 소개
• 문제점
• PDB의 컨텐츠
• 테스트 데이터베이스
• PDB를 위한 데이터베이스 설계 권장사항
• 요약
• 감사의 인사
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견