นักพัฒนาถกเถียงกลยุทธ์การแคชในหน่วยความจำเทียบกับดิสก์สำหรับระบบที่ใช้ S3

ทีมชุมชน BigGo
นักพัฒนาถกเถียงกลยุทธ์การแคชในหน่วยความจำเทียบกับดิสก์สำหรับระบบที่ใช้ S3

ชุมชนเทคโนโลยีกำลังหารือเกี่ยวกับแนวทางต่างๆ ในการแก้ปัญหาความล่าช้าของ S3 หลังจาก RisingWave เผยแพร่รายละเอียดเกี่ยวกับโซลูชันแคชแบบไฮบริดที่เรียกว่า Foyer แม้ว่า S3 จะให้พื้นที่จัดเก็บข้อมูลไม่จำกัดในราคาต่ำ แต่ความล่าช้า 50-150 มิลลิวินาทีทำให้ไม่เหมาะสำหรับแอปพลิเคชันแบบเรียลไทม์ที่ต้องการการเข้าถึงข้อมูลที่รวดเร็ว

การเปรียบเทียบ Latency ระหว่าง S3 กับ Local Storage

  • เวลาในการรับ byte แรกของ S3 : 50-150ms
  • การเข้าถึง Memory : ~0ms
  • การเข้าถึง Disk : 0.2-1ms
  • S3 Express One Zone : หลายมิลลิวินาทีเท่านั้น

Swap เทียบกับการจัดการแคชแบบชัดเจน

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

อย่างไรก็ตาม คนอื่นๆ ชี้ให้เห็นข้อเสียร้ายแรงของแนวทาง swap สำหรับงานที่ต้องการความล่าช้าต่ำ page faults และ swapping สร้างการเพิ่มขึ้นของประสิทธิภาพที่คาดเดาไม่ได้ซึ่งส่งผลเสียต่อเวลาตอบสนอง สภาพแวดล้อมการผลิตหลายแห่งตั้งใจปิดใช้งาน swap เพื่อป้องกันปัญหาเหล่านี้ ทำให้การจัดการแคชแบบชัดเจนเชื่อถือได้มากกว่าในสถานการณ์การใช้งานที่แตกต่างกัน

กลยุทธ์การจัดการแคช

  • การจัดการแบบชัดเจน: การประสานงานแคชหน่วยความจำและดิสก์แบบกำหนดเอง
  • แบบอิงตาม Swap: ให้ระบบปฏิบัติการจัดการการถ่ายโอนหน่วยความจำไปยังดิสก์โดยอัตโนมัติ
  • แนวทางแบบผสม: รวมแคชหน่วyความจำเข้ากับชั้นแคชดิสก์
  • การแลกเปลี่ยน: ความซับซ้อนเทียบกับความสามารถในการคาดการณ์ประสิทธิภาพ

ผลกระทบต่อประสิทธิภาพในโลกจริง

ความแตกต่างด้านประสิทธิภาพระหว่าง S3 และการจัดเก็บข้อมูลในเครื่องมีมากมาย เวลาไปยังไบต์แรกของ S3 อยู่ในช่วง 50-150 มิลลิวินาที ในขณะที่การให้บริการจากหน่วยความจำลดลงเกือบเป็นศูนย์ และการเข้าถึงดิสก์ใช้เวลาเพียง 0.2-1 มิลลิวินาที ช่องว่างขนาดใหญ่นี้อธิบายว่าทำไมการแคชจึงกลายเป็นสิ่งจำเป็นมากกว่าตัวเลือกสำหรับแอปพลิเคชันที่สร้างบน S3

AWS มี S3 Express One Zone ที่มีความล่าช้าเพียงไม่กี่มิลลิวินาที แต่บริการพรีเมียมนี้มุ่งเป้าไปที่กรณีการใช้งานที่แตกต่างกันซึ่งวัตถุเดียวกันต้องการการเข้าถึงบ่อยครั้งในหลายอินสแตนซ์ สำหรับการเข้าถึงซ้ำในอินสแตนซ์เดียว การแคชในเครื่องยังคงคุ้มค่ากว่า

โซลูชันโอเพนซอร์สได้รับความนิยม

โครงการหลายโครงการกำลังสร้างบน Foyer ไลบรารีแคชแบบไฮบริดที่ใช้ Rust ซึ่งได้รับแรงบันดาลใจจาก CacheLib ของ Facebook Distributed Chroma ใช้ Foyer อย่างกว้างขวางในฐานข้อมูลเวกเตอร์โอเพนซอร์สของพวกเขา ในขณะที่นักพัฒนาคนอื่นๆ ได้รวมเข้ากับระบบไฟล์และบริการจัดเก็บข้อมูล ไลบรารีนี้มีทั้งโหมดในหน่วยความจำและแบบไฮบริด ให้นักพัฒนาเริ่มต้นอย่างง่ายและเพิ่มการแคชดิสก์ในภายหลังโดยไม่ต้องเปลี่ยนตรรกะของแอปพลิเคชัน

คุณสมบัติของ Foyer Hybrid Cache

  • เขียนด้วย Rust โดยได้รับแรงบันดาลใจจาก CacheLib ของ Facebook
  • รองรับทั้งโหมดในหน่วยความจำและโหมดไฮบริด
  • การแยกแคชในหน่วยความจำแบบ zero-copy
  • เอนจินดิสก์หลายแบบสำหรับงานที่แตกต่างกัน
  • ถูกใช้งานโดย Distributed Chroma และโปรเจกต์โอเพนซอร์สอื่นๆ

การพิจารณาต้นทุนและการแลกเปลี่ยน

แม้ว่าคำขอ GET ของ S3 จะค่อนข้างถูก แต่ต้นทุนที่แท้จริงมาจากผลกระทบของความล่าช้าต่อประสิทธิภาพของแอปพลิเคชันมากกว่าราคาคำขอ ความซับซ้อนของระบบแคชแบบไฮบริดต้องการการวางแผนอย่างระมัดระวังเกี่ยวกับการทำให้แคชไม่ถูกต้อง พฤติกรรม write-through และการจัดการคำขอพร้อมกันสำหรับข้อมูลเดียวกัน

การหารือเผยให้เห็นว่าการเลือกระหว่างกลยุทธ์การแคชที่แตกต่างกันขึ้นอยู่กับความต้องการของงานเฉพาะ ข้อจำกัดในการใช้งาน และเป้าหมายประสิทธิภาพเป็นอย่างมาก เมื่อแอปพลิเคชันมากขึ้นใช้สถาปัตยกรรม S3-first การตัดสินใจเกี่ยวกับการแคชเหล่านี้กลายเป็นสิ่งสำคัญมากขึ้นสำหรับการรักษาประสบการณ์ผู้ใช้ที่ยอมรับได้

อ้างอิง: The Case for Hybrid Cache for Object Stores