dim_time
PK time_keydate · month · quarter1DATA SYSTEMS · INTERACTIVE LAB
ระบบข้อมูลไม่ได้ต่างกันเพราะชื่อสินค้า แต่ต่างกันเพราะวางการคำนวณไว้คนละตำแหน่ง
คำถามที่มีประโยชน์ไม่ใช่ “ฐานข้อมูลใดชนะ” แต่คือระบบหลีกเลี่ยง เลื่อนเวลา จัดเก็บ หรือทำงานส่วนใดซ้ำ
Checking isolated teaching runtimes…
ROWS10K
100K
1Mone deterministic sales model
100K
1Mone deterministic sales model
สไลด์ประกอบการเรียน · 34 หน้า
From Views to Incremental Analytics
เริ่มจากภาพรวมเชิงแนวคิดก่อนลงมือทำ Lab ตั้งแต่ VIEW, materialization, row กับ column storage, incremental view maintenance ไปจนถึงการเลือกตำแหน่งคำนวณใน modern OLAP
VIEWMaterialized ViewRow vs ColumnIVM · ΔThree Labs
CONCEPTUAL ER DIAGRAM
แบบจำลองทางธุรกิจที่อยู่เบื้องหลังตารางสอนแบบแบน
แต่ละ dimension ใช้อธิบายเหตุการณ์ขายได้หลายรายการ ส่วน Lab ตั้งใจฝัง attribute เหล่านี้ไว้ใน sales เพื่อให้ทั้งสาม engine ได้รับ physical contract เดียวกันที่เคลื่อนย้ายได้ง่าย
dim_product
PK product_keycategory · product1dim_customer
PK customer_idคุณลักษณะลูกค้า1dim_geography
PK geography_keyregion · province1dim_channel
PK channel_keychannel1fact_sales
PK sale_idFK time · product · customerFK geography · channelquantity · unit_price · discountrevenue · cost · profitN
ความสัมพันธ์เชิงแนวคิด · 1:N
สิ่งที่ใช้จริงใน Lab · ตาราง sales แบบ denormalized หนึ่งตาราง
ONE QUESTION · THREE COMPUTATION PLACEMENTS
เลือกขอบเขตการคำนวณ ก่อนเลือกผลิตภัณฑ์
PostgreSQLrows + reusable SQL + stored snapshot
↔DuckDBembedded process + local files
↔ClickHousecolumnar parts + incremental states
สาม LAB · ความต้องการสามแบบ
เริ่มจากงานที่เราต้องการให้ระบบข้อมูลทำ ไม่ใช่เริ่มจากชื่อฐานข้อมูล
01 · TRANSACTIONAL FOUNDATION
PostgreSQL
เราอยากให้ application และหลายทีมใช้ความหมายเดียวกันได้อย่างเชื่อถือได้
- รับอะไร
- แถวข้อมูลที่แก้ไขได้ constraint และธุรกรรมของระบบงาน
- ทดลองอะไร
- VIEW → Materialized View → staleness → REFRESH
- ได้อะไร
- หลักตัดสินใจว่าเมื่อใดควรใช้ตรรกะร่วม และเมื่อใดควรเก็บผลลัพธ์
DuckDB
เราอยากวิเคราะห์ไฟล์ด้วย SQL โดยไม่ต้องดูแล database server เพิ่ม
- รับอะไร
- CSV, Parquet และ process ภายในเครื่องที่ควบคุมขอบเขตได้
- ทดลองอะไร
- pushdown → window → rollup → precompute
- ได้อะไร
- รอยต่อระหว่างรูปแบบไฟล์ ต้นทุนการ scan และผลลัพธ์ที่ใช้ซ้ำได้
ClickHouse
เราอยากให้ aggregation ที่ถามซ้ำยังเร็ว เมื่อปริมาณ event โตขึ้น
- รับอะไร
- event ที่เพิ่มต่อเนื่อง และรูปแบบการอ่านเชิงวิเคราะห์ที่พอคาดได้
- ทดลองอะไร
- MergeTree → column pruning → skipping → incremental MV
- ได้อะไร
- วิจารณญาณด้าน physical design สำหรับลำดับ คอลัมน์ และ incremental state
COMMON DATA CONTRACT
หนึ่ง sales event หนึ่งระดับความละเอียด และหนึ่งความหมาย—นำไปสร้างในสาม engine
การเปรียบเทียบที่เป็นธรรมต้องมากกว่าการตั้งชื่อคอลัมน์ให้คล้ายกัน ทุก engine จึงได้รับความหมายต่อแถว ค่าแบบ deterministic ตัววัด และโจทย์วิเคราะห์เดียวกัน โดยเปลี่ยนชนิดจัดเก็บเฉพาะส่วนที่ต้องใช้ native type ของ engine นั้น
ตารางข้อเท็จจริงsalesหนึ่งแถว = เหตุการณ์ขายที่เสร็จสมบูรณ์หนึ่งครั้ง
รหัสระบุหลักsale_idระบุ event ไม่ซ้ำ โดย PostgreSQL บังคับด้วย PK
เวลาของเหตุการณ์sale_timestampเวลาธุรกิจที่ใช้สร้างยอดสรุปรายวัน
ขนาดข้อมูลทดลอง10K · 100K · 1Mกฎการสร้างเดียวกันในทุกระดับที่จำกัดไว้
ตัวระบุและเวลา
sale_id · BIGINT / UInt64sale_timestamp · TIMESTAMP / DateTimeมิติสำหรับอธิบาย
region · provincecategory · productchannel · customer_idค่าตั้งต้นระดับรายการ
quantity · unit_price · discountตัววัดที่คำนวณแล้ว
revenue · cost · profitความหมายคงที่
region, category และ channel มีความหมายเดียวกันทุก Lab จึงไม่ทำให้ผลเร็วขึ้นด้วยการแอบเปลี่ยนโจทย์
ภาระงานที่เทียบกันได้
baseline เดียวกันจัดกลุ่มตาม region และ category แล้วคำนวณจำนวนรายการกับรายได้ จากนั้นจึงใช้การทดลองเฉพาะ engine เพื่อเห็นจุดแข็งจริง
ข้อมูลสังเคราะห์ที่ควบคุมได้
ไม่ใช้ข้อมูลนักศึกษาหรือ production สูตร deterministic ทำให้ reset แล้วสร้างซ้ำได้
schema นี้ตั้งใจให้กระชับเพื่อการสอน ไม่ใช่ enterprise model ฉบับเต็ม ในระบบจริง customer, product และ geography มักแยกเป็น dimension ที่มีการกำกับประวัติ คุณภาพ และความเป็นส่วนตัวอย่างชัดเจน
MASTER COMPARISON
แต่ละแบบทำให้อะไรถูกลง และเรียกร้องให้เราดูแลอะไรเพิ่ม
| System | Computation location | Physical reuse | Freshness model | Best teaching question |
|---|---|---|---|---|
| PostgreSQL | database server | materialized rows | explicit refresh | logic vs stored result |
| DuckDB | web process | Parquet + local table | file/table replacement | serverless analytical scan |
| ClickHouse | isolated OLAP server | sorted column parts + aggregate states | new inserted blocks | layout and incremental work |