SQL Academy · บทเรียน

OLTP เทียบกับ OLAP

ฐานข้อมูลเชิงธุรกรรมเทียบกับฐานข้อมูลเชิงวิเคราะห์

OLTP เทียบกับ OLAP เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน

OLTP และ OLAP คืออะไร

ฐานข้อมูลไม่ได้เหมาะกับงานทุกประเภทเหมือนกัน ภาระงานสองรูปแบบที่แตกต่างกันโดยพื้นฐานมีอิทธิพลต่อวิธีที่เราออกแบบและดำเนินงานฐานข้อมูล ได้แก่ OLTP (การประมวลผลธุรกรรมออนไลน์) และ OLAP (การประมวลผลเชิงวิเคราะห์ออนไลน์)

การทำความเข้าใจความแตกต่างนี้มีความสำคัญต่อผู้เชี่ยวชาญด้านข้อมูลทุกคน การเลือกระหว่าง OLTP กับ OLAP อย่างเหมาะสมจะเป็นตัวกำหนดความเร็วของคำสืบค้น ค่าใช้จ่ายในการจัดเก็บข้อมูล และสถาปัตยกรรมโดยรวมของระบบข้อมูล

OLTP: สร้างมาเพื่อธุรกรรม

ระบบ OLTP จัดการการดำเนินการจำนวนมากที่สั้นและรวดเร็ว เช่น การแทรก การปรับปรุง และการลบข้อมูล ซึ่งสะท้อนเหตุการณ์ทางธุรกิจแบบทันที ตัวอย่างเช่น การสั่งซื้อ การประมวลผลการชำระเงิน หรือการปรับปรุงระเบียนลูกค้า

คุณสมบัติสำคัญของ OLTP ได้แก่ เวลาแฝงต่ำต่อการดำเนินการ การทำงานพร้อมกันจำนวนมาก และความสอดคล้องของข้อมูลที่เข้มงวด ทุกธุรกรรมต้องเป็นไปตามข้อกำหนดของ ACID เพื่อปกป้องความถูกต้องสมบูรณ์ของข้อมูล

-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);

-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;

OLAP: สร้างมาเพื่อการวิเคราะห์

ระบบ OLAP ได้รับการปรับให้เหมาะกับคำสืบค้นที่ซับซ้อน ซึ่งสแกนข้อมูลในอดีตปริมาณมากเพื่อค้นหาแนวโน้ม รูปแบบ และข้อมูลสรุป นักวิเคราะห์ธุรกิจและนักวิทยาศาสตร์ข้อมูลใช้ OLAP เพื่อตอบคำถาม เช่น “ไตรมาสที่แล้ว เรามียอดขายรวมในแต่ละภูมิภาคเท่าใด”

คำสืบค้นของ OLAP มักรวมข้อมูลหลายล้านแถวและมีการเชื่อมตารางหลายครั้งระหว่างตารางข้อเท็จจริงกับตารางมิติ ความเร็วในการเขียนข้อมูลแต่ละครั้งมีความสำคัญรองลงมา สิ่งที่สำคัญคือปริมาณงานอ่านและความยืดหยุ่นของคำสืบค้น

-- OLAP example: total sales by region for Q1 2024
SELECT
    d.region,
    SUM(f.sales_amount) AS total_sales,
    COUNT(f.order_id)   AS order_count
FROM fact_sales f
JOIN dim_date   dd ON f.date_key   = dd.date_key
JOIN dim_store  d  ON f.store_key  = d.store_key
WHERE dd.year = 2024
  AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;

เปรียบเทียบทั้งสองระบบโดยตรง

วิธีจำความแตกต่างนี้ที่ง่ายที่สุดคือพิจารณาว่า ใครใช้แต่ละระบบ และ ใช้งานอย่างไร:

OLTP: ใช้โดยระบบส่วนหลังของแอปพลิเคชัน มีผู้ใช้หลายพันคนทำงานพร้อมกัน และแต่ละคำสืบค้นเข้าถึงเพียงไม่กี่แถว
OLAP: ใช้โดยนักวิเคราะห์และเครื่องมือจัดทำรายงาน มีคำสืบค้นพร้อมกันน้อยกว่า แต่แต่ละคำสืบค้นจะสแกนหลายล้านแถว

รูปแบบการเข้าถึงที่แตกต่างกันนี้นำไปสู่การออกแบบโครงสร้างฐานข้อมูล กลยุทธ์การสร้างดัชนี และแม้แต่การเลือกฮาร์ดแวร์ที่แตกต่างกันอย่างมาก

-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;

-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
    DATE_TRUNC('month', order_date) AS month,
    SUM(total_amount)               AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

การออกแบบสคีมา: แบบนอร์มัลไลซ์เทียบกับแบบดีนอร์มัลไลซ์

ฐานข้อมูล OLTP มักเลือกใช้ สคีมาแบบนอร์มัลไลซ์ (3NF หรือสูงกว่า) เพื่อขจัดข้อมูลซ้ำซ้อนและทำให้การเขียนมีประสิทธิภาพ เอนทิตีแต่ละรายการอยู่ในตารางของตนเอง จึงลดปริมาณข้อมูลที่ต้องแตะต้องในแต่ละธุรกรรม

ฐานข้อมูล OLAP มักเลือกใช้ สคีมาแบบดีนอร์มัลไลซ์ — โดยเฉพาะสคีมาแบบดาวและแบบเกล็ดหิมะ — ซึ่งข้อมูลถูกเชื่อมตารางไว้ล่วงหน้าและมีข้อมูลซ้ำซ้อน วิธีนี้ขจัดการเชื่อมตารางที่มีค่าใช้จ่ายสูงขณะสืบค้น และช่วยให้กลไกจัดเก็บข้อมูลแบบคอลัมน์สแกนข้อมูลได้เร็วขึ้น

-- Normalized OLTP design (3NF)
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name        VARCHAR(100),
    email       VARCHAR(150) UNIQUE
);

CREATE TABLE orders (
    order_id    SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    order_date  DATE,
    total       NUMERIC(10,2)
);

-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
    sale_id      BIGINT PRIMARY KEY,
    customer_key INT,
    date_key     INT,
    product_key  INT,
    region       VARCHAR(50),
    category     VARCHAR(50),
    amount       NUMERIC(12,2)
);

กลยุทธ์การทำดัชนีแตกต่างกัน

ระบบ OLTP พึ่งพา ดัชนีแบบต้นไม้ B บนคีย์หลักและคีย์นอกอย่างมาก เพื่อรองรับการค้นหาแถวเดียวอย่างรวดเร็วและการเชื่อมตารางภายในธุรกรรมอย่างมีประสิทธิภาพ

ระบบ OLAP ได้ประโยชน์จาก ดัชนีบิตแมป การจัดเก็บข้อมูลแบบคอลัมน์ และ การแบ่งพาร์ทิชัน การสแกนทั้งคอลัมน์ (เช่น จำนวนเงินจากการขายทั้งหมด) มีประสิทธิภาพกว่ามากเมื่อจัดเก็บข้อมูลแยกตามคอลัมน์แทนที่จะแยกตามแถว

-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
    ON orders (customer_id);

-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
    ON orders (order_date, customer_id);

-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
    PARTITION OF fact_sales
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

การทำงานพร้อมกันและการล็อก

ระบบ OLTP ต้องรองรับการเขียนพร้อมกันหลายพันรายการโดยไม่เกิดความขัดแย้ง ฐานข้อมูลใช้ การล็อกระดับแถว และ MVCC (การควบคุมการทำงานพร้อมกันหลายเวอร์ชัน) เพื่อให้การอ่านไม่ขัดขวางการเขียน และการเขียนก็ไม่ขัดขวางการอ่านเช่นกัน

คำสั่งสืบค้นของ OLAP ส่วนใหญ่เป็นแบบอ่านอย่างเดียว การล็อกจึงไม่ค่อยเป็นปัญหา แต่การสแกนที่ใช้เวลานานอาจใช้ CPU และอินพุต/เอาต์พุตเป็นปริมาณมาก คลังข้อมูลส่วนใหญ่เรียกใช้ OLAP บนระบบแยกต่างหาก ซึ่งเติมข้อมูลด้วย ETL แบบเป็นชุดหรือ CDC (การจับการเปลี่ยนแปลงข้อมูล) จากแหล่ง OLTP

-- OLTP: explicit transaction with row-level lock
BEGIN;

SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;

UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;

COMMIT;

ETL: การเชื่อม OLTP และ OLAP

เนื่องจาก OLTP และ OLAP มีการออกแบบที่เข้ากันไม่ได้ องค์กรจึงใช้ ETL (ดึงข้อมูล แปลงข้อมูล และโหลดข้อมูล) เป็นกระบวนการส่งต่อข้อมูลเพื่อคัดลอกและปรับรูปข้อมูลจากฐานข้อมูลเชิงธุรกรรมไปยังคลังข้อมูลเชิงวิเคราะห์ตามกำหนดเวลา (ทุกคืน ทุกชั่วโมง หรือเกือบเรียลไทม์)

กระบวนการ ETL แปลงแถว OLTP แบบนอร์มัลไลซ์ให้เป็นระเบียนข้อเท็จจริงและมิติแบบดีนอร์มัลไลซ์ พร้อมใช้ตรรกะทางธุรกิจไปด้วย (เช่น การแปลงสกุลเงินและการแบ่งกลุ่มลูกค้า)

-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
    customer_key,
    date_key,
    product_key,
    amount
)
SELECT
    dc.customer_key,
    dd.date_key,
    dp.product_key,
    o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date     dd ON dd.calendar_date       = o.order_date
JOIN dim_product  dp ON dp.source_product_id   = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
  AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);

รูปแบบคำสั่งสืบค้น OLAP ที่พบบ่อย

คำสั่งสืบค้น OLAP แทบทั้งหมดเกี่ยวข้องกับ การรวมค่า (SUM, COUNT, AVG) การจัดกลุ่ม ข้ามหลายมิติ และ การกรอง ตามช่วงวันที่หรือหมวดหมู่ สิ่งเหล่านี้เป็นองค์ประกอบพื้นฐานของแผงควบคุมและรายงานธุรกิจ

ฟังก์ชันหน้าต่างมีประโยชน์อย่างยิ่งกับภาระงาน OLAP เพราะช่วยให้คุณเปรียบเทียบตัวเลขของแต่ละช่วงเวลากับช่วงเวลาก่อนหน้าได้โดยไม่ต้องเชื่อมตารางกับตัวเอง

-- Year-over-year revenue comparison using a window function
SELECT
    dd.year,
    dd.quarter,
    SUM(f.amount)                                          AS revenue,
    LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                             ORDER BY dd.year)             AS prev_year_revenue,
    ROUND(
        100.0 * (SUM(f.amount) -
                 LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                                         ORDER BY dd.year))
        / NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
                                          ORDER BY dd.year), 0)
    , 2)                                                   AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;

HTAP: ทำให้เส้นแบ่งเลือนราง

ระบบสมัยใหม่อย่าง TiDB, SingleStore และ ส่วนขยายแบบคอลัมน์ของ PostgreSQL ใช้ HTAP (การประมวลผลเชิงธุรกรรม/เชิงวิเคราะห์แบบผสม) โดยมีเป้าหมายรองรับภาระงานทั้งสองแบบในกลไกเดียว เพื่อหลีกเลี่ยงความซับซ้อนในการดำเนินงานของการดูแลระบบ OLTP และ OLAP แยกจากกัน

HTAP ทำเช่นนี้โดยจัดเก็บข้อมูลสองรูปแบบพร้อมกัน ได้แก่ ที่เก็บข้อมูลแบบแถวสำหรับการเขียนเชิงธุรกรรม และที่เก็บข้อมูลแบบคอลัมน์สำหรับการอ่านเชิงวิเคราะห์ โดยทำให้ข้อมูลทั้งสองรูปแบบตรงกันโดยอัตโนมัติ

-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
    date_key     INT,
    product_key  INT,
    region       VARCHAR(50),
    amount       NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');

-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;

การเลือกระบบที่เหมาะสม

การตัดสินใจเลือกระหว่าง OLTP กับ OLAP (หรือ HTAP) ขึ้นอยู่กับภาระงานหลักของคุณ:

หากคุณกำลังสร้างแอปพลิเคชันที่บันทึกเหตุการณ์แบบเรียลไทม์ — ให้ใช้ฐานข้อมูล OLTP (PostgreSQL, MySQL, เซิร์ฟเวอร์ SQL)
หากคุณกำลังสร้างชั้นรายงานบนข้อมูลในอดีต — ให้ใช้คลังข้อมูล OLAP (BigQuery, เรดชิฟต์, สโนว์เฟลก, ClickHouse)
หากคุณต้องการทั้งสองแบบและต้องการให้การดำเนินงานเรียบง่าย — ให้พิจารณาตัวเลือก HTAP

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

-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
    relname              AS table_name,
    seq_scan,
    idx_scan,
    n_live_tup           AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;

ตรวจสอบความรู้

ตรวจสอบความเข้าใจของคุณเกี่ยวกับความแตกต่างที่สำคัญระหว่างระบบ OLTP และ OLAP

ทบทวนบทเรียน

ประเด็นสำคัญของ OLTP เทียบกับ OLAP:

OLTP รองรับภาระงานเชิงธุรกรรมแบบเรียลไทม์ ได้แก่ การเขียนระดับแถวที่รวดเร็วและทำงานพร้อมกันได้ พร้อมการรับประกัน ACID
OLAP รองรับภาระงานเชิงวิเคราะห์ ได้แก่ การรวมค่าที่ซับซ้อนบนชุดข้อมูลประวัติขนาดใหญ่ โดยใช้สคีมาแบบดีนอร์มัลไลซ์
การออกแบบสคีมาขึ้นอยู่กับภาระงาน — ใช้แบบนอร์มัลไลซ์ (3NF) สำหรับ OLTP และแบบดาว/เกล็ดหิมะสำหรับ OLAP
กระบวนการ ETL เชื่อมระบบทั้งสองเข้าด้วยกัน โดยโหลดข้อมูล OLTP ที่แปลงแล้วเข้าสู่คลังข้อมูลเชิงวิเคราะห์
ระบบ HTAP พยายามรองรับภาระงานทั้งสองแบบจากกลไกเดียว โดยใช้การจัดเก็บทั้งแบบแถวและแบบคอลัมน์

การเลือกสถาปัตยกรรมที่เหมาะสมตั้งแต่เริ่มต้นช่วยป้องกันการย้ายระบบที่ยุ่งยากในภายหลัง และทำให้มั่นใจได้ว่าคำสั่งสืบค้นจะทำงานได้เร็วตามที่ผู้ใช้คาดหวัง

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

บทเรียน “OLTP เทียบกับ OLAP” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “OLTP เทียบกับ OLAP” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “OLTP เทียบกับ OLAP”

ฐานข้อมูลเชิงธุรกรรมเทียบกับฐานข้อมูลเชิงวิเคราะห์ คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “OLTP เทียบกับ OLAP” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม

ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ SQL Academy