ClickHouse: ออกแบบตาราง event log เพื่อวิเคราะห์ด้วย SQL

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

เริ่มจากคีย์ที่ใช้กรอง

ตาราง MergeTree เป็นจุดเริ่มต้นที่เอกสาร ClickHouse แนะนำสำหรับตารางทั่วไปบนเครื่องเดียว ORDER BY ในการสร้างตารางไม่ใช่ลำดับแสดงผลของทุก query แต่เป็นคีย์จัดเรียงข้อมูลบนดิสก์ ซึ่งมีผลต่อการอ่านช่วงข้อมูล ตัวอย่างนี้มักกรองตามบริการและเวลา:

CREATE TABLE http_events
(
    event_time DateTime,
    service LowCardinality(String),
    status UInt16,
    duration_ms UInt32
)
ENGINE = MergeTree
ORDER BY (service, event_time);

ลองใส่ข้อมูลทดสอบจำนวนเล็กก่อน:

INSERT INTO http_events VALUES
('2026-10-01 10:00:00', 'checkout', 200, 41),
('2026-10-01 10:01:00', 'checkout', 500, 930);

SELECT service, count() AS requests, countIf(status >= 500) AS errors
FROM http_events
WHERE service = 'checkout'
  AND event_time >= '2026-10-01 00:00:00'
GROUP BY service;

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

ทดลองให้ตอบโจทย์ production

1. เก็บ query ที่ทีมใช้จริงอย่างน้อยสามแบบ เช่น นับข้อผิดพลาดรายบริการ p95 latency รายชั่วโมง และเจาะเหตุการณ์ตามช่วงเวลา
2. สร้างตารางทดลองด้วยชุดข้อมูลหลายวัน ไม่ใช่เฉพาะหนึ่งชั่วโมง เพื่อดูว่า ORDER BY ช่วยตัวกรองตามเวลาที่ต้องใช้จริงหรือไม่
3. ส่งข้อมูลเป็นชุดตามแนวทาง ingestion ของระบบ แล้ววัดจำนวน parts, เวลา insert และ latency ของ query พร้อมกัน
4. ดูแผน query และจำนวนแถวที่อ่านก่อนปรับ schema จากนั้นเทียบผลกับฐานข้อมูลต้นทางเพื่อยืนยันว่าตัวเลขตรงกัน
5. ตั้งนโยบาย retention การสำรอง และสิทธิ์อ่านข้อมูล ก่อนเปิดให้ dashboard หรือผู้ใช้หลายกลุ่มเรียกตรง

ข้อควรระวัง

ClickHouse เน้นการอ่านเชิงวิเคราะห์และการเพิ่มข้อมูลเป็นหลัก การแก้แถวเดี่ยวบ่อย ๆ ไม่ใช่จุดที่ควรย้ายมาทั้งหมดจาก OLTP อีกทั้ง ORDER BY ที่เลือกตาม query เดียวอาจทำให้ query อื่นอ่านข้อมูลมากขึ้น จึงควรทดสอบกับ workload จริงและทบทวนเมื่อรูปแบบการใช้งานเปลี่ยน อย่าใช้การนับ event เป็นตัวแทนจำนวนผู้ใช้โดยไม่แยก retry, duplicate และ bot ให้ชัด

อ่านเพิ่มเติม: การสร้างตาราง ClickHouse, MergeTree, แนวทาง ingestion