การออกแบบสถาปัตยกรรม API เพื่อการอ่านไฟล์ข้อความอย่างรวดเร็วพร้อมป้ายกำกับที่ไม่ซ้ำกัน 150 เมตร
สมมติว่าไฟล์ข้อความที่มีระเบียนเฉพาะ 150 ม.
แต่ละระเบียนมีสองคอลัมน์: (1) สตริงและ (2) จำนวนเต็ม
สตริงเป็นป้ายกำกับเฉพาะและจำนวนเต็มคือค่าของป้ายกำกับ
แบบสอบถามเดียวจะส่งคืนค่าจำนวนเต็มสำหรับป้ายกำกับที่กำหนด
เรากำลังสำรวจสถาปัตยกรรมหลายแบบเพื่อแสดงไฟล์ข้อความนี้เป็น API
ไฟล์ข้อความนี้จะสร้างใหม่ทุก 72 ชั่วโมง ~ 90% ของข้อมูลยังคงเหมือนเดิมในการสร้างใหม่ แต่การสร้างใหม่นี้ถูกควบคุมโดยบุคคลที่สาม เราได้รับไฟล์ข้อความใหม่ทุกๆ 72 ชั่วโมง
เราตั้งเป้าไว้ที่ประสิทธิภาพการสืบค้น 100ms - 500ms ต่อการอ่าน
สถาปัตยกรรม 1
- จัดเก็บไฟล์ข้อความบนดิสก์ ค้นหาไฟล์ข้อความ คิวรีแคชในหน่วยความจำ
- ข้อดี: ใช้งานง่าย อัปเดตข้อมูลได้ง่าย
- จุดด้อย: ไม่สง่างาม ข้อความค้นหาที่ไม่ได้เก็บไว้อ่านช้า
สถาปัตยกรรม 2
- แยกวิเคราะห์ไฟล์ข้อความเป็นฐานข้อมูลแบบดั้งเดิม / NoSQL โดยแต่ละบรรทัดถือเป็นบันทึกฐานข้อมูล / เอกสาร เรียกใช้แบบสอบถามกับฐานข้อมูล
- จุดเด่น: ดูเหมือนสถาปัตยกรรมมาตรฐาน
- จุดด้อย: การอัปเดตระเบียนฐานข้อมูล 150m นั้นช้าและดูเหมือนสิ้นเปลืองโดยเฉพาะอย่างยิ่งเนื่องจาก ~ 90% ของระเบียนยังคงเหมือนเดิม
สถาปัตยกรรม 3
- ใช้ Redis หรือฐานข้อมูลในหน่วยความจำเพื่อจัดเก็บไฟล์ข้อความขนาด 5GB รันคิวรีกับฐานข้อมูลในหน่วยความจำ
- ข้อดี: การสืบค้นด่วน อัปเดตข้อมูลได้ง่าย
- จุดด้อย: แพง
สถาปัตยกรรม 4
- ใช้ ElasticSearch เพื่อสืบค้นเร็กคอร์ด
- ข้อดี: ElasticSearch ออกแบบมาเพื่อการค้นหา
- จุดด้อย: ES อาจมากเกินไปสำหรับการสืบค้นง่ายๆเช่นนี้
คำถาม:
เราควรพิจารณาสถาปัตยกรรมอื่น ๆ หรือมีข้อดี / ข้อเสียที่เรามองข้ามไปหรือไม่?
ความท้าทายทางวิศวกรรมนี้ดูเหมือนจะเป็นเรื่องธรรมดา: อะไรคือสถาปัตยกรรม "มาตรฐาน" ที่สุดสำหรับการสร้างสมดุลระหว่างต้นทุน / ประสิทธิภาพเมื่อพยายามสร้างการอ่านอย่างรวดเร็วเทียบกับที่เก็บข้อมูล 150 ล้านระเบียนที่เปลี่ยนแปลง
คำตอบ
โดยทั่วไปแล้วสิ่งนี้ดูเหมือนจะเป็นกรณีคลาสสิกสำหรับโฟลว์ ETL: รับไฟล์ใหม่แยกข้อมูลแปลงเป็นรูปแบบของคุณและโหลดไปยังฐานข้อมูลของคุณ หมายเหตุบางประการ:
สิ่งสำคัญที่ต้องจำไว้คือการโหลดและการสืบค้นนั้นเป็นการดำเนินการที่แตกต่างกันและไม่เกี่ยวข้องกันเลย คำถามหนึ่งคือ "ฉันจะโหลดไฟล์บันทึก 150m รายวันอย่างมีประสิทธิภาพลงในที่เก็บข้อมูลได้อย่างไรเมื่อ 90% ของระเบียนซ้ำกัน" และอีกคำถามคือ "ฉันจะสืบค้นคีย์ / ค่าบันทึก 150 ล้านรายการอย่างมีประสิทธิภาพได้อย่างไร" ตอบคำถามสองข้อนี้แยกกันเพราะเป็นอิสระ
สำหรับคำถามแรกคุณกังวลว่าการโหลดบันทึกที่เหมือนกัน 90% จะเป็นการสิ้นเปลือง คุณได้วัดเวลาที่ใช้แล้วหรือยัง? การอ่านบันทึก 150m จากไฟล์ข้อความควรใช้เวลาไม่กี่วินาทีและที่เก็บคีย์ / ค่าที่ดีควรสามารถเพิ่มประสิทธิภาพการดำเนินการ UPDATE ซ้ำซ้อนได้ หรืออีกวิธีหนึ่งคือเปลี่ยนไฟล์ใหม่กับไฟล์ก่อนหน้าเพื่อสร้างรายการการเปลี่ยนแปลงจริงโดยเป็นส่วนหนึ่งของโฟลว์ ETL ของคุณจากนั้นดำเนินการโหลด กำหนดเมตริกสำหรับโซลูชันนี้ (เวลาทั้งหมดในการอ่านความแตกต่างการโหลดการหยุดชะงักของการดำเนินการสืบค้นขณะกำลังโหลด ฯลฯ ) เพื่อให้คุณสามารถประเมินโซลูชันของคุณได้
สำหรับคำถาม # 2 ให้หลีกเลี่ยงการใช้โซลูชันแบบกำหนดเองเมื่อมีตัวเลือกนอกชั้นวางอยู่ ElasticSearch อาจใช้งานมากเกินไปเนื่องจากคุณเพียงแค่จัดเก็บจำนวนเต็มที่สำคัญ แต่มีคีย์ / ค่ามากมายที่เก็บไว้ที่นั่นซึ่งจะให้ประสิทธิภาพที่ดีสำหรับการอ่านรวมถึงการแคชหน่วยความจำที่สำรองไว้ด้วยดิสก์การแคช MRU หรือกลยุทธ์การแคชที่แตกต่างกันขึ้นอยู่กับการใช้งานของคุณ อาจจะเป็นการดำเนินการอัปเดตแบบไม่ใช้ระบบดังกล่าวข้างต้นและอื่น ๆ อีกครั้งตามคำถาม # 1 กำหนดเมตริกสำหรับความสำเร็จ คุณบอกว่า "การโหลด 5GB ลงใน RAM มีราคาแพงใช่ไหมเซิร์ฟเวอร์ของคุณมี RAM เท่าไหร่คุณลองใช้การแคชแบบสอบถามทั่วไปจำเป็นไหมอ่านแบบไม่แคชเร็วแค่ไหนวัด! คุณต้องการกลยุทธ์การแคชแบบกำหนดเองเช่นการตรวจสอบเร็กคอร์ดที่เกี่ยวข้องหรือไม่ ตรวจสอบรูปแบบการใช้งานของคุณ
ฉันไม่สามารถบอกคุณได้ว่าแนวทางที่ดีที่สุดคืออะไร มีตัวแปรมากเกินไปที่คุณเท่านั้นที่รู้ - งบประมาณของคุณและรูปแบบการใช้งานแผนในอนาคตสำหรับระบบและศักยภาพในการขยายความสัมพันธ์กับแหล่งข้อมูลของบุคคลที่สาม (เช่นสามารถมั่นใจได้ว่าจะสร้างความแตกต่างหรือเพิ่มแท็กการประทับเวลา / เวอร์ชัน สำหรับบันทึก ฯลฯ ) สิ่งที่ทำได้คือแนะนำรูปแบบหลัก: การส่งผ่านข้อมูลแยกจากขั้นตอนการสืบค้นใช้เครื่องมือที่ทดลองและทดสอบแล้วและเหนือสิ่งอื่นใดการวัดการวัดการวัด
คุณอาจพิจารณาแนวทางของ cdb ของDJBernsteinซึ่งก็คือ:
cdb เป็นแพ็คเกจที่รวดเร็วเชื่อถือได้ง่ายสำหรับการสร้างและอ่านฐานข้อมูลคงที่ โครงสร้างฐานข้อมูลมีคุณสมบัติหลายประการ:
การค้นหาอย่างรวดเร็ว: การค้นหาที่ประสบความสำเร็จในฐานข้อมูลขนาดใหญ่โดยปกติจะใช้การเข้าถึงดิสก์เพียงสองครั้ง การค้นหาที่ไม่สำเร็จจะใช้เวลาเพียงครั้งเดียว
ค่าใช้จ่ายต่ำ: ฐานข้อมูลใช้ 2048 ไบต์บวก 24 ไบต์ต่อเร็กคอร์ดรวมทั้งพื้นที่สำหรับคีย์และข้อมูล
ไม่ จำกัด การสุ่ม: cdb สามารถจัดการฐานข้อมูลใด ๆ ได้ถึง 4 กิกะไบต์ ไม่มีข้อ จำกัด อื่น ๆ บันทึกไม่จำเป็นต้องพอดีกับหน่วยความจำ ฐานข้อมูลจะถูกจัดเก็บในรูปแบบที่ไม่ขึ้นกับเครื่อง
การเปลี่ยนฐานข้อมูลปรมาณูอย่างรวดเร็ว: cdbmake สามารถเขียนใหม่ทั้งฐานข้อมูลสองลำดับขนาดได้เร็วกว่าแพ็คเกจการแฮชอื่น ๆ
การทิ้งฐานข้อมูลอย่างรวดเร็ว: cdbdump พิมพ์เนื้อหาของฐานข้อมูลในรูปแบบที่เข้ากันได้กับ cdbmake
cdb ได้รับการออกแบบมาเพื่อใช้ในแอปพลิเคชันที่มีความสำคัญต่อภารกิจเช่นอีเมล การเปลี่ยนฐานข้อมูลจะปลอดภัยต่อระบบล่ม ผู้อ่านไม่ต้องหยุดชั่วคราวระหว่างการเขียนซ้ำ
คุณอาจจะต้องการการใช้งานที่ทันสมัยมากขึ้นที่ไม่ได้มีขีด จำกัด 4GiB เช่นนี้อย่างใดอย่างหนึ่ง