PostgreSQL에서 UniProt의 생물학적 순서


11

PostreSQL에 UniProt 생물학적 서열을 저장하는 가장 좋은 방법은 무엇입니까?

데이터 세부 사항

  • UniProt 에서 1200 만 개의 시퀀스를 가져옵니다. 이 숫자는 3-10 개월마다 두 배가 될 것입니다.
  • 시퀀스의 길이는 100 ~ 500 억 자로 다양
  • 시퀀스의 1 % 미만이 1 만자를 초과합니다.
    • 더 긴 시퀀스를 별도로 저장하는 성능이 향상됩니까?
  • 서열은 단백질 또는 DNA 알파벳 일 수있다
    • DNA 알파벳에는 5 자 (A, T, C, G 또는-)가 있습니다.
    • 단백질 알파벳은 약 30 자입니다.
    • 우리는 두 개의 다른 알파벳 순서를 다른 열이나 다른 테이블에 저장하는 것을 신경 쓰지 않습니다. 도움이 되겠습니까?

데이터 액세스 세부 사항

예레미야 페 쉬카의 의견에 대답하려면 :

  • 단백질과 DNA 서열은 다른 시간에 접근
  • 시퀀스 내에서 검색 할 필요가 없습니다 (db 외부에서 수행됨)
  • ether가 한 번에 하나의 행에 액세스하거나 ID로 행 세트를 가져옵니다. 행을 스캔 할 필요는 없습니다. 모든 서열은 다른 표에 의해 참조된다-생물학적으로 그리고 시간적으로 의미있는 여러 계층이 데이터베이스에 존재한다.

이전 버전과의 호환성

시퀀스에 다음 해싱 함수 (SEGUID-SEquence Globally Unique IDentifier)를 계속 적용 할 수 있으면 좋을 것 입니다.

CREATE OR REPLACE FUNCTION gfam.get_seguid(p_sequence character varying)
  RETURNS character varying AS
$BODY$
declare
  result varchar := null;
  x integer;
begin

  select encode(gfam.digest(p_sequence, 'sha1'), 'base64')
  into   result;

  x := length(result);
  if substring(result from x for 1) = '=' then

     result := substring( result from 1 for x-1 );

  end if;

  return result;

end;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;

어떤 종류의 데이터 액세스 패턴이 있습니까? DNA와 단백질 데이터가 동시에 서열에 접근됩니까? 시퀀스 내에서 검색해야합니까? 데이터 액세스는 한 번에 한 행씩 수행됩니까? 아니면 데이터 스캔을 수행합니까? 데이터에 액세스하는 방식은 여러 가지면에서 데이터 자체보다 훨씬 중요합니다.
예레미아 페 쉬카

1
이 신생 커뮤니티에 문의하지 말고 생물 ​​정보학 질문에 대해서는 biostar.stackexchange.com 에서 원하는 답변을 얻을 수 있습니다. 희망이 도움이됩니다!
Gaurav

Biostar의 경우 +1이지만이 퀘스트는 엄격히 DB로 유지합니다.
Aleksandr Levchuk

@jcolebrand, 이것은 Blast와 관련이 있습니다. 시퀀스를 FASTA 형식으로 작성하고 Blast에 유효한 입력 인 내보내기 기능이 있습니다. 그런 다음 Blast는 시퀀스 또는 더 큰 데이터베이스에 대해 높은 처리량 유사성 검색을 수행 할 수 있습니다 (그러나 Uniprot만이 Uniport보다 클 수 있음). 또한 시퀀스 세트에서 HMM을 구성하고 HMMER2를 사용하여 유사성을 검색합니다.
Aleksandr Levchuk 18

답변:


7

PostBio 의 기능을 살펴보면 몇 가지 인코딩 방법이있는 것 같습니다. 그러나 이러한 확장은 검색에 최적화되어 있으므로 단순히 text데이터 형식을 사용하는 것에 대한 여러 참조를 만듭니다 .

설명서 에 따르면 :

긴 문자열은 시스템에 의해 자동으로 압축되므로 디스크의 물리적 요구 사항이 더 적을 수 있습니다. 매우 긴 값은 백그라운드 테이블에 저장되므로 더 짧은 열 값에 빠르게 액세스하는 데 방해가되지 않습니다. 어쨌든 저장할 수있는 가장 긴 문자열은 약 1GB입니다.

따라서 테이블을 전용 하드웨어 의 매우 큰 테이블 공간에 배치하면 성능 목표에 충분해야합니다. 1GB가 데이터에 비해 너무 작은 경우 ProtBio의 int_interval은 우수한 성능을 제공해야합니다.

시퀀스 피처는 3 중항 (id, orient, ii)에 해당합니다. 여기서 id는 시퀀스 식별자 (시퀀스 테이블의 기본 키일 수 있음), orient는 피처가 시퀀스의 동일 또는 반대 방향인지를 나타내는 부울입니다. ii는 특징을 서브 시퀀스로 나타내는 int_interval이다.

sha1에서 시퀀스를 인코딩하는 것은 시퀀스의 잠재적 길이를 고려하여 GUID를 만드는 매우 고통스러운 방법으로 보입니다.

다른 순서가 서로 관련이없는 경우, 성능을 최대화하기 위해 다른 디스크의 다른 테이블 스페이스 에 저장하십시오 .


1

필자는 500 억 개의 문자가 어떤 식 으로든 레코드를 분할하지 않고 PostgreSQL로 할 수있는 작업의 한계를 뛰어 넘을 것으로 생각합니다. 나는 당신이 어떤 식 으로든 물건을 깰 수있는 방법을 찾아야한다고 생각합니다. postbio가 어떤 종류의 인코딩을 허용하는지 모르겠지만 ....

여기서 빠른 계산 : 5 개의 문자는 인코딩을 위해 3 비트를 필요로하지만 4 비트는 바이트 당 2 개의 문자를 인코딩 할 수 있으므로 검색이 쉬워집니다. 반면에 4 바이트 당 10자를 수행 할 수 있으므로 10 개 이상의 문자 그룹을 검색하는 경우 3이면 충분할 수 있습니다. 짧은 문자열 검색에 최적화 된 500 억 문자는 단일 열에서 수행 할 수있는 것보다 약 25GB의 저장 공간을 차지합니다. 압축이 도움이 될 수 있지만 최소한의 압축되지 않은 이진 표현을 넘어서는 엄청난 압축 규모입니다.1GB로 떨어지기 위해. 더 긴 검색에 최적화되어 있으며 20GB 만 제공합니다. 유전자 정보 유형이 있어도 문제가 생겼을 것입니다. 그 복잡성에있는 단백질은 5 비트 표기법이므로 32 개당 6 개를 의미하기 때문에 가장 어려운 문제가 될 수 있습니다. 이는 스토리지에 가장 적합한 경우는 열당 30GB입니다. 따라서 압축을 다시 얻을 수 없다면 압축이 다시 도움이 될 수 있지만 큰 압축률이 필요합니다. 나는 좋은 압축률을 보았지만 당신이 그것을 압축하고 있다는 것을 명심하십시오.

따라서 내 권장 사항은이 문제를 알고 실제 데이터로 테스트하는 것입니다. 경우에 따라 판독 값을 분해하기 위해 파서해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.