Біологічні послідовності 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;

Вивчаючи функції 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 ГБ на стовпчик. Тому, якщо ви не зможете отримати компресію, знову може допомогти, але для цього потрібен великий коефіцієнт стиснення. Я бачив хороші показники стиснення, але майте на увазі, що ви можете наштовхнути його.

Тож моя рекомендація знає про цю проблему і зробіть тестування з реальними даними. Будьте готові розкласти свої показання в деяких випадках.