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

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

Детали данных

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

Детали доступа к данным

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

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

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

Было бы неплохо иметь возможность продолжать применять следующую последовательность хеширования (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;

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

Согласно документации :

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

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

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

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

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

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

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

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