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;
postgresql
Aleksandr Levchuk
źródło
źródło
Odpowiedzi:
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ą :
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ść:
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ść.
źródło
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.
źródło