การอพิจารณาล่าสุดในชุมชนนักพัฒนาได้เน้นย้ำถึงข้อจำกัดที่สำคัญของ materialized views ของ PostgreSQL ทำให้เกิดการถกเถียงเกี่ยวกับความจำเป็นในการมี incremental view maintenance แบบอัตโนมัติอย่างแท้จริงในฐานข้อมูล การสนทนานี้มุ่งเน้นไปที่ช่องว่างระหว่างสิ่งที่นักพัฒนาคาดหวังจาก materialized views และสิ่งที่การใช้งานจริงในปัจจุบันสามารถให้ได้
ปัญหาการรีเฟรชแบบแมนนวลของ PostgreSQL
ปัญหาหลักของ materialized views ของ PostgreSQL คือต้องการการรีเฟรชแบบแมนนวลโดยใช้คำสั่ง REFRESH MATERIALIZED VIEW ซึ่งแตกต่างจากเวอร์ชันในอุดมคติที่อธิบายไว้ในบทเรียนหลายๆ เรื่อง views เหล่านี้ไม่ได้ซิงโครไนซ์กับข้อมูลพื้นฐานโดยอัตโนมัติ ทำให้มันเหมือนกับกลไกการแคชที่ซับซ้อนมากกว่าโซลูชันที่อัปเดตอยู่เสมอแบบวิเศษที่นักพัฒนาหลายคนหวังไว้
สถานการณ์จะยิ่งมีปัญหามากขึ้นเมื่อต้องจัดการกับชุดข้อมูลขนาดใหญ่ การรีเฟรช materialized view ใน PostgreSQL ต้องการการสร้าง view ใหม่ทั้งหมด ซึ่งอาจใช้ทรัพยากรมากและอาจรบกวนระบบที่ใช้งานจริง วิธีการแบบทั้งหมดหรือไม่เลยนี้หมายความว่าคุณไม่สามารถอัปเดตเฉพาะส่วนของ view ได้ ทำให้เกิดคอขวดด้านประสิทธิภาพที่อาจเกิดขึ้น
ส่วนขยาย PostgreSQL สำหรับ Incremental Views
- pg_ivm: ส่วนขยายจากบุคคลที่สามที่เพิ่มการบำรุงรักษา incremental view ให้กับ PostgreSQL
- ไม่สามารถใช้งานได้บน Amazon RDS
- ให้การอัปเดตอัตโนมัติแต่ต้องติดตั้งและกำหนดค่าด้วยตนเอง
โซลูชันจากบุคคลที่สามเติมเต็มช่องว่าง
บริษัทหลายแห่งได้เกิดขึ้นเพื่อแก้ไขข้อจำกัดนี้ โดยเสนอความสามารถ incremental view maintenance แบบแท้จริง Materialize, ReadySet, Feldera, RisingWave และ DeltaStream เป็นสตาร์ตอัพที่ให้โซลูชันที่สามารถซิงโครไนซ์ materialized views กับข้อมูลต้นทางโดยอัตโนมัติ แพลตฟอร์มเหล่านี้ใช้เทคนิคเช่น differential dataflow และ incremental view maintenance เพื่อให้ได้สิ่งที่ฐานข้อมูลแบบดั้งเดิมต้องดิ้นรนกับมัน
Materialized views ใน ScyllaDB เป็นที่รู้จัก (หรือเคย?) ว่าเป็นการใช้งานที่มีบั๊ก โดยเฉพาะอย่างยิ่ง มันมักจะขึ้นอยู่กับการที่คลัสเตอร์มีสุขภาพดีในขณะที่เผยแพร่การเปลี่ยนแปลง
บริษัทที่เสนอบริการ Incremental View Maintenance
- Materialize: ฐานข้อมูล streaming เฉพาะทางที่มีการอัปเดตมุมมองอัตโนมัติ
- ReadySet: ชั้น SQL caching ที่มี incremental maintenance
- Feldera: แพลตฟอร์มที่ใช้ DBSP มีความซับซ้อนในการอัปเดต O(1)
- RisingWave: ฐานข้อมูล streaming สำหรับการวิเคราะห์แบบเรียลไทม์
- DeltaStream: การประมวลผล stream ที่มี materialized views
- Confluent: แพลตฟอร์ม streaming ที่ใช้ Kafka มีความสามารถด้าน view
ผู้จำหน่ายฐานข้อมูลกำลังไล่ตาม
ในขณะที่ PostgreSQL ล้าหลัง ระบบฐานข้อมูลอื่นๆ เสนอการใช้งาน materialized views ที่ดีกว่า Microsoft SQL Server ให้ indexed views ที่อัปเดตแบบซิงโครนัสกับตารางพื้นฐาน แม้ว่าจะมีผลกระทบต่อประสิทธิภาพระหว่างการดำเนินการเขียน Oracle เสนอตัวเลือกการสร้างใหม่แบบเต็มและแบบเพิ่มทีละน้อย โดยเวอร์ชันล่าสุดเพิ่มความสามารถในการรีเฟรชแบบพร้อมกัน
ผู้ให้บริการคลาวด์ก็กำลังก้าวหน้าในพื้นที่นี้เช่นกัน Materialized views ของ BigQuery อนุญาตให้ปรับแต่งพารามิเตอร์ความสดใหม่และสามารถเขียนคิวรีใหม่โดยอัตโนมัติเพื่อใช้การรวมที่คำนวณล่วงหน้า อย่างไรก็ตาม ฟีเจอร์ขั้นสูงเหล่านี้มักมาพร้อมกับการพิจารณา vendor lock-in
การเปรียบเทียบฐานข้อมูลสำหรับ Materialized Views
| ฐานข้อมูล | อัปเดตอัตโนมัติ | รีเฟรชแบบเพิ่มหน่วย | พร้อมใช้งานจริง |
|---|---|---|---|
| PostgreSQL | ไม่มี | ใช้ Extension เท่านั้น | ใช่ |
| MySQL | ไม่มี | ไม่มี | ใช่ |
| SQL Server | ใช่ (Indexed Views) | ใช่ | ใช่ |
| Oracle | เลือกได้ | ใช่ | ใช่ |
| BigQuery | ใช่ | ใช่ | ใช่ |
| ScyllaDB | ใช่ (มีบั๊ก) | ใช่ | จำกัด |
การแลกเปลี่ยนระหว่างประสิทธิภาพและความซับซ้อน
การอภิปรายเผยให้เห็นความตึงเครียดพื้นฐานในการออกแบบฐานข้อมูล คิวรีการนับแบบง่ายที่ทำงานได้อย่างสมบูรณ์แบบกับการจัดทำดัชนีที่เหมาะสมมักถูกออกแบบให้ซับซ้อนเกินไปเป็นโซลูชันการแคชที่ซับซ้อน นักพัฒนาหลายคนชี้ให้เห็นว่าสำหรับกรณีการใช้งานทั่วไปที่เกี่ยวข้องกับหลายพันมากกว่าหลายล้านเรคคอร์ด คิวรี COUNT(*) ที่มีดัชนีที่ดีทำงานได้อย่างเพียงพอโดยไม่มีความซับซ้อนของ materialized views
คุณค่าที่แท้จริงของ materialized views เกิดขึ้นกับคิวรีการวิเคราะห์ที่ซับซ้อนมากขึ้นที่เกี่ยวข้องกับการรวมหลายตาราง การรวมข้อมูล และการแปลงข้อมูล สถานการณ์เหล่านี้ได้รับประโยชน์อย่างมากจากผลลัพธ์ที่คำนวณล่วงหน้า โดยเฉพาะในแอปพลิเคชันคลังข้อมูลและการรายงาน
การพัฒนาอย่างต่อเนื่องในพื้นที่นี้แสดงให้เห็นว่า automatic incremental view maintenance น่าจะกลายเป็นฟีเจอร์มาตรฐานในระบบฐานข้อมูลในอนาคต จนกว่าจะถึงเวลานั้น นักพัฒนาต้องชั่งน้ำหนักการแลกเปลี่ยนระหว่างประสิทธิภาพคิวรี ความสดใหม่ของข้อมูล และความซับซ้อนของระบบอย่างรอบคอบเมื่อเลือกวิธีการจัดการข้อมูลที่ได้มา