Row Store vs Column Store

วิธีจัดเก็บ data บน disk ที่ส่งผลต่อ performance อย่างมาก — เลือกผิดช้าได้ 100 เท่า

Row-Oriented Database (เก่ง OLTP)

1 IO ดึง 1 page = ได้หลาย row พร้อมทุก column

เหมาะ: OLTP — transactional ทั่วไป (e-commerce, banking)
SELECT * FROM emp WHERE id=1 → อ่าน 1 page ได้ row ครบ
ตัวอย่าง: PostgreSQL, MySQL, Oracle, SQL Server

Column-Oriented Database (เก่ง OLAP)

ข้อมูล column เดียวกันเก็บต่อกันบน disk:

salary column file:
  101000:1001, 102000:1002, 103000:1003, ...

name column file:
  John:1001, Kary:1002, Norman:1003, ...

SELECT SUM(salary) FROM emp → อ่านแค่ salary file → IO น้อยมาก
SELECT * FROM emp WHERE id=1 → ต้องอ่านทุก column file → ช้ามาก
เหมาะ: OLAP — data warehouse, analytics, BI
ตัวอย่าง: ClickHouse, Apache Druid, Vertica, Redshift, BigQuery, Snowflake

เปรียบเทียบ

ด้าน	Row Store	Column Store
เหมาะกับ	OLTP (transactional)	OLAP (analytics)
Point query	เร็ว	ช้า
Aggregation	ช้า (อ่านทุก column)	เร็วมาก (อ่านเฉพาะ column)
INSERT 1 row	เร็ว (เขียน 1 page)	ช้า (เขียนทุก column file)
Compression	ปานกลาง	ดีมาก (data ประเภทเดียวกัน compress ดี)

Pitfalls

ใช้ column store ทำ OLTP → Insert 1 row ต้อง write ทุก column file = ช้ามาก
ใช้ row store ทำ analytics aggregation บน billion rows → ช้ามาก

Modern Pattern: HTAP (Hybrid)

เก็บ OLTP ใน PostgreSQL + replicate ไป ClickHouse สำหรับ analytics — ได้ดีทั้ง 2 โลก

Key Points

Row store = OLTP, point queries, INSERT เร็ว
Column store = OLAP, aggregation, analytics เร็วมาก
เลือกผิดประสิทธิภาพช้าได้ 100 เท่า
HTAP = Postgres (OLTP) + ClickHouse (OLAP) ได้ดีทั้งคู่

Database Engines — B-Tree vs LSM-Tree เป็นอีกมิติ
PostgreSQL — row store, OLTP
Database Indexing — index ทำงานต่างกันใน row vs column store