การออกแบบระบบ (System Design) 3 กลยุทธ์ Caching เพื่อความเร็วสูงสุด

System Design Deep Dive กลยุทธ์ Caching เพื่อความเร็วสูงสุด

เราได้เรียนรู้แล้วว่า Database คือ หัวใจของระบบ แต่การเข้าไปค้นหาข้อมูลใน Database ทุกครั้งที่ผู้ใช้ร้องขอ ก็เปรียบเหมือนการต้องวิ่งไปค้นเอกสารในห้องสมุดขนาดใหญ่ทุกครั้ง ซึ่งทั้งช้าและเสียเวลา Caching จึงเข้ามามีบทบาทเป็น "โต๊ะทำงาน" ที่เราวางหนังสือที่ใช้บ่อยๆ ไว้ใกล้มือ ทำให้หยิบใช้ได้ทันที แต่คำถามสำคัญ คือ "เราจะจัดการหนังสือบนโต๊ะทำงาน (Cache) กับในห้องสมุด (Database) ให้ตรงกันเสมอได้อย่างไร?" บทความนี้จะเจาะลึกกลยุทธ์การทำ Caching ในรูปแบบต่างๆ เพื่อตอบคำถามนี้ และช่วยให้คุณเลือกใช้เทคนิคที่เหมาะสมที่สุดกับงาน

ทบทวน: Cache-Aside (Lazy Loading)

นี่คือกลยุทธ์พื้นฐานที่สุดที่นักพัฒนานิยมใช้ และเป็นแบบที่เราได้เคยพูดถึงไปแล้ว

1. Read: แอปพลิเคชันจะมองหาข้อมูลใน Cache ก่อน

2. Cache Miss: ถ้าไม่เจอ จะไปดึงข้อมูลจาก Database

3. Update Cache: จากนั้นนำข้อมูลที่ได้จาก Database มาเก็บไว้ใน Cache เพื่อใช้ในครั้งต่อไป

4. Write: แอปพลิเคชันจะเขียนข้อมูลใหม่ลงใน Database โดยตรง และมักจะลบข้อมูลเก่าที่เกี่ยวข้องออกจาก Cache ไปด้วย (เพื่อบังคับให้ครั้งต่อไปต้องอ่านจาก Database ใหม่)

ข้อดี: ง่ายต่อการนำไปใช้, Cache จะเก็บเฉพาะข้อมูลที่มีการร้องขอจริงๆ ข้อเสีย: การอ่านครั้งแรก (Cache Miss) จะช้าเสมอ, ข้อมูลใน Cache กับ Database อาจไม่ตรงกันในบางจังหวะ

กลยุทธ์สำหรับ "การเขียน" ข้อมูล (Write Policies)

ปัญหาของ Cache-Aside คือการจัดการข้อมูลตอนเขียนที่อาจทำให้ข้อมูลไม่ตรงกัน (Inconsistent) กลยุทธ์ต่อไปนี้จึงถูกออกแบบมาเพื่อแก้ปัญหานี้

1. Write-Through (เขียนทะลุ)

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

• การทำงาน: App -> Write to Cache -> Cache writes to DB -> Success

• ข้อดี: ข้อมูลตรงกันเสมอ! รับประกันได้ว่าข้อมูลใน Cache กับ Database จะเหมือนกันตลอดเวลา เพราะเขียนพร้อมกัน

• ข้อเสีย: การเขียนจะช้าลง เพราะต้องรอให้เขียนลง Database ซึ่งช้ากว่าให้เสร็จสิ้นก่อน

• เหมาะกับ: ระบบที่ต้องการความถูกต้องของข้อมูลสูงสุด และยอมรับการเขียนที่ช้าลงได้ เช่น ระบบธนาคาร, ระบบจัดการสต็อกสินค้าที่ความผิดพลาดรับไม่ได้

2. Write-Back / Write-Behind (เขียนทีหลัง)

นี่คือกลยุทธ์ที่เน้นความเร็วในการเขียนสูงสุด แอปพลิเคชันจะเขียนข้อมูลลงที่ Cache เท่านั้น แล้วตอบกลับผู้ใช้ทันทีว่า "สำเร็จ" โดยไม่ต้องรอเขียนลง Database

จากนั้น Cache จะรวบรวมข้อมูลที่ถูกเขียนไว้หลายๆ รายการ แล้วค่อยนำไปเขียนลง Database ในภายหลังเป็นชุดๆ (เช่น ทุก 1 นาที หรือเมื่อมีข้อมูลครบ 100 รายการ)

• การทำงาน: App -> Write to Cache -> Success (Cache จะหาจังหวะเขียนลง DB เองทีหลัง)

• ข้อดี: เขียนเร็วมาก! เพราะทำงานกับ Cache ที่อยู่ใน Memory ซึ่งเร็วกว่า Disk ของ Database หลายเท่า

• ข้อเสีย: เสี่ยงข้อมูลหาย! หาก Cache ล่มก่อนที่จะได้เขียนข้อมูลลง Database ข้อมูลที่ค้างอยู่ทั้งหมดจะหายไปทันที

• เหมาะกับ: ระบบที่ต้องการประสิทธิภาพในการเขียนสูงมากๆ และยอมรับความเสี่ยงข้อมูลหายเล็กน้อยได้ เช่น ระบบนับยอดวิว, การเก็บ Log, หรือระบบที่ข้อมูลเปลี่ยนแปลงบ่อยมากๆ

เปรียบเทียบกลยุทธ์ Caching

แล้วถ้า Cache เต็มล่ะ? (Eviction Policies)

เมื่อ Cache เต็ม เราต้องเลือกว่าจะลบข้อมูลเก่าชิ้นไหนทิ้งไปเพื่อเอาที่ว่างมาให้ข้อมูลใหม่ ซึ่งมีนโยบาย (Policy) ที่นิยมใช้กันคือ:

• LRU (Least Recently Used): ลบข้อมูลที่ "ถูกใช้งานนานที่สุดแล้ว" ทิ้งไป

• LFU (Least Frequently Used): ลบข้อมูลที่ "ถูกใช้งานน้อยครั้งที่สุด" ทิ้งไป

• FIFO (First-In, First-Out): ข้อมูลที่เข้ามาใน Cache ก่อน ก็จะถูกลบออกไปก่อน (เหมือนท่อ)

การทำ Caching ไม่ใช่แค่การเอาข้อมูลมาพักไว้ แต่คือศาสตร์และศิลป์ในการเลือกลยุทธ์ที่สมดุลระหว่าง ความเร็ว (Performance) และ ความถูกต้องของข้อมูล (Consistency) การเข้าใจกลยุทธ์อย่าง Write-Through และ Write-Back จะทำให้คุณสามารถออกแบบระบบที่ตอบโจทย์ทางธุรกิจได้อย่างแท้จริง ไม่ว่าจะเป็นระบบที่ต้องการความถูกต้อง 100% หรือระบบที่ต้องการความเร็วเป็นที่หนึ่ง

ที่มาข้อมูล

- 

ที่มาภาพและรวบรวม

- www.iok2u.com 

-------------------------

สนใจเรื่องราวเพิ่มเติมคลิกที่นี่

การรวมระบบ (System Integration)

-------------------------