WW warin.me

DATA SYSTEMS · INTERACTIVE LAB

เมื่อข้อมูลโต การอ่านเฉพาะคอลัมน์และข้ามส่วนที่ไม่เกี่ยวข้องสำคัญกว่าการอ่านให้เร็วขึ้นเฉย ๆ

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

Checking isolated teaching runtimes…
ROWS10K
100K
1Mone deterministic sales model

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

column layout, sort order และ inserted block ลดงานที่ต้องทำซ้ำอย่างไร

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

  1. เลือก 100,000 แถว แล้วรัน Raw columnar aggregate เป็น baseline ของ ClickHouse
  2. รัน Column pruning ตรวจว่า query ขออ่านคอลัมน์น้อยลง แม้ logical dataset ยังเป็นชุดเดิม
  3. รัน Data skipping แล้วดูขอบเขตแถวที่อ่าน เชื่อมผลกับ sort order และช่วงข้อมูลที่ค้นหาได้
  4. รัน Stored aggregate states สังเกตว่า ClickHouse merge state ที่เตรียมไว้ แทนการ scan event ต้นทางทุกแถว
  5. รัน Insert through incremental MV โดย event ใหม่ 1 รายการจะเข้ามาเป็น block และ materialized-view pipeline จะแปลงเฉพาะ inserted block เป็น aggregate state
runtime นี้สาธิตอะไรจริง

ClickHouse incremental MV คือ transformation ที่ทำงานเมื่อ insert ไม่ใช่ PostgreSQL pg_ivm และไม่ใช่ snapshot ที่ refresh ทั้งชุด

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

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

CONCEPT

Read fewer columns, then skip more ranges.

MergeTree stores columns independently and organizes parts by an ORDER BY key. A predicate aligned with that key can skip marks and parts; an incremental materialized view transforms each arriving insert block into reusable aggregate state.

inserted block→MergeTree pipeline→aggregate states

BOUNDED EXPERIMENT

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.

Incremental does not mean identical

MergeTree order

The ORDER BY expression is a physical promise. It shapes sparse indexes and locality; it is not merely presentation order. Queries misaligned with it may still scan widely.

Aggregate states

AggregatingMergeTree stores mergeable states such as sumState. Reads finalize them with sumMerge. Background merges may combine parts later, so queries must preserve correct merge semantics.

Inserted blocks

The materialized view sees newly inserted blocks. It does not automatically notice arbitrary historical mutations in the way a full PostgreSQL REFRESH rereads the source. That distinction is the lesson.