Trình tự sinh học của UniProt trong PostgreSQL


11

Cách tốt nhất để lưu trữ các chuỗi sinh học UniProt trong PostreSQL là gì?

Chi tiết dữ liệu

  • Chúng tôi thu hút 12 triệu chuỗi từ UniProt - con số này có thể sẽ tăng gấp đôi sau mỗi 3-10 tháng.
  • Độ dài của chuỗi có thể thay đổi từ 10 đến 50 tỷ ký tự
  • Ít hơn 1% các chuỗi dài hơn 10 nghìn ký tự
    • Nó sẽ cải thiện hiệu suất để lưu trữ các chuỗi dài hơn một cách riêng biệt?
  • Một chuỗi có thể là bảng chữ cái Protein hoặc DNA
    • Bảng chữ cái DNA có 5 ký tự (A, T, C, G hoặc -).
    • Bảng chữ cái Protein sẽ có khoảng 30 ký tự.
    • Chúng tôi không ngại lưu trữ các chuỗi của hai bảng chữ cái khác nhau trong các cột khác nhau hoặc thậm chí các bảng khác nhau. Điều đó có giúp được không?

Chi tiết truy cập dữ liệu

Để trả lời bình luận của Jeremiah Peschka:

  • Trình tự protein và DNA sẽ được truy cập tại các thời điểm khác nhau
  • Không cần tìm kiếm trong chuỗi (điều đó được thực hiện bên ngoài db)
  • Ether sẽ truy cập các hàng đơn lẻ tại một thời điểm hoặc kéo ra các bộ hàng bằng ID. Chúng tôi không cần phải quét hàng. Tất cả các chuỗi được tham chiếu bởi các bảng khác - một số phân cấp có ý nghĩa về mặt sinh học và thời gian tồn tại trong cơ sở dữ liệu.

Khả năng tương thích ngược

Thật tuyệt khi có thể tiếp tục áp dụng chức năng băm sau (SEGUID - SEquence Globally Unique IDentifier) ​​cho các chuỗi.

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;

Những loại mẫu truy cập dữ liệu bạn sẽ có? Dữ liệu DNA và protein sẽ được truy cập cùng một lúc cho một chuỗi? Bạn sẽ cần tìm kiếm trong chuỗi? Truy cập dữ liệu phần lớn sẽ dành cho các hàng đơn lẻ tại một thời điểm hay bạn sẽ thực hiện quét dữ liệu? Theo nhiều cách, cách bạn đang truy cập dữ liệu quan trọng hơn nhiều so với chính dữ liệu đó.
Jeremiah Peschka

1
Không ngăn cản bạn tư vấn cho cộng đồng non trẻ này, nhưng đối với câu hỏi tin sinh học, biostar.stackexchange.com có thể có câu trả lời mà bạn đang tìm kiếm. Mong rằng sẽ giúp!
Gaurav

+1 cho Biostar nhưng tôi đang thực hiện nhiệm vụ này một cách nghiêm ngặt DB.
Alexanderr Levchuk

@jcolebrand, cái này liên quan đến Blast. Chúng tôi có một hàm xuất ghi các chuỗi thành định dạng FASTA và đó là một đầu vào hợp lệ cho Blast. Sau đó, Blast có thể thực hiện các tìm kiếm tương tự thông lượng cao đối với các chuỗi hoặc đối với cơ sở dữ liệu lớn hơn (nhưng chỉ Uniprot có thể lớn hơn Uniport). Chúng tôi cũng xây dựng HMM từ các bộ trình tự và sử dụng HMMER2 để tìm kiếm sự tương tự.
Alexanderr Levchuk

Câu trả lời:


7

Khám phá các chức năng tại PostBio, có vẻ như họ có một vài cách mã hóa. Tuy nhiên, do các tiện ích mở rộng đó được tối ưu hóa để tìm kiếm, chúng tạo ra nhiều tham chiếu để chỉ sử dụng textkiểu dữ liệu.

Theo tài liệu :

Các chuỗi dài được hệ thống nén tự động, do đó yêu cầu vật lý trên đĩa có thể ít hơn. Các giá trị rất dài cũng được lưu trữ trong các bảng nền để chúng không cản trở việc truy cập nhanh vào các giá trị cột ngắn hơn. Trong mọi trường hợp, chuỗi ký tự dài nhất có thể được lưu trữ là khoảng 1 GB.

Do đó, bằng cách đặt bảng vào không gian bảng rất lớn trên phần cứng chuyên dụng sẽ đủ cho mục tiêu hiệu suất của bạn. Nếu 1 GB quá nhỏ so với dữ liệu của bạn, int_interval từ ProtBio sẽ cung cấp hiệu suất tuyệt vời:

Một tính năng chuỗi tương ứng với một bộ ba (id, direction, ii) trong đó id là một mã định danh trình tự (có thể là khóa chính cho bảng tuần tự), direction là một boolean cho biết nếu tính năng này nằm trong cùng hướng hoặc ngược hướng của chuỗi, và ii là int_interval đại diện cho tính năng này như là một chuỗi con.

Mã hóa chuỗi trong sha1 có vẻ là một cách rất khó để tạo GUID, xem xét độ dài tiềm năng của chuỗi.

Nếu các chuỗi khác nhau không liên quan, lưu trữ chúng trên các không gian bảng khác nhau trên các đĩa khác nhau để có hiệu suất tối đa.


1

Tôi nghĩ 50 tỷ ký tự có thể sẽ đẩy các giới hạn của những gì bạn có thể làm với PostgreSQL mà không phải chia nhỏ hồ sơ của bạn theo một cách nào đó. Tôi nghi ngờ bạn sẽ phải tìm cách phá vỡ mọi thứ theo một cách nào đó. Tôi không biết loại postbio mã hóa nào cho phép nhưng ....

Tính toán nhanh ở đây: 5 ký tự yêu cầu mã hóa 3 bit, nhưng 4 bit sẽ giúp tìm kiếm dễ dàng hơn vì hai ký tự có thể được mã hóa trên mỗi byte. Mặt khác, 3 có thể là đủ nếu bạn đang tìm kiếm các nhóm từ 10 chữ cái trở lên vì bạn có thể thực hiện 10 ký tự trên 4 byte. Vì vậy, được tối ưu hóa cho các tìm kiếm chuỗi ngắn, 50 tỷ ký tự chiếm khoảng 25gb dung lượng, vượt xa những gì bạn có thể làm trong một cột. Nén có thể giúp ích, nhưng đó là một quy mô nén khổng lồ cần thiết ngoài biểu diễn nhị phân không nén tối thiểuđể có được xuống 1GB. Tối ưu hóa cho các tìm kiếm dài hơn, chúng tôi chỉ nhận được 20 GB. Vì vậy, tôi nghĩ ngay cả khi bạn có các loại thông tin di truyền, bạn sẽ phá vỡ mọi thứ. Protein ở mức độ phức tạp đó sẽ còn là một thách thức nữa vì điều tốt nhất bạn có thể hy vọng là ký hiệu 5 bit, có nghĩa là bạn có 6 trên 32, nghĩa là trường hợp lưu trữ tốt nhất của bạn là 30 GB cho mỗi cột. Vì vậy, trừ khi bạn có thể nhận được Nén có thể giúp một lần nữa nhưng đó là tốc độ nén lớn cần thiết. Tôi đã thấy tốc độ nén tốt, nhưng hãy nhớ rằng bạn có thể đang đẩy nó.

Vì vậy, khuyến nghị của tôi là nhận thức được vấn đề này và thực hiện một số thử nghiệm với dữ liệu thực. Được parepared để phân tách bài đọc của bạn trong một số trường hợp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.