ระบบจัดเก็บข้อมูลพร้อมกันสูง


12

ลองนึกภาพความต้องการของคุณคือคุณมีตารางขนาดใหญ่ 3 ตาราง (ข้อมูลที่มีโครงสร้าง) โดยมีจำนวนแถวละ 30,000 ล้านแถว (ขนาดรวม 4TB) และผู้ใช้ที่ใช้งานพร้อมกันจำนวนมาก (ซึ่งเป็นเธรดระบบปฏิบัติการแบบขนานบนเครื่อง LAN ระยะไกล) ข้อมูลผ่าน SELELCT WHERE GROUPBY ของพวกเขาและพร้อมกันสูงพูด 10,000 อ่านพร้อมกันในเวลาเดียวกันและผู้ใช้จำเป็นต้องแทรกข้อมูล (ไม่มีการปรับปรุง) ลงในตารางเหล่านี้พร้อมกันสูงเช่นนักเขียนพร้อมกัน 2000 (ทั่วเครือข่าย LAN ของศูนย์ข้อมูล) . ผู้ใช้ต้องการอ่านและแทรกให้เร็วที่สุดเท่าที่จะเป็นไปได้ในรูปแบบที่เก็บข้อมูลนี้ซึ่งการอ่านและเขียนแต่ละอันจะเกิดขึ้นคือ ms ถึง 1 วินาที

เทคโนโลยีใดที่คุณแนะนำให้ตอบสนองความต้องการดังกล่าว มีที่เก็บข้อมูลหรือที่เก็บค่าคีย์ที่สามารถทำสิ่งนี้ได้หรือไม่? คลาวด์ไม่ใช่ตัวเลือก

ชี้แจงบางส่วน:

ผู้ใช้ไม่จำเป็นต้องเห็นข้อมูลทันทีและยอมรับความสอดคล้องในที่สุด ข้อมูลสามารถเข้าถึงได้ผ่านทุกไดรเวอร์ที่หน่วยเก็บข้อมูลสามารถให้และผู้ใช้จะเป็นเพียงเธรดที่ทำงานบนเครื่องระยะไกลของศูนย์ข้อมูล ข้อความค้นหาส่วนใหญ่จะเป็นเหมือน SELECT WHERE GROUPBY

ข้อมูลอยู่ในรูปแบบตารางและแต่ละแถวมีขนาดประมาณ 60 ไบต์

ไม่มีตัวเลือกคลาวด์ที่ฉันไม่สามารถใช้ DynamoDB หรือโซลูชันที่คล้ายกัน ฉันต้องสามารถโฮสต์ภายในศูนย์ข้อมูลได้

ข้อมูลทั้งหมดของตารางสามารถอ่านได้ตลอดเวลาและรูปแบบการใช้งานไม่แน่นอน ไม่มีการเข้าร่วมหรือการสืบค้นที่ยาวมาก ไม่จำเป็นต้องใช้ DR แต่จำเป็นต้องใช้ HA ที่เหมาะสม แต่ไม่จำเป็นต้องแฟนซี ผู้อ่านทุกคนได้รับชุดของแถวตามที่ส่วนคำสั่งและแถวไม่เกี่ยวข้องจริง ๆ เราอาจมีความยาวคงที่สำหรับแต่ละแถว แต่ฉันหวังว่าเลเยอร์การจัดเก็บจะกังวลเกี่ยวกับมัน

นอกจากนี้ความกังวลที่ยิ่งใหญ่ที่สุดของฉันคือการเขียนพร้อมกันทั้งหมดที่เกิดขึ้นกับการอ่านพร้อมกัน

ข้อมูลเชิงลึกของคุณเกี่ยวกับเรื่องนี้เป็นที่นิยมอย่างสูง

และยิ่งกว่านั้นฉันมีตารางสามตารางที่แต่ละแถวมีจำนวน 30,000 ล้านแถวที่มีชนิดของวัตถุต่างกัน


กำหนดคลาวด์เพราะสิ่งที่คนส่วนใหญ่พูดว่า 99% ของประชาชนทั่วไปและ 100% ของนักการตลาดเรียกว่าคลาวด์เป็นเพียงกลุ่มที่คนอื่นดูแล

ฉันหมายความว่าฉันไม่สามารถใช้ DynamoDB หรือเทคโนโลยีบางอย่างที่มีเฉพาะในระบบคลาวด์สาธารณะเช่น amazon หรือ azure เป็นต้น
iCode

คำตอบ:


6

หากความสอดคล้องในที่สุดเป็นที่ยอมรับและข้อความค้นหาทั้งหมดของคุณเป็นผลรวมบางทีระบบ OLAP ที่มีความหน่วงต่ำอาจใช้งานได้สำหรับคุณ ความต้องการของคุณฟังเหมือนแพลตฟอร์มการซื้อขายอัลกอริทึม สถาปัตยกรรมประเภทนี้มักจะใช้ในระบบการซื้อขายที่มีความต้องการที่จะดำเนินการคำนวณการวิเคราะห์ทางสถิติโดยรวมในข้อมูลที่ทันสมัย

หากคุณสามารถแบ่งพาร์ติชันข้อมูลตามวันที่และแถวเก่าไม่ได้รับการอัปเดตคุณสามารถสร้างระบบไฮบริด OLAP โดยใช้เซิร์ฟเวอร์ OLAP ทั่วไปเช่นบริการวิเคราะห์ Microsoft ที่สนับสนุนโดยแพลตฟอร์ม RDBMS ทั่วไป มันควรจะเป็นไปได้ที่จะทำให้สิ่งนี้รับมือกับ ~ 4TB ของข้อมูลและทั้ง SQL Server และ SSAS จะทำกลุ่มดิสก์ที่ใช้ร่วมกัน ระบบ OLAP ที่คล้ายกัน (เช่น Oracle / Hyperion Essbase) มีให้บริการจากผู้ขายรายอื่น

เซิร์ฟเวอร์ OLAP ทำงานโดยเก็บข้อมูลในร้านค้าดั้งเดิมพร้อมกับรวม ส่วนใหญ่จะสนับสนุนข้อมูลที่แบ่งพาร์ติชัน นอกจากนี้ส่วนใหญ่จะทำงานในโหมด ROLAP ซึ่งพวกเขาจะออกแบบสอบถามกับฐานข้อมูลพื้นฐาน สิ่งสำคัญที่ควรทราบคือกลยุทธ์การจัดเก็บสามารถจัดการแบบต่อพาร์ติชันและคุณสามารถสลับพาร์ติชันจากแบบหนึ่งไปเป็นแบบอื่นได้โดยทางโปรแกรม

ในรูปแบบนี้ข้อมูลประวัติจะถูกเก็บไว้ในพาร์ติชัน MOLAP ด้วยการรวมของข้อมูลยังคงอยู่ หากแบบสอบถามสามารถทำได้จากผลรวมแล้วเซิร์ฟเวอร์จะใช้พวกเขา การรวมสามารถปรับให้เหมาะสมกับการสืบค้นและการรวมที่ถูกต้องจะลดจำนวนการคำนวณที่จำเป็นในการแก้ไขแบบสอบถามอย่างมาก สามารถรวมข้อความค้นหาที่ตอบสนองได้ดีกับระบบประเภทนี้

ข้อมูลเรียลไทม์สามารถดำเนินการได้โดยการบำรุงรักษาพาร์ติชันชั้นนำขนาดเล็ก - สำหรับเดือนวันหรือชั่วโมงปัจจุบันถ้าจำเป็น เซิร์ฟเวอร์ OLAP จะออกแบบสอบถามกับฐานข้อมูล ถ้าพาร์ติชันนี้มีขนาดเล็กพอ DBMS จะสามารถตอบสนองได้อย่างรวดเร็ว กระบวนการปกติสร้างพาร์ติชั่นชั้นนำใหม่และแปลงช่วงเวลาทางประวัติศาสตร์ที่ปิดเป็น MOLAP พาร์ติชั่นที่เก่ากว่าสามารถรวมกันได้ทำให้สามารถจัดการข้อมูลประวัติได้ในทุกเม็ดที่ต้องการ

ลูกค้าที่เขียนไปยังฐานข้อมูลเพียงแค่เขียน RDBMS พื้นฐานโดยตรง หากข้อมูลประวัติยังคงอยู่พวกเขาจะถูกเขียนไปยังพาร์ทิชันชั้นนำเท่านั้น 4TB เป็นโวลุ่มที่ใช้งานได้จริงหากคุณต้องการประสิทธิภาพของ DBMS เพิ่มเติม แม้แต่ผู้ค้ารายใหญ่ก็ยังมีข้อเสนอ SSD ที่มาพร้อมกับหน่วย SLC ที่เร็วขึ้น


ขอขอบคุณสำหรับการตอบสนองของคุณ. คุณถูก. ปัญหาของฉันคล้ายกับแพลตฟอร์มการซื้อขายอัลกอริทึม แต่ก็แตกต่างกัน เราได้ลองใช้เส้นทาง RDBMS แล้วและไม่สามารถปรับขนาดได้ ฉันต้องการที่เก็บข้อมูลที่สามารถปรับขนาดและไม่มีความซับซ้อนของระบบ OLAP เนื่องจากขนาดของข้อมูลของเราเพิ่มขึ้นและเมื่อเราได้รับ TB เพิ่มขึ้นในสามตาราง RDBMS จะสร้างการล็อคและปัญหาที่คล้ายกันจำนวนมาก ฉันหวังว่าตัวเลือก nosql สามารถตอบสนองความต้องการดังกล่าว ความคิดใด ๆ
iCode

@MDotnet ความคาดหวัง / ความต้องการของคุณสำหรับการแก้ปัญหาอย่างง่ายสำหรับผู้ใช้งานพร้อมกัน 12k ปัญหาขนาด 4TB อาจไม่สมจริง คุณพูดถึงว่าคุณดูที่วิธีการของ RDBMS และมันไม่ได้ปรับขนาด 1) คุณสามารถเพิ่มรายละเอียดของสิ่งนี้ลงใน Q 2 ของคุณได้หรือไม่คำตอบนี้สนับสนุนการผสมผสานระหว่าง ROLAP / MOLAP ไม่ใช่ฐานข้อมูลเชิงสัมพันธ์ที่บริสุทธิ์
Mark Storey-Smith

ฉันไม่ใช่ DBA และฉันคิดว่า "การขับเคลื่อนโดยผู้อัปโหลด" นั้นไม่ดีสำหรับเว็บไซต์ส่วนใหญ่โดยเฉพาะ แต่ฉันไม่สนใจคำตอบนี้ดีเกินไปสำหรับการอัปเดตเพียงครั้งเดียว +1
psr
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.