Sekwencje biologiczne UniProt w PostgreSQL

Jaki jest najlepszy sposób przechowywania sekwencji biologicznych UniProt w PostreSQL?

Szczegóły danych

• Pobieramy 12 milionów sekwencji z UniProt - liczba ta może się podwoić co 3-10 miesięcy.
• Długość sekwencji może wynosić od 10 do 50 miliardów znaków
• Mniej niż 1% sekwencji ma więcej niż 10 tysięcy znaków
  • Czy poprawiłoby się wydajność oddzielnego przechowywania dłuższych sekwencji?
• Sekwencja może być alfabetem białkowym lub DNA
  • Alfabet DNA ma 5 znaków (A, T, C, G lub -).
  • Alfabet białkowy będzie miał około 30 znaków.
  • Nie mamy nic przeciwko przechowywaniu sekwencji dwóch różnych alfabetów w różnych kolumnach lub nawet w różnych tabelach. Czy to pomogłoby?

Szczegóły dostępu do danych

Aby odpowiedzieć na komentarz Jeremiasza Peschki:

• Sekwencje białek i DNA będą dostępne w różnych momentach
• Nie musiałbym wyszukiwać w sekwencji (odbywa się to poza db)
• Czy eter uzyskiwałby dostęp do pojedynczych wierszy na raz lub wyciągałby zestawy wierszy według identyfikatorów. Nie musielibyśmy skanować wierszy. Wszystkie sekwencje są przywoływane przez inne tabele - w bazie danych istnieje kilka hierarchicznie znaczących biologicznie i chronologicznie hierarchii.

Kompatybilność wsteczna

Byłoby miło móc nadal stosować następującą funkcję haszującą (SEGUID - Sekwencja Globalnie Unikalny Identyfikator) do sekwencji.

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;

Odkrywanie funkcji w PostBio wygląda na to, że mają kilka sposobów kodowania. Jednak biorąc pod uwagę, że rozszerzenia te są zoptymalizowane do wyszukiwania, zawierają wiele odniesień do zwykłego używania texttypu danych.

Zgodnie z dokumentacją :

Długie łańcuchy są automatycznie kompresowane przez system, więc wymagania fizyczne na dysku mogą być mniejsze. Bardzo długie wartości są również przechowywane w tabelach w tle, aby nie zakłócały szybkiego dostępu do krótszych wartości kolumn. W każdym razie najdłuższy możliwy ciąg znaków, który można zapisać, to około 1 GB.

Dlatego umieszczenie tabeli w jej własnym, bardzo dużym obszarze tabel na dedykowanym sprzęcie powinno wystarczyć do osiągnięcia celów wydajnościowych. Jeśli 1 GB jest za małe dla danych, inter_interval z ProtBio powinien zapewnić doskonałą wydajność:

Funkcja sekwencji odpowiada tripletowi (id, orient, ii), gdzie id jest identyfikatorem sekwencji (być może kluczem podstawowym tabeli sekwencji), orient jest wartością logiczną wskazującą, czy cecha jest w tej samej lub przeciwnej orientacji sekwencji, a ii to inter_interval reprezentujący funkcję jako podsekwencję.

Kodowanie sekwencji w sha1 wydaje się być bardzo bolesnym sposobem tworzenia identyfikatora GUID, biorąc pod uwagę potencjalną długość sekwencji.

Jeśli różne sekwencje nie są ze sobą powiązane, przechowuj je w różnych obszarach tabel na różnych dyskach, aby uzyskać maksymalną wydajność.

Myślę, że 50 miliardów znaków prawdopodobnie przekroczy granice tego, co możesz zrobić dzięki PostgreSQL bez dzielenia twoich rekordów. Podejrzewam, że będziesz musiał znaleźć jakiś sposób, aby jakoś to rozdzielić. Nie wiem na co pozwala kodowanie postbio, ale ....

Szybkie obliczenia tutaj: 5 znaków wymaga 3 bitów do zakodowania, ale 4 bity ułatwią wyszukiwanie, ponieważ dwa znaki można zakodować na bajt. Z drugiej strony 3 może wystarczyć, jeśli szukasz grup 10 lub więcej liter, ponieważ możesz zrobić 10 znaków na 4 bajty. Tak zoptymalizowany do wyszukiwania krótkich ciągów, 50 miliardów znaków zajmuje około 25 GB pamięci, znacznie wykraczając poza to, co można zrobić w pojedynczej kolumnie. Kompresja może pomóc, ale jest to ogromna skala kompresji wymagana poza minimalną nieskompresowaną reprezentację binarnąaby zejść do 1 GB. Zoptymalizowany pod kątem dłuższych wyszukiwań, otrzymujemy tylko 20 GB. więc myślę, że nawet gdybyś miał typ informacji genetycznej, rozpadłbyś się. Białka o tej złożoności będą jeszcze większym wyzwaniem, ponieważ najlepszym, na co możesz liczyć, jest 5-bitowa notacja, co oznacza, że ​​masz 6 na 32, co oznacza, że ​​najlepszym miejscem na przechowywanie jest 30 GB na kolumnę. Więc jeśli nie możesz uzyskać kompresji, może to pomóc, ale wymaga to dużego stopnia kompresji. Widziałem dobre wskaźniki kompresji, ale pamiętaj, że możesz to popychać.

Więc moja rekomendacja jest świadoma tego problemu i przeprowadzam testy z prawdziwymi danymi. Bądź ostrożny, aby w niektórych przypadkach rozłożyć swoje odczyty.