OLTP vs OLAP: เข้าใจประเภทของ Database, Row vs Column Storage และวิธีเลือกใช้

OLTP vs OLAP คือการแบ่งประเภทที่ควรเข้าใจก่อนเลือก database ระบบ OLTP (online transaction processing) รับ transaction เล็ก ๆ สั้น ๆ ที่ไหลเข้ามาตลอดเวลา แต่ละตัวแตะข้อมูลไม่กี่ row เช่น การสั่งซื้อสินค้าหรือการถอนเงิน ส่วนระบบ OLAP (online analytical processing) รัน query จำนวนน้อยกว่าแต่ใหญ่กว่ามาก สแกนข้อมูลเป็นล้าน row เพื่อตอบคำถามอย่าง "รายได้แยกตามภูมิภาคในแต่ละเดือน" สองงานนี้ต้องการ storage คนละแบบแทบจะตรงข้ามกัน บริษัทส่วนใหญ่จึงลงเอยด้วยการมีทั้งสองอย่าง

บทความนี้เริ่มจากจัดกลุ่มตระกูล database หลัก ๆ (relational, object-relational, object-oriented และ NoSQL) แล้วเปรียบเทียบ OLTP กับ OLAP พร้อมระบบและเครื่องมือจริง อธิบาย storage แบบ row-oriented และ column-oriented ที่อยู่เบื้องหลัง และปิดท้ายด้วยวิธีเลือก database ที่ใช้ได้จริง

ภาพรวมตระกูลของ database

ก่อนจะถามเรื่อง workload ต้องถามเรื่อง data model ก่อน ว่า database แทนข้อมูลของเราในรูปแบบไหน

Relational (RDBMS)

ข้อมูลอยู่ในตารางที่มี schema ตายตัว ความสัมพันธ์แสดงด้วย key และ join ความถูกต้องควบคุมด้วย constraint relational database ให้ ACID transaction, query optimizer ที่พัฒนามานาน และเครื่องมือที่สะสมมาหลายสิบปี สำหรับแอปธุรกิจตัวใหม่ relational database คือตัวเลือกตั้งต้น ถ้าไม่มีเหตุผลชัดเจนให้เลือกอย่างอื่น

Object-relational (ORDBMS)

Object-relational database คือ relational database ที่เข้าใจ type ที่ซับซ้อนขึ้นด้วย ตัวอย่างที่รู้จักกันดีที่สุดคือ PostgreSQL ซึ่งสร้าง composite type ได้ เก็บ array และ jsonb ได้ และเพิ่ม data type หรือ index method ใหม่ผ่าน extension อย่าง PostGIS ได้:

CREATE TYPE address AS (street text, city text, postcode text);

CREATE TABLE stores (
    id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name  text NOT NULL,
    addr  address,
    tags  text[],
    attrs jsonb
);

SELECT name, (addr).city
FROM stores
WHERE '24h' = ANY (tags)
  AND attrs @> '{"parking": true}';

ในทางปฏิบัติเส้นแบ่งระหว่าง RDBMS กับ ORDBMS จางลงมากแล้ว ทั้ง MySQL, SQL Server และ Oracle ต่างก็รองรับ JSON ในปัจจุบัน ป้ายชื่อจึงสำคัญน้อยกว่าการดูว่ามีฟีเจอร์ที่เราต้องใช้จริงหรือไม่

Object-oriented (OODBMS)

Object database เก็บ object ของแอปตามที่เป็นอยู่ รวมทั้ง reference ระหว่าง object โดยไม่ต้อง map ลงตาราง ตัวอย่างคือ ObjectDB (สำหรับ Java) และ GemStone/S (สำหรับ Smalltalk) เคยมี db4o ด้วย แต่เลิกพัฒนาไปแล้ว OODBMS ยังเป็นตลาดเฉพาะกลุ่ม เพราะ ORM ที่ทำงานบน relational database เข้ามาแทนงานส่วนใหญ่ และ relational database ก็ query แบบ ad-hoc ได้ดีกว่าและมีเครื่องมือมากกว่า

NoSQL

NoSQL ครอบคลุมหลาย model ที่ต่างกัน:

• Document (MongoDB, CouchDB): เอกสารคล้าย JSON ที่โครงสร้างยืดหยุ่น เหมาะเมื่อแต่ละ record เป็นเอกสารที่สมบูรณ์ในตัวเองอยู่แล้ว
• Key-value (Redis, Amazon DynamoDB): get และ set ด้วย key เร็วมาก นิยมใช้ทำ cache, session และตัวนับ ดูเพิ่มในRedis caching, data structure และ persistence
• Wide-column (Apache Cassandra, ScyllaDB): row ถูกกระจายไปหลาย node ออกแบบมาเพื่อรับการเขียนปริมาณมากและเข้าถึงด้วย partition key
• Graph (Neo4j): node และ relationship เป็นข้อมูลหลัก เหมาะกับ query ที่ต้องเดินหลาย hop ดูการปรับ graph workload ให้เร็วขึ้น

ระบบ NoSQL มักแลกการรับประกันบางอย่างของ relational เช่น transaction ข้ามหลาย row, join หรือ schema ที่เข้มงวด กับ scale หรือความยืดหยุ่น ปัจจุบันหลายตัวรองรับ transaction ได้ในขอบเขตจำกัด จึงควรตรวจสอบจาก product ที่จะใช้จริง อย่าเดาเอา

OLTP vs OLAP: ความต่างที่เป็นแก่น

นอกจาก data model แล้ว workload ก็เป็นตัวกำหนดสำคัญว่าต้องใช้ database แบบไหน

ระบบ OLTP

OLTP คือ database ที่อยู่เบื้องหลังตู้ ATM, ระบบจองตั๋ว, หน้า checkout ของร้านออนไลน์ หรือระบบธนาคาร ทุก action คือ transaction สั้น ๆ:

BEGIN;
INSERT INTO orders (customer_id, amount, created_at)
VALUES ('C01', 500.00, now());
UPDATE inventory SET stock = stock - 1
WHERE sku = 'TSHIRT-M' AND stock > 0;
COMMIT;

สิ่งที่สำคัญคือความถูกต้องเมื่อมีงานพร้อมกันจำนวนมาก และ latency ที่ต่ำสม่ำเสมอ ลูกค้าสองคนต้องซื้อเสื้อตัวสุดท้ายพร้อมกันไม่ได้ และการโอนเงินต้องไม่เกิดแค่ครึ่งเดียว การรับประกันเหล่านี้มาจาก ACID transaction ซึ่งอธิบายผ่านตัวอย่างการโอนเงินไว้ในACID และ MVCC ฉบับเข้าใจง่าย query ของ OLTP หา row ผ่าน index บน key การออกแบบ index ที่ดีจึงสำคัญกว่าความเร็วในการ scan มาก

ระบบ OLAP

OLAP คือ data warehouse ที่อยู่เบื้องหลัง dashboard ผู้บริหาร รายงานยอดขายรายเดือนแยกตามภูมิภาค หรือการวิเคราะห์พฤติกรรมลูกค้า query ทั่วไปจะอ่านข้อมูลย้อนหลังก้อนใหญ่แล้ว aggregate:

SELECT date_trunc('month', s.sold_at) AS month,
       c.region,
       sum(s.amount)                  AS revenue
FROM fact_sales s
JOIN dim_customer c ON c.customer_key = s.customer_key
WHERE s.sold_at >= date '2026-01-01'
GROUP BY 1, 2
ORDER BY 1, 2;

Schema สำหรับงานวิเคราะห์มักเป็น star schema คือมี fact table ขนาดใหญ่ที่เก็บเหตุการณ์ (ยอดขาย, คลิก, การชำระเงิน) ล้อมรอบด้วย dimension table ที่เล็กกว่า (ลูกค้า, สินค้า, วันที่) ยอมให้ข้อมูลซ้ำซ้อนได้ เพราะทำให้ query ง่ายและเร็วขึ้น

เทคโนโลยี OLAP ที่พบบ่อย:

• Cloud warehouse: Google BigQuery, Snowflake, Amazon Redshift
• Real-time analytical database: ClickHouse, Apache Druid, Apache Pinot สำหรับ dashboard บนข้อมูล event ที่สด
• Embedded analytics: DuckDB สำหรับวิเคราะห์ไฟล์และ dataset บนเครื่องเดียว
• OLAP cube: Microsoft SQL Server Analysis Services ซึ่ง pre-aggregate ข้อมูลเป็น model หลายมิติให้เครื่องมือ BI ใช้

Storage แบบ row-oriented vs column-oriented

ความต่างเชิงเทคนิคที่ใหญ่ที่สุดระหว่าง database แบบ OLTP กับ OLAP คือวิธีจัดวางข้อมูลบน disk ลองดูตาราง sales(order_id, customer_id, amount, created_at)

Database แบบ row-oriented เก็บค่าของแต่ละ row ไว้ติดกัน:

page 1: [101, C01, 500, 2026-04-01] [102, C02, 700, 2026-04-01] [103, C01, 200, 2026-04-02] ...

Database แบบ column-oriented เก็บค่าของแต่ละคอลัมน์ไว้ติดกัน:

order_id:    101, 102, 103, ...
customer_id: C01, C02, C01, ...
amount:      500, 700, 200, ...
created_at:  2026-04-01, 2026-04-01, 2026-04-02, ...

Row storage เหมาะกับ OLTP การเพิ่มคำสั่งซื้อหนึ่งรายการ การแก้สถานะลูกค้าหนึ่งคน หรือการดึง order 102 ตาม id ล้วนอ่านหรือเขียน row เดียว และ row นั้นอยู่ในที่เดียวกัน PostgreSQL, MySQL และ database แบบ transactional ส่วนใหญ่ทำงานแบบนี้ ถ้าอยากเห็นว่า row ถูกอัดลง page ขนาด 8KB อย่างไร ดูPostgreSQL storage internals

Column storage เหมาะกับ OLAP SELECT sum(amount) FROM sales WHERE created_at >= ... ต้องใช้แค่สองคอลัมน์ column store จะอ่านเฉพาะ amount กับ created_at แล้วข้ามที่เหลือ ถ้าตารางมี 50 คอลัมน์ นั่นอาจหมายถึงอ่านข้อมูลเพียงส่วนเล็ก ๆ ของทั้งหมด ค่าในคอลัมน์เดียวกันยังเป็น type เดียวกันและมักซ้ำกัน จึงบีบอัดได้ดีมากด้วยเทคนิคอย่าง dictionary encoding และ run-length encoding engine แบบ column หลายตัวยังประมวลผลค่าเป็นชุด (vectorized execution) ซึ่งใช้ CPU ได้คุ้มค่า

ฝั่งการเขียนกลับตรงกันข้าม การ insert หรือ update row เดียวใน column store ต้องแตะ storage ของทุกคอลัมน์ ระบบพวกนี้จึงชอบการ load ข้อมูลเป็น batch ใหญ่ ๆ มากกว่า

ย้ายข้อมูลจาก OLTP ไป OLAP

องค์กรส่วนใหญ่ไม่ได้เลือกแค่อย่างเดียว database แบบ OLTP ใช้รันแอป แล้ว copy ข้อมูลไปยังระบบ OLAP เพื่อวิเคราะห์:

1. Batch ETL หรือ ELT job ที่ตั้งเวลาไว้ดึง row ที่เปลี่ยน load เข้า warehouse แล้ว transform ที่นั่น เรียบง่าย แต่ข้อมูลช้าเป็นชั่วโมง
2. Change data capture (CDC) เครื่องมืออย่าง Debezium อ่าน change log ของ database (WAL ของ PostgreSQL, binlog ของ MySQL) แล้ว stream ทุกการเปลี่ยนแปลง มักผ่าน Kafka เข้า warehouse ภายในไม่กี่วินาทีถึงไม่กี่นาที
3. Read replica ถ้างานวิเคราะห์ไม่ใหญ่มาก ให้รันรายงานบน replica เพื่อไม่ให้ query หนัก ๆ ถ่วง primary

หัวใจคือต้องกัน query วิเคราะห์หนัก ๆ ออกจาก primary ของ OLTP รายงานยาว ๆ แค่ตัวเดียวก็แย่ง CPU และ I/O กับ traffic ของหน้า checkout ได้

Database ตัวเดียวทำได้ทั้งสองอย่างไหม?

ได้ในระดับหนึ่ง PostgreSQL รองรับงานวิเคราะห์ขนาดกลางได้ดีถ้าเราช่วยมันหน่อย:

-- BRIN index: tiny, effective on append-only time columns
CREATE INDEX orders_created_brin ON orders USING brin (created_at);

-- pre-aggregate a heavy report
CREATE MATERIALIZED VIEW monthly_revenue AS
SELECT date_trunc('month', o.created_at) AS month,
       c.region,
       sum(o.amount) AS revenue
FROM orders o
JOIN customers c ON c.id = o.customer_id
GROUP BY 1, 2;

CREATE UNIQUE INDEX ON monthly_revenue (month, region);
REFRESH MATERIALIZED VIEW CONCURRENTLY monthly_revenue;

การทำ partition ตามวันที่ parallel query และ extension ที่เพิ่ม columnar storage ช่วยดันขีดจำกัดนี้ออกไปได้อีก นอกจากนี้ยังมี database ที่เรียกว่า HTAP (hybrid transactional/analytical processing) เช่น TiDB และ SingleStore ที่เก็บข้อมูลทั้งแบบ row และ column ไว้ในระบบเดียว

แต่เมื่อข้อมูลหรือความซับซ้อนของ query โตถึงจุดหนึ่ง การใช้ระบบ OLAP แยกต่างหากจะง่ายและถูกกว่าการฝืนยืด database ของ OLTP

วิธีเลือก database

ถามคำถามเหล่านี้ตามลำดับ:

1. Workload เป็นแบบไหน? transaction เล็ก ๆ จำนวนมาก (OLTP), scan และ aggregate ก้อนใหญ่ (OLAP) หรือทั้งคู่
2. ข้อมูลมีรูปร่างอย่างไร? ตารางที่มีความสัมพันธ์ชี้ไปทาง relational ส่วนเอกสารที่สมบูรณ์ในตัว, การ lookup ด้วย key หรือ graph ที่ลึก อาจชี้ไปทาง NoSQL ตระกูลใดตระกูลหนึ่ง
3. ต้องถูกต้องเข้มงวดแค่ไหน? เงิน สต็อกสินค้า และการจอง ต้องใช้ ACID transaction ข้ามหลาย row
4. ต้องการ scale เท่าไรจริง ๆ? PostgreSQL เครื่องเดียวที่จูนดี ๆ รับงานได้มากกว่าที่แอปส่วนใหญ่จะต้องใช้ อย่าออกแบบเผื่อ traffic ที่ยังไม่มี
5. ทีมดูแลอะไรไหว? backup, upgrade, monitoring และ failover สำคัญพอ ๆ กับฟีเจอร์

สำหรับ product ใหม่ส่วนใหญ่ ค่าตั้งต้นที่สมเหตุสมผลคือ relational OLTP database อย่าง PostgreSQL ใช้ Redis ทำ cache ถ้าจำเป็น แล้วค่อยเพิ่ม warehouse หรือ ClickHouse เมื่องานวิเคราะห์โตเกินกว่าที่ read replica จะรับไหว

คำถามที่พบบ่อย

OLTP กับ OLAP ต่างกันอย่างไร?

OLTP รัน transaction เล็กและเร็วจำนวนมากที่อ่านเขียนไม่กี่ row และเป็นตัวขับเคลื่อนแอป ส่วน OLAP รัน query ขนาดใหญ่จำนวนน้อยกว่าที่ scan และ aggregate ข้อมูลย้อนหลังจำนวนมาก และใช้สำหรับรายงานและการวิเคราะห์

PostgreSQL เป็น OLTP หรือ OLAP?

PostgreSQL เป็น database แบบ OLTP เป็นหลัก ใช้ storage แบบ row-oriented รองรับงานวิเคราะห์ขนาดกลางได้ด้วย index, partitioning, materialized view และ parallel query แต่ column store ที่ทำมาเฉพาะจะเร็วกว่าสำหรับงานวิเคราะห์ขนาดใหญ่

Data warehouse เป็น OLAP หรือไม่?

ใช่ data warehouse คือระบบ OLAP ที่พบบ่อยที่สุด มันเก็บข้อมูลย้อนหลังที่รวบรวมมาจาก database ของระบบงานต่าง ๆ และจัดรูปแบบไว้เพื่อการวิเคราะห์ ไม่ใช่เพื่อ transaction

ทำไม column-oriented database ถึงเร็วกว่าสำหรับงานวิเคราะห์?

เพราะอ่านเฉพาะคอลัมน์ที่ query ต้องใช้ บีบอัดค่าที่คล้ายกันได้ดี และประมวลผลค่าเป็นชุด query วิเคราะห์มักแตะไม่กี่คอลัมน์แต่หลาย row ซึ่งเป็นกรณีที่ column storage ถูกออกแบบมาให้ทำได้ดี

PostgreSQL เป็น object-relational database หรือไม่?

ใช่ PostgreSQL มักถูกเรียกว่า object-relational database เพราะรองรับ custom type และ composite type, array, table inheritance และขยาย data type กับ index ได้

Checklist สั้น ๆ สำหรับการตัดสินใจ

• เริ่มจาก workload ก่อน: transaction, การวิเคราะห์ หรือทั้งคู่
• ใช้ relational OLTP database เป็นแกนหลักของแอป เว้นแต่มีเหตุผลที่ชัดเจน
• ย้ายงานวิเคราะห์ออกจาก primary: เริ่มจาก read replica แล้วค่อยเป็น warehouse ที่รับข้อมูลผ่าน ETL หรือ CDC
• เลือก column-oriented storage สำหรับ scan และ aggregate ก้อนใหญ่ และ row-oriented storage สำหรับการอ่านเขียน row เดียวบ่อย ๆ
• เลือก NoSQL เพราะรูปแบบการเข้าถึงที่มันทำได้ดี ไม่ใช่เลือกโดยอัตโนมัติ

ถ้ากำลังชั่งน้ำหนักตัวเลือกเหล่านี้สำหรับระบบจริง Vectorkub ช่วยออกแบบ data architecture ได้