ลำดับทางชีวภาพของ UniProt ใน PostgreSQL

วิธีที่ดีที่สุดในการจัดเก็บลำดับทางชีวภาพของ UniProt ใน PostreSQL คืออะไร

รายละเอียดข้อมูล

• เราดึงลำดับ 12 ล้านจากUniProt - จำนวนนี้น่าจะเพิ่มเป็นสองเท่าทุก 3-10 เดือน
• ความยาวของลำดับสามารถเปลี่ยนแปลงได้ตั้งแต่ 10 ถึง 50 พันล้านตัวอักษร
• น้อยกว่า 1% ของลำดับนั้นยาวกว่า 10,000 ตัวอักษร
  • มันจะปรับปรุงประสิทธิภาพในการจัดเก็บลำดับที่ยาวกว่าแยกกันหรือไม่
• ลำดับสามารถเป็นได้ทั้งโปรตีนหรือตัวอักษรดีเอ็นเอ
  • ตัวอักษร DNA มี 5 ตัวอักษร (A, T, C, G หรือ -)
  • ตัวอักษรโปรตีนจะมีประมาณ 30 ตัวอักษร
  • เราไม่รังเกียจที่จะเก็บลำดับของตัวอักษรสองตัวที่แตกต่างกันในคอลัมน์ที่แตกต่างกันหรือแม้แต่ตารางที่แตกต่างกัน จะช่วยได้ไหม

รายละเอียดการเข้าถึงข้อมูล

เพื่อตอบความคิดเห็นของ Jeremiah Peschka:

• ลำดับโปรตีนและ DNA จะเข้าถึงได้ในเวลาที่ต่างกัน
• ไม่จำเป็นต้องค้นหาภายในลำดับ (ที่ทำนอกฐานข้อมูล)
• อีเธอร์จะเข้าถึงทีละแถวหรือดึงชุดของแถวด้วย ID เราไม่จำเป็นต้องสแกนแถว ลำดับทั้งหมดถูกอ้างอิงโดยตารางอื่น ๆ - มีลำดับชั้นทางชีววิทยาและลำดับความสำคัญหลายลำดับที่มีอยู่ในฐานข้อมูล

ความเข้ากันได้ย้อนหลัง

มันจะเป็นการดีที่จะสามารถใช้ฟังก์ชัน hashingต่อไปนี้ได้(SEGUID - SEquence Unique 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 GB

ดังนั้นการวางตารางลงในพื้นที่ตารางขนาดใหญ่มากบนฮาร์ดแวร์เฉพาะควรเพียงพอสำหรับเป้าหมายประสิทธิภาพของคุณ หาก 1 GB มีขนาดเล็กเกินไปสำหรับข้อมูลของคุณ int_interval จาก ProtBio ควรมอบประสิทธิภาพที่ยอดเยี่ยม:

คุณลักษณะลำดับสอดคล้องกับ triplet (id, orient, ii) โดยที่ id คือตัวระบุลำดับ (อาจเป็นคีย์หลักสำหรับตารางลำดับ) orient เป็นบูลีนที่ระบุว่าคุณลักษณะนั้นอยู่ในทิศทางเดียวกันหรือตรงกันข้ามกับลำดับ และ ii คือ int_interval ที่แสดงถึงคุณลักษณะที่เป็นส่วนประกอบ

การเข้ารหัสลำดับใน sha1 ดูเหมือนจะเป็นวิธีที่เจ็บปวดมากในการสร้าง GUID โดยพิจารณาความยาวที่อาจเกิดขึ้นของลำดับ

หากลำดับที่แตกต่างกันไม่เกี่ยวข้องให้จัดเก็บไว้ในพื้นที่ตารางต่าง ๆ บนดิสก์ที่ต่างกันเพื่อประสิทธิภาพสูงสุด

ฉันคิดว่าตัวละคร 50 พันล้านตัวมีแนวโน้มที่จะผลักดันขีด จำกัด ของสิ่งที่คุณสามารถทำได้กับ PostgreSQL โดยไม่แยกบันทึกของคุณในบางวิธี ฉันสงสัยว่าคุณจะต้องหาวิธีที่จะทำลายสิ่งต่าง ๆ ในทางใดทางหนึ่ง ฉันไม่ทราบว่าการเข้ารหัสแบบโพสบิโออนุญาตให้ใช้ แต่ ....

การคำนวณอย่างรวดเร็วที่นี่: 5 ตัวอักษรต้องการการเข้ารหัส 3 บิต แต่ 4 บิตจะทำให้การค้นหาง่ายขึ้นเนื่องจากสามารถเข้ารหัสอักขระสองตัวต่อไบต์ ในทางกลับกัน 3 อาจเพียงพอหากคุณค้นหากลุ่มที่มี 10 ตัวอักษรหรือมากกว่าเนื่องจากคุณสามารถทำ 10 อักขระต่อ 4 ไบต์ ปรับให้เหมาะสมสำหรับการค้นหาสตริงสั้น ๆ ตัวอักษร 50 พันล้านตัวใช้พื้นที่เก็บข้อมูลประมาณ 25gb ซึ่งมากกว่าสิ่งที่คุณสามารถทำได้ในคอลัมน์เดียว การบีบอัดอาจช่วยได้ แต่นั่นเป็นระดับการบีบอัดขนาดใหญ่ที่ต้องการนอกเหนือจากการแสดงไบนารีแบบไม่บีบอัดที่น้อยที่สุดเพื่อลดขนาดลง 1GB ปรับให้เหมาะสมสำหรับการค้นหาที่ยาวนานขึ้นเราได้รับเพียง 20GB ดังนั้นฉันคิดว่าแม้ว่าคุณจะมีประเภทข้อมูลพันธุกรรมคุณจะต้องเลิกกัน โปรตีนที่มีความซับซ้อนนั้นจะยิ่งท้าทายมากขึ้นเพราะสิ่งที่ดีที่สุดที่คุณสามารถคาดหวังได้คือโน้ต 5 บิตซึ่งหมายความว่าคุณมี 6 ต่อ 32 หมายความว่ากรณีที่ดีที่สุดสำหรับการจัดเก็บคือ 30GB ต่อคอลัมน์ ดังนั้นหากคุณไม่ได้รับการบีบอัดอาจช่วยได้อีก แต่นั่นเป็นอัตราการบีบอัดขนาดใหญ่ที่จำเป็น ฉันเห็นอัตราการบีบอัดที่ดี แต่โปรดจำไว้ว่าคุณอาจกำลังผลักดันมัน

ดังนั้นคำแนะนำของฉันคือตระหนักถึงปัญหานี้และทำการทดสอบด้วยข้อมูลจริง ระมัดระวังในการย่อยสลายการอ่านของคุณในบางกรณี