วันนี้อ่านบทความเรื่อง Everything you need to know about Caching — System Design
อธิบายเรื่องพื้นฐานเกี่ยวกับ caching หรือข้อมูลชั่วคราว ว่าคืออะไร
มีการใช้งานใน use case หรือในกรณีอะไรบ้าง
รวมทั้ง strategy และ policy การใช้งาน caching ว่าเป็นอย่างไร
ผมคิดว่าเป็นเรื่องพื้นฐานที่นักพัฒนาจำเป็นต้องรู้และเข้าใจ
เพื่อนำมาประยุกต์ใช้งานได้อย่างมีประสิทธิภาพ
จึงทำการสรุปไว้นิดหน่อย
ถ้าเราเข้า website หนึ่ง ๆ ด้วยความเร็วที่แตกต่างและมีข้อจำกัด
การดึงข้อมูลข้อความ รูปภาพ และ vdo ต่าง ๆ ที่มีคุณภาพสูง ๆ นั้น
อาจจะทำให้หน้า web ช้ามาก ๆ
ซึ่งถ้าช้ามาก ๆ นั่นคือ ปัญหาที่จะตามมามากมาย
รวมทั้งสูญเสียโอกาสทางธุรกิจอีกต่างหาก
หนึ่งในวิธีการที่ใช้งานกันคือ การทำระบบ caching
เพื่อจัดเก็บข้อมูลสิ่งที่ไม่ค่อยเปลี่ยนแปลง และใช้งานบ่อย ๆ
ไว้ใกล้กับผู้ใช้งานไปเลย หรือเรียกว่า Locality of Reference
ทำให้เราสามารถใช้ข้อมูลชุดนั้น ๆ ได้รวดเร็วขึ้น
ที่สำคัญยังช่วยลด latency time ของการอ่านข้อมูล
และช่วยเพิ่ม throughput ของระบบเราอีกด้วย
ถ้าอธิบายง่าย ๆ ให้เห็นภาพในช่วง Work From Home กัน
น่าจะแสดงด้วยภาพนี้ นั่นคือ
ถ้าในการทำอาหารหรือหาของกิน ก็ต้องไปหาในตู้เย็นก่อน
แต่ถ้าไม่มีหรือหมดก็ต้องออกไปซื้อที่ตลาด หรือ super market มาใส่ตู้เย็น
ดังนั้นตู้เย็นก็คือ Caching หรือเป็น local storage นั่นเอง
ทำให้เราไม่ต้องเสียเวลาไปซื้อของอยู่ตลอดเวลา
ทำให้เราได้กินอาหารรวดเร็วขึ้น
ระบบงานที่เราพัฒนาขึ้นมา ก็ต้องการรูปแบบการทำงานเช่นนี้เหมือนกัน
แต่ถ้าเป็นในไทยน่าจะเป็นแบบนี้
กลับมาที่ระบบงานหรือ software ของเรากัน
เป็นระบบ Backend ไปดึงข้อมูลหรือจัดการข้อมูลใน Database
ก่อนที่จะส่งข้อมูลเหล่านั้นกลับไปให้ผู้ใช้งานต่อไป
น่าจะมีการทำงานปกติดังรูป
การอ่านข้อมูลจาก Database นั้นใช้ resource และเวลานานใช้ได้เลย
ทั้ง Network ที่ใช้งาน
ทั้ง I/O ที่เกิดขึ้นจากการไปดึงข้อมูลที่อยู่ใน file system
ทั้ง Connection ของ database ที่มีอยู่อย่างจำกัด
ดังนั้นจะดีกว่าไหม
ถ้าเรามีระบบ caching มาช่วย เพื่อลดการเรียกใช้งานมายัง Database
ที่สำคัญที่จัดเก็บข้อมูลของ caching ก็ต้องเร็วและใช้ resource น้อยด้วยเช่นกัน
ยกตัวอย่างเช่น การใช้งาน Key-value database แสดงดังรูป
โดยที่ในการพัฒนาระบบงานนั้น
จะมี caching เยอะมาก ๆ
ทั้งจาก database
ทั้งจากระบบ network
ทั้งจาก data caching
ทั้งจาก browser
ทั้งจาก web server
หรือลงไปในระดับ CPU ก็ยังมี cache level ต่าง ๆ อีกด้วย
สิ่งที่ต้องพึงระวังคือ ข้อมูลชุดเดียวกันอาจจะอยู่หลาย ๆ ที่
ดังนั้นอาจจะทำให้ข้อมูลชุดเดียวกัน
แต่มีรายละเอียดต่างกัน หรือไม่ update (Data inconsistency)
เรื่องนี้ต้องจัดการให้ดี
แนวคิดของ caching นั้นจะมีวงจรชีวิตด้วย
ขึ้นอยู่กับ use case ที่ต้องการใช้งาน ยกตัวอย่างเช่น
- อยู่ตลอดไป
- มีอายุตามที่กำหนด (Expire time)
รวมทั้งยังต้องมีนโยบายของการลบข้อมูลทิ้ง
เมื่อจำนวนพื้นที่ใช้งานเหลือน้อยหรือกำลังจะเต็ม
มิเช่นนั้นระบบ caching อาจจะกลายเป็นปัญหาก็ได้
ยกตัวอย่างเช่น
- LRU (Least Recently Used) ข้อมูลชุดไหนที่ถูกใช้น้อย ๆ จะถูกลบไปก่อน
- LFU (Least Frequently Used) ข้อมูลชุดไหนที่ถูกแก้ไขน้อย ๆ จะถูกลบไปก่อน
- MRU (Most Recently Used) ข้อมูลที่มีอายุนาน และใช้น้อย ๆ จะถูกลบไปก่อน ไม่งั้นมันจะเน่า
โดยระบบ caching ต่าง ๆ ยังมีนโยบายอีกเพียบ
ยกตัวอย่างเช่น Redis จะมี policy ให้เราเลือกใช้ดังนี้
ในบทความอธิบายเรื่องของชนิดของ caching ไว้ดังนี้
โดยจะแยกตามรูปแบบการจัดการ caching กับ database หลัก
ว่ามีการใช้งานอย่างไร
ชนิดที่ 1 Write Through Cache
เป็นการบันทึกข้อมูลไปที่ระบบ caching ก่อน
จากนั้นทำการบันทึกข้อมูลชุดเดียวกันไปยัง database หลัก
ทำให้ข้อมูลทั้งสองที่ตรงกันเสมอ
แต่ปัญหาหลักที่เห็นได้ชัดคือ latency time ที่สูงขึ้น
เพราะว่าต้องบันทึกข้อมูลทั้ง 2 ที่
จะไม่เหมาะกับระบบงานที่มีการเขียนข้อมูลเยอะ ๆ
แต่จะเหมาะกับระบบที่มีการอ่านข้อมูลที่เขียนไปแล้วเยอะ ๆ
และต้องการให้ข้อมูลตรงกันเสมอ
ชนิดที่ 2 Write Back Cache
ทำขึ้นมาเพื่อช่วยแก้ไขปัญหาในระบบที่มีการเขียนสูง ๆ
ทำให้เราบันทึกข้อมูลไปยัง caching ก็พอ
จากนั้นทำการบันทึกข้อมูลที่ database แบบ asynchronous ต่อไป
แต่ปัญหาที่ตามมาคือ จะมีช่วงเวลาที่ข้อมูลทั้งสองที่ไม่ตรงกัน (Data inconsistency)
ยิ่งถ้าระบบงานส่วนอื่น ๆ ต้องใช้ข้อมูลจาก database หลัก
อาจจะทำให้เกิดปัญหาตามมาอีกเยอะเลย
ชนิดที่ 3 Write Around Cache
ทำการบันทึกข้อมูลลง database หลักเลย ไม่ลง caching
แต่ถ้ามีการอ่านข้อมูลจะอ่านข้อมูลจาก caching
แน่นอนว่า ครั้งแรก ๆ จะไม่พบ (cache miss)
ดังนั้นต้องไปดึงข้อมูลจาก database มา
แล้วทำการสร้างข้อมูลใน caching ขึ้นมาเรื่อย ๆ
โดยรวมแล้วเรื่องของ caching เข้ามาช่วยแก้ไขปัญหาให้
แต่ก็มีข้อเสียเช่นกัน ดังนั้นควรเข้าใจด้วยว่า มีข้อเสียอะไร
จะได้เตรียมการรับมือไว้
การแก้ไขปัญหารูปแบบนี้ จะถูกเรียกว่า แก้ไขปัญหาด้วยการเพิ่มปัญหา (N+1 problem)
สิ่งที่ต้องควรพิจารณาของการนำ caching มาใช้
- การทำงานทั้ง read/write ว่าเป็นอย่างไร
- Storage รวมไปถึง database model ที่ใช้งาน
- การ sync ข้อมูล
- ความเร็วในการทำงาน
- Availability ของระบบ
- การ Scale
- Security
- Operation
มาถึงตรงนี้ น่าจะทำให้เข้าใจเรื่องพื้นฐานของ caching มากขึ้นนะครับ
