Биологические последовательности UniProt в PostgreSQL

Каков наилучший способ хранения биологических последовательностей UniProt в PostreSQL?

Сведения о данных

  • Мы вытягиваем 12 миллионов последовательностей из UniProt - это число, вероятно, удвоится каждые 3-10 месяца .
  • Длина последовательности может варьироваться от 10 до 50 миллиардов символов.
  • Менее 1% последовательностей длиннее 10 тысяч символов
    • Будет ли улучшена производительность для хранения более длинных последовательностей отдельно?
  • Последовательность может быть либо белкового, либо ДНК-алфавита
    • Алфавит ДНК имеет 5 символов (A, T, C, G или -).
    • Алфавит для белков будет содержать около 30 символов.
    • Мы не против хранить последовательности двух разных алфавитов в разных столбцах или даже разных таблицах. Это поможет?

Сведения о доступе к данным

Чтобы ответить на комментарий Иеремии Песчки:

  • Доступ к белкам и последовательностям ДНК можно получить в разное время.
  • Не нужно искать в последовательности (это делается за пределами db)
  • Будет ли простой доступ к элементу доступа к отдельным строкам или вытаскиванию наборов строк по идентификаторам. Нам не нужно было сканировать строки. Все последовательности ссылаются на другие таблицы - в базе данных существует несколько биологически и хронологически значимых иерархий.

Обратная совместимость

Было бы неплохо иметь возможность использовать следующую функцию хеширования (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;
11 голосов | спросил Aleksandr Levchuk 4 Jam1000000amTue, 04 Jan 2011 02:31:44 +030011 2011, 02:31:44

2 ответа


7

Изучая функции в PostBio , похоже, что у них есть несколько способов кодирования. Однако, учитывая, что эти расширения оптимизированы для поиска, они делают несколько ссылок на простое использование типа данных text.

В соответствии с документацией :

  

Длинные строки автоматически сжимаются системой, поэтому физическое требование на диске может быть меньше. Очень длинные значения также хранятся в фоновых таблицах, чтобы они не мешали быстрому доступу к более коротким значениям столбцов. В любом случае, самая длинная строка символов, которая может быть сохранена, составляет около 1 ГБ.

Поэтому, поставив таблицу в собственное очень большое табличное пространство на выделенном оборудовании, должно быть достаточно для ваших целей производительности. Если 1 GB слишком мал для ваших данных, int_interval из ProtBio должен обеспечивать отличную производительность:

  

Функция последовательности соответствует триплету (id, orient, ii), где id - идентификатор последовательности (возможно, первичный ключ для таблицы последовательности), ориентация - это логическое значение, указывающее, является ли эта функция той же или противоположной ориентацией последовательность и ii - int_interval, представляющий функцию как подпоследовательность.

Кодирование последовательности в sha1 выглядит очень болезненным способом создания GUID с учетом возможных длин последовательности.

Если разные последовательности не связаны друг с другом, сохраните их на разных табличных пространствах на разных дисках для максимальной производительности.

ответил Brian Ballsun-Stanton 7 Jam1000000amFri, 07 Jan 2011 04:32:11 +030011 2011, 04:32:11
1

Я думаю, что 50 миллиардов символов, скорее всего, вытеснят пределы того, что вы можете делать с PostgreSQL, не разбирая ваши записи каким-то образом. Я подозреваю, что вам придется найти способ каким-то образом разбить вещи. Я не знаю, что такое кодировка postbio, но ....

Быстрые вычисления здесь: 5 символов требуют 3 бита для кодирования, но 4 бита облегчат поиск, поскольку два символа могут быть закодированы за один байт. С другой стороны, 3 может быть достаточно, если вы ищете группы из 10 или более букв, так как вы можете сделать 10 символов на 4 байта. Таким образом, оптимизированный для поиска коротких строк, 50 миллиардов символов занимают около 25 гб памяти, что намного превышает то, что вы можете сделать в одном столбце. Сжатие может помочь, но это огромный масштаб сжатия, требуемый за минимальным несжатым двоичным представлением , чтобы перейти на 1 ГБ. Оптимизированный для более длительных поисков, мы получаем только 20 ГБ. поэтому я думаю, что даже если бы у вас были генетические типы информации, вы бы разобрались. Белки с такой сложностью будут еще более сложными, так как лучшее, на что вы можете надеяться, это 5-битная нотация, что означает, что у вас есть 6 на 32, что означает, что ваш лучший вариант для хранения - 30 ГБ на столбец. Поэтому, если вы не можете получить сжатие, может снова помочь, но это большая степень сжатия. Я видел хорошие коэффициенты сжатия, но имейте в виду, что вы можете его нажимать.

Таким образом, моя рекомендация должна быть осведомлена об этой проблеме и провести некоторое тестирование с использованием реальных данных. Будьте осторожны, чтобы разложить ваши показания в некоторых случаях.

ответил Chris Travers 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 04 Sep 2012 09:15:27 +0400 2012, 09:15:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132