DATA SYSTEMS · INTERACTIVE LAB

VIEW เก็บตรรกะ ส่วน Materialized View เก็บผลลัพธ์ — ความต่างเล็ก ๆ ที่เปลี่ยนต้นทุนทั้งระบบ

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

Checking isolated teaching runtimes…

ROWS10K
100K
1Mone deterministic sales model

เริ่มจากคำถามเดียว

การใช้ SQL ร่วมกัน หมายถึงใช้ผลการคำนวณร่วมกันด้วยหรือไม่

ลำดับที่แนะนำ

Track A · เลือก 100,000 แถว แล้วรัน Raw aggregate บันทึกผลลัพธ์และ observed latency ไว้เป็น baseline
คงขนาด 100,000 แถวไว้ รัน Logical VIEW แล้วตามด้วย Stored Materialized View สังเกตว่าแบบแรกใช้ SQL ซ้ำ ส่วนแบบหลังใช้แถวที่คำนวณเก็บไว้ซ้ำ
รัน Insert without refresh เปรียบเทียบ base table กับ snapshot เพื่อดูความเก่า แล้วรัน Full REFRESH ให้ snapshot กลับมาตรงกับข้อมูลปัจจุบัน
Track B · เลือก experiment ที่ขึ้นต้นด้วย IVM หน้าเว็บจะสลับไป dataset แยกของ pg_ivm ขนาด 10,000 แถวอัตโนมัติ ไม่ได้นำ IVM ไปต่อท้ายข้อมูล 100,000 แถวก่อนหน้า
รัน Read pg_ivm IMMV แล้วตามด้วย Insert + incremental maintenance ระบบจะเพิ่ม sale event ใหม่ 1 แถว และ pg_ivm จะปรับเฉพาะ aggregate group ของ วัน–region–category ที่ได้รับผล
รัน IVM delta vs full REFRESH แล้วเทียบขอบเขตงาน: IVM ดูแล delta/group ที่กระทบ ส่วน REFRESH ต้องอ่าน base table ของ IVM ครบทั้ง 10,000 แถว

TRACK A100,000 rows

ชุด PostgreSQL หลัก: Raw → VIEW → Materialized View → ดูข้อมูลเก่า → full refresh

TRACK B · IVM10,000 + 1 rows

ชุด pg_ivm แยก: เริ่มจาก 10,000 แถว แล้วเพิ่ม event ใหม่ 1 แถว พร้อมดูแลเฉพาะ aggregate group ที่กระทบ

แล้วข้อมูล 100,000 แถวหายไปไหน? ไม่มีการเพิ่มหรือลบจาก dataset ของ Track A การเลือก IVM คือการเปลี่ยนไปใช้ห้องทดลองย่อยอีกชุดหนึ่ง เครื่องหมาย “+1” หมายถึงเพิ่ม sale ใหม่ใน IVM base table จาก 10,000 เป็น 10,001 แถว ไม่ใช่จาก 100,000 เป็น 100,001 แถว

runtime นี้สาธิตอะไรจริง

Lab นี้ใช้ runtime แยก PostgreSQL 17 + pg_ivm 1.14 โดยไม่แก้ไขฐาน PostgreSQL ของ MADlib

อ่านค่าระยะเวลาอย่างระมัดระวัง

ค่าที่แสดงคือ observed lab latency ไม่ใช่ benchmark สากลของฐานข้อมูล PostgreSQL ใช้ connection ที่เปิดค้างผ่าน PDO, DuckDB ต้องเริ่ม subprocess ในแต่ละ request ส่วน ClickHouse ติดต่อผ่าน HTTP และรายงาน engine elapsed time ของตนเอง อีกทั้งข้อมูลเพียง 10K–1M แถวมักอยู่ใน cache ได้มาก จึงควรเทียบ query plan จำนวนแถวและ byte ที่อ่าน ความสดของข้อมูล และต้นทุนการดูแล ก่อนเปรียบเทียบ millisecond

CONCEPT

Logical interface or physical answer?

A normal VIEW saves a query definition. It improves consistency and governance, but usually repeats the underlying computation. A materialized view stores rows produced by that query. The read becomes smaller; freshness becomes your responsibility.

base rows→VIEW definition→stored snapshot

BOUNDED EXPERIMENT

Dataset size

Whitelist only · 25 s timeout · 2 CPU / 2 GB ClickHouse ceiling · one operation at a time

—execution time

—rows scanned

—bytes read

—rows returned

SQL

Select a bounded experiment.

Result

No result yet.

Explain / query plan

The physical plan appears after execution.

What happened?

Run an experiment, then connect the measurement to physical work.

View, materialization and the cost of being current

VIEW

Use it as a named data contract: centralize joins, calculations, masking and business meaning. It is excellent at preventing every team from rewriting the same logic differently. It is not automatically a cache.

Materialized View

Use it when the repeated transformation is expensive and a controlled freshness lag is acceptable. Reads become predictable because they touch summarized rows, but refresh consumes compute and may need orchestration.

pg_ivm · IMMV

The isolated PostgreSQL 17 runtime uses pg_ivm 1.14. Its IMMV is updated inside the same transaction as changes to the base table. The lab contrasts this write-time delta maintenance with a full snapshot REFRESH at 1,000 and 10,000 rows.