PostgreSQL'de UniProt'un Biyolojik Dizileri


11

UniProt biyolojik dizilerini PostreSQL'de depolamanın en iyi yolu nedir?

Veri Detayları

  • UniProt'tan 12 milyon dizi çekiyoruz - bu sayı her 3-10 ayda bir ikiye katlanıyor .
  • Bir dizinin uzunluğu 10 ila 50 milyar karakter arasında değişebilir
  • Dizilerin% 1'inden azı 10 bin karakterden uzun
    • Uzun dizileri ayrı ayrı saklamak performansı artırabilir mi?
  • Bir dizi, Protein veya DNA alfabesinden olabilir
    • DNA alfabesinin 5 karakteri vardır (A, T, C, G veya -).
    • Protein alfabesinde yaklaşık 30 karakter olacaktır.
    • İki farklı alfabenin dizilerini farklı sütunlarda ve hatta farklı tablolarda saklamak önemli değildir. Bu yardımcı olur mu?

Veri Erişim Ayrıntıları

Jeremiah Peschka'nın yorumuna cevap vermek için:

  • Protein ve DNA dizilerine farklı zamanlarda erişilecekti
  • Dizi içinde arama yapmanıza gerek yoktur (db dışında yapılır)
  • Eter her seferinde tek sıralara erişir veya kimlik gruplarına göre satır kümelerini çıkarır. Satırları taramamız gerekmeyecekti. Tüm sekanslara diğer tablolar tarafından atıfta bulunulur - veritabanında biyolojik ve kronolojik olarak anlamlı birkaç hiyerarşi bulunur.

Geriye Dönük Uyumluluk

Dizilere aşağıdaki karma işlevini (SEGUID - SEquence Globally Unique IDentifier) uygulayabilmeye devam etmek güzel olurdu .

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;

Ne tür veri erişim modellerine sahip olacaksınız? Bir sekans için DNA ve protein verilerine aynı anda erişilecek mi? Dizi içinde arama yapmanız gerekecek mi? Veri erişimi büyük ölçüde tek bir satır için mi olacak yoksa verilerin taranmasını mı yapacaksınız? Verilere erişme şekliniz birçok açıdan verilerin kendisinden çok daha önemlidir.
Jeremiah Peschka

1
Sizi bu yeni doğan topluluğa danışmaktan caydırmak değil, biyoenformatik sorusu için biostar.stackexchange.com aradığınız cevaba sahip olabilir. Umarım yardımcı olur!
Gaurav

Biostar için +1 ama bu görevi kesinlikle DB tutuyorum.
Aleksandr Levchuk

@jcolebrand, bu Blast ile ilgilidir. Dizileri FASTA formatına yazan ve Blast için geçerli bir girdi olan bir dışa aktarma fonksiyonumuz var. Daha sonra Blast, sekanslara veya daha büyük bir veritabanına karşı yüksek verimli benzerlik aramaları yapabilir (ancak Uniport'tan yalnızca Uniprot daha büyük olabilir). Ayrıca sekans setlerinden HMM oluşturuyoruz ve benzerlik aramak için HMMER2'yi kullanıyoruz.
Aleksandr Levchuk

Yanıtlar:


7

PostBio'daki fonksiyonları keşfetmek, kodlamanın birkaç yolu var gibi görünüyor. Ancak, bu uzantıların arama için optimize edildiği göz önüne alındığında, yalnızca textveri türünü kullanmak için birden çok referans yaparlar .

Belgelere göre :

Uzun dizeler sistem tarafından otomatik olarak sıkıştırılır, bu nedenle diskteki fiziksel gereksinim daha az olabilir. Çok uzun değerler de arka plan tablolarında saklanır, böylece daha kısa sütun değerlerine hızlı erişimi engellemezler. Her durumda, saklanabilecek mümkün olan en uzun karakter dizisi yaklaşık 1 GB'dir.

Bu nedenle, kendi içine tablo koyarak çok büyük adanmış donanım üzerinde tablo performans hedeflerinize için yeterli olacaktır. 1 GB verileriniz için çok küçükse, ProtBio'dan int_interval mükemmel performans sağlamalıdır:

Bir sekans özelliği, id'nin bir sekans tanımlayıcısı (muhtemelen bir sekans tablosu için birincil anahtar) olduğu bir üçlüye (id, orient, ii) karşılık gelir; orient, unsurun sekansla aynı veya ters yönde olup olmadığını gösteren bir boolean, ve ii, özelliği bir ardışık olarak temsil eden int_interval'dir.

Sekansı shal'de kodlamak, sekansın potansiyel uzunluklarını göz önünde bulundurarak bir GUID yapmanın çok acı verici bir yolu gibi görünmektedir.

Farklı sekanslar ilgisizse , maksimum performans için farklı disklerdeki farklı tablo alanlarında saklayın .


1

Bence 50 milyar karakter PostgreSQL ile yapabileceğiniz şeylerin sınırlarını zorlamayacak. Bazı şeyleri bir şekilde ayırmak için bir yol bulmanız gerekeceğinden şüpheleniyorum. Postbio'nun ne tür bir kodlamaya izin verdiğini bilmiyorum ama ....

Burada hızlı hesaplamalar: 5 karakter kodlamak için 3 bit gerektirir, ancak 4 bit bayt başına iki karakter kodlanabildiğinden aramayı kolaylaştırır. Öte yandan, 4 veya daha fazla harften oluşan gruplar arıyorsanız, 4 bayt başına 10 karakter yapabileceğiniz için 3 yeterli olabilir. Kısa dizeli aramalar için optimize edilen 50 milyar karakter, tek bir sütunda yapabileceğinizin çok ötesinde yaklaşık 25 gb depolama alanı alır. Sıkıştırma yardımcı olabilir, ancak bu, sıkıştırılmamış minimum ikili gösterimin ötesinde gerekli olan büyük bir sıkıştırma ölçeğidir.1GB'a kadar inmek için. Daha uzun aramalar için optimize edildiğinde, yalnızca 20 GB alırız. bu yüzden genetik bilgi türleriniz olsa bile bazı şeyleri parçalara ayıracağınızı düşünüyorum. Bu karmaşıklıktaki proteinler daha da zor olacak çünkü umut edebileceğiniz en iyi şey 5 bitlik gösterimdir, yani 32'de 6'ya sahipsiniz, yani depolama için en iyi durum sütun başına 30 GB'dir. Sıkıştırma alamadığınız sürece tekrar yardımcı olabilir, ancak bu büyük bir sıkıştırma oranı gerektirir. İyi sıkıştırma oranları gördüm, ancak bunu itmekte olabileceğinizi unutmayın.

Bu yüzden tavsiyem bu sorunun farkında olmak ve gerçek verilerle bazı testler yapmak. Bazı durumlarda okumalarınızı ayrıştırmak için parepared olun.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.