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

ชุมชนนักพัฒนาซอฟต์แวร์กำลังมีส่วนร่วมในการอภิปรายอย่างเข้มข้นเกี่ยวกับว่าฐานข้อมูลแบบดั้งเดิมสามารถทดแทนบริการแคชเฉพาะทาง เช่น Redis หรือ Valkey ได้อย่างมีประสิทธิภาพหรือไม่ การถกเถียงนี้มีจุดศูนย์กลางอยู่ที่คำถามพื้นฐานของสถาปัตยกรรมระบบ: นักพัฒนาควรเพิ่มความซับซ้อนอีกชั้นหนึ่งด้วยบริการแคช หรือฐานข้อมูลสมัยใหม่สามารถจัดการกับข้อกำหนดด้านประสิทธิภาพได้เองแล้ว

การสนทนานี้เกิดขึ้นจากข้อเสนอให้ใช้ read replicas ของฐานข้อมูลเป็นตัวทดแทนแคช โดยใช้ประโยชน์จากฟีเจอร์ต่างๆ เช่น buffer pools และ materialized views อย่างไรก็ตาม การตอบสนองของชุมชนเผยให้เห็นความแตกแยกทางปรัชญาอย่างลึกซึ้งเกี่ยวกับเวลาและวิธีการที่ควรนำแคชมาใช้ในระบบซอฟต์แวร์

มุมมองที่มองแคชเป็นแผ่นปิดแผล

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

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

Buffer pools คือพื้นที่หน่วยความจำที่ฐานข้อมูลใช้เก็บหน้าข้อมูลที่เข้าถึงบ่อยเพื่อลด I/O operations ของดิสก์

การป้องกันการแคชแบบปฏิบัติจริง

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

กลุ่มนี้เน้นว่าการแคชสามารถมองเป็นชั้นข้อมูลอีกชั้นหนึ่ง มากกว่าที่จะเป็นแค่เทคนิคด้านประสิทธิภาพ พวกเขาสนับสนุนการปฏิบัติต่อข้อมูลที่แคชไว้เป็นชุดข้อมูลที่ได้มา (derived datasets) ที่มีข้อกำหนดความสอดคล้องที่ชัดเจน คล้ายกับวิธีที่ธุรกิจจัดการกับรูปแบบอื่นๆ ของสแนปช็อตข้อมูล เช่น รายงานที่ส่งทางอีเมลหรือแดชบอร์ดเป็นระยะ

กลุ่มปฏิบัติจริงยังเน้นว่าระบบสมัยใหม่มักต้องจัดการกับข้อจำกัดด้านการคำนวณที่ทำให้การแคชในรูปแบบใดรูปแบบหนึ่งเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ไม่ว่าจะนำมาใช้เป็นบริการเฉพาะหรือสร้างเข้าไปในฟีเจอร์ฐานข้อมูล เช่น materialized views

Materialized views คือออบเจ็กต์ฐานข้อมูลที่เก็บผลลัพธ์ของคิวรีแบบฟิสิคัล ต่างจาก views ปกติที่คำนวณตามต้องการ

อุปสรรคทางเทคนิคของโซลูชันที่ใช้เฉพาะฐานข้อมูล

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

นักพัฒนายังสังเกตว่าฐานข้อมูลส่วนใหญ่ไม่รองรับ partial replication อย่างมีประสิทธิภาพ หมายความว่าคุณต้องจำลองชุดข้อมูลทั้งหมดแม้ว่าจะมีเพียงส่วนย่อยเล็กๆ ที่เข้าถึงบ่อย สิ่งนี้สร้างการสูญเสียทรัพยากรและค่าใช้จ่ายในการดำเนินงานที่แคชเฉพาะทางหลีกเลี่ยงได้

นอกจากนี้ ชุมชนยังชี้ให้เห็นว่าฐานข้อมูลโดยทั่วไปไม่สามารถจัดลำดับความสำคัญของแถวเฉพาะเพื่อเก็บไว้ใน buffer pools หรือให้นโยบายการขับไล่ที่ยืดหยุ่นเหมือนที่บริการแคชเสนอ

Incremental View Maintenance (IVM) คือเทคนิคที่อัปเดต materialized views แบบเพิ่มหน่วยเมื่อข้อมูลพื้นฐานเปลี่ยนแปลง แทนที่จะคำนวณ view ทั้งหมดใหม่

ข้อจำกัดทางเทคนิคที่ป้องกันไม่ให้ฐานข้อมูลแทนที่ Database Cache

• การจำลองแบบบางส่วน: ฐานข้อมูลส่วนใหญ่ต้องการการจำลองข้อมูลทั้งหมดแทนที่จะเป็นการจำลองเฉพาะส่วนย่อย
• ความสามารถในการขยายการเชื่อมต่อ: ฐานข้อมูลโดยทั่วไปไม่สามารถจัดการการเชื่อมต่อพร้อมกันหลายแสนรายการได้
• การควบคุมลำดับความสำคัญของหน่วยความจำ: ไม่มีความสามารถในการกำหนดลำดับความสำคัญให้กับแถวข้อมูลเฉพาะใน buffer pools
• นโยบายการขับไล่: ขาดความยืดหยุ่นใน TTL และกลยุทธ์การขับไล่ที่มีอยู่ใน dedicated caches
• การคำนวณล่วงหน้า: ความสามารถที่จำกัดในการเก็บผลลัพธ์ของการ join และการคำนวณที่ซับซ้อน
• ความหน่วงของเครือข่าย: Read replicas ยังคงต้องการการเรียกผ่านเครือข่าย ซึ่งแตกต่างจากโซลูชันฐานข้อมูลแบบ embedded

การแลกเปลี่ยนความซับซ้อนในการดำเนินงาน

บางทีข้อโต้แย้งที่น่าสนใจที่สุดในการถกเถียงนี้มีจุดศูนย์กลางอยู่ที่ความซับซ้อนในการดำเนินงาน แม้ว่าการเพิ่มชั้นแคชจะเพิ่มบริการอีกหนึ่งรายการที่ต้องจัดการ แต่มันสามารถทำให้บางแง่มุมของการบำรุงรักษาระบบและการแก้ไขข้อบกพร่องง่ายขึ้นได้

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

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

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

การเปรียบเทียบประสิทธิภาพระหว่าง Cache และ Database

ทิศทางอนาคตและโซลูชันที่เกิดขึ้นใหม่

การอภิปรายเน้นเทคโนโลยีที่เกิดขึ้นใหม่หลายรายการที่อาจเชื่อมช่องว่างระหว่างฐานข้อมูลและแคช ระบบ Incremental View Maintenance เช่น Noria (ปัจจุบันคือ ReadySet ) แสดงให้เห็นแนวโน้มที่ดีในการให้ประสิทธิภาพเหมือนแคชพร้อมการรับประกันความสอดคล้องเหมือนฐานข้อมูล

นักพัฒนาบางคนกำลังสำรวจสถาปัตยกรรม event-sourcing และระบบ disaggregated storage ที่สามารถให้ประโยชน์ของทั้งสองแนวทาง คนอื่นๆ ชี้ไปที่ฐานข้อมูลเฉพาะทางที่ออกแบบมาสำหรับ high-concurrency read workloads เป็นโซลูชันที่เป็นไปได้

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

อ้างอิง: Replacing a cache service with a database