ClickHouse — เอนจินวิเคราะห์ข้อมูลแบบเรียลไทม์ในสแตกของแพลตฟอร์ม
สแตกของ 4buildsite มี ClickHouse — ฐานข้อมูลแบบคอลัมน์ที่สร้างมาเพื่อการวิเคราะห์ข้อมูลปริมาณมากโดยเฉพาะ เป็นฐานที่เรากำลังใช้สร้างโมดูลสถิติทราฟฟิกและยอดขายของแพลตฟอร์ม (อยู่ระหว่างพัฒนา): ข้อมูลยังเป็นของคุณ การเก็บข้อมูลและการรายงานแยกจากการเสิร์ฟเว็บไซต์ — นี่คือแนวทางที่ออกแบบสถาปัตยกรรมไว้
ClickHouse คืออะไร และทำไมเราจึงใช้
ClickHouse เป็นฐานข้อมูล OLAP (การวิเคราะห์ออนไลน์) แบบคอลัมน์ ที่สร้างขึ้นที่ Yandex สำหรับ Yandex.Metrica ซึ่งเป็นหนึ่งในระบบวิเคราะห์เว็บที่ใหญ่ที่สุดในโลก และเปิดเป็นโอเพนซอร์สในปี 2016 ภายใต้สัญญาอนุญาต Apache 2.0 มันถูกสร้างมาเพื่อสิ่งเดียวและทำได้ยอดเยี่ยม คือการรวมผลข้อมูลปริมาณมหาศาลอย่างรวดเร็ว ในสถาปัตยกรรมของ 4buildsite ClickHouse คือเอนจินที่เลือกใช้กับชั้นสถิติ: ทุกการเข้าชม การคลิก และคำสั่งซื้อจะกลายเป็นอีเวนต์ที่วิเคราะห์ได้
ความลับอยู่ที่การจัดเก็บแบบคอลัมน์: แทนที่จะอ่านทุก “แถว” แบบเต็ม ClickHouse อ่านเฉพาะคอลัมน์ที่รายงานต้องใช้ และประมวลผลเป็นบล็อกขนาดใหญ่แบบเวกเตอร์ ด้วยเหตุนี้คำถามอย่าง “เมื่อวานมีผู้เข้าชมกี่คน แยกตามหน้า แยกตามแหล่งที่มา” จึงประมวลผลได้โดยไม่ต้องอ่านทุกแถวของตาราง แม้กับอีเวนต์หลายล้านรายการ ซึ่งฐานข้อมูลแบบแถวทั่วไปทำได้ยาก
นี่ไม่ใช่เทคโนโลยีเฉพาะกลุ่ม: Cloudflare ใช้วิเคราะห์ทราฟฟิก HTTP ในระดับทั่วโลก ส่วน Uber, eBay และ Spotify ใช้เพื่อการวิเคราะห์และประมวลผลล็อกในปริมาณมหาศาล บน 4buildsite เอนจินเดียวกันนี้เป็นส่วนหนึ่งของสแตกของแพลตฟอร์ม โดยคุณไม่ต้องจ้างทีมวิศวกรข้อมูล
สถิติแบบเรียลไทม์ — โมดูลนี้ออกแบบอย่างไร
โมดูลสถิติของแพลตฟอร์มอยู่ระหว่างพัฒนา และสถาปัตยกรรมของมันเรียบง่าย: อีเวนต์ทราฟฟิกถูกเก็บแบบอะซิงโครนัสและเขียนลง ClickHouse แยกออกจากเซิร์ฟเวอร์ที่ส่งหน้าเว็บของคุณโดยสิ้นเชิง การรายงานทำงานบนระบบแยกต่างหาก ไม่มีสคริปต์ติดตามของบุคคลที่สามที่หนัก — การเก็บข้อมูลมีขนาดเล็กและเป็น first-party
รายงานใน panel.4buildsite.net จะถูกคำนวณโดยตรงใน ClickHouse: ทราฟฟิกของแต่ละหน้า แหล่งที่มาของผู้เข้าชม คอนเวอร์ชัน ยอดขายต่อสินค้า การรวมผลที่ใช้บ่อยจะถูกคำนวณล่วงหน้าผ่าน materialized view ทุกครั้งที่เขียนข้อมูล แดชบอร์ดจึงใช้ผลที่คำนวณไว้แล้ว — ไม่ต้องเริ่มคำนวณหนัก ๆ ทุกครั้งที่คุณเปิดดู
- ทราฟฟิก: การเข้าชม หน้า แหล่งที่มา และอุปกรณ์ — สืบค้นได้หลังเก็บข้อมูลแล้ว
- ยอดขายต่อสินค้า คำสั่งซื้อ และคอนเวอร์ชันของร้านค้า รวมผลจากข้อมูลที่เก็บไว้
- ประวัติย้อนหลังหลายเดือนหลายปีด้วยต้นทุนต่ำ — การบีบอัดแบบคอลัมน์ลดพื้นที่จัดเก็บได้หลายเท่าเมื่อเทียบกับข้อมูลดิบ
- การเก็บข้อมูลเป็นแบบอะซิงโครนัส ส่วนการรายงานทำงานบนระบบแยกต่างหาก
PostgreSQL + ClickHouse: ทำไมเราจึงใช้ทั้งสอง
สแตกของแพลตฟอร์มรวมฐานข้อมูลสองตัวเพราะทั้งสองทำหน้าที่ต่างกันโดยพื้นฐาน PostgreSQL คือบัญชีธุรกรรม (OLTP): คำสั่งซื้อ การชำระเงิน สต็อก บัญชีผู้ใช้ — การดำเนินการที่ต้องถูกต้องสมบูรณ์ทีละรายการพร้อมการรับประกันระดับธุรกรรม ส่วน ClickHouse คือห้องวิเคราะห์ (OLAP): อ่านอีเวนต์หลายล้านรายการพร้อมกันเพื่อตอบคำถามเรื่องทราฟฟิกและยอดขายของคุณ
หากรายงานหนัก ๆ รันบนฐานข้อมูลเดียวกับที่ประมวลผลคำสั่งซื้อ ทุกรายงานก็จะแย่งทรัพยากรกับลูกค้าที่กำลังชำระเงินในขณะนั้น การแยก OLTP/OLAP ช่วยลดความขัดแย้งนี้: รายงานทำงานบนระบบของตัวเอง จึงลดการแย่งทรัพยากรกับคำสั่งซื้อที่กำลังประมวลผล แต่ละเอนจินทำสิ่งที่มันถูกสร้างมาให้ทำ
- PostgreSQL: คำสั่งซื้อ การชำระเงินผ่าน Stripe สต็อก ลูกค้า — ความถูกต้องของธุรกรรม
- ClickHouse: อีเวนต์ทราฟฟิก รายงาน สถิติ — การรวมผลในปริมาณมาก
- การออกแบบจะทำสำเนาข้อมูลธุรกรรมที่เกี่ยวข้องไปยัง ClickHouse ในรูปอีเวนต์ รายงานยอดขายจึงไม่แตะฐานข้อมูลที่ให้บริการร้านค้าของคุณ
การวิเคราะห์แบบ first-party ที่เป็นมิตรกับความเป็นส่วนตัว — แทน Google Analytics
หลักการของโมดูลสถิติ: ข้อมูลของเว็บไซต์คุณอยู่บนโครงสร้างพื้นฐานของแพลตฟอร์ม ไม่ถูกส่งไปยัง Google หรือเครือข่ายโฆษณาอื่น ไม่ถูกขาย และไม่ถูกรวมกับโปรไฟล์ผู้ใช้ภายนอก นี่คือการวิเคราะห์แบบ first-party ตามความหมายตรงตัว: ข้อมูลเกี่ยวกับผู้เข้าชมของคุณเป็นของคุณ
เนื่องจากแนวทางนี้ไม่ใช้คุกกี้ติดตามของบุคคลที่สาม การปฏิบัติตาม GDPR จึงง่ายขึ้นมาก บริบทสำคัญ: ในปี 2022 หน่วยงานคุ้มครองข้อมูลของออสเตรีย ฝรั่งเศส และอิตาลีประกาศว่าการใช้ Google Analytics ไม่สอดคล้องกับ GDPR เนื่องจากการถ่ายโอนข้อมูลไปยังสหรัฐฯ ด้วยการวิเคราะห์แบบ first-party ที่โฮสต์ในยุโรป ความเสี่ยงประเภทนี้จึงไม่เกี่ยวข้องกับการวิเคราะห์แบบนี้ตั้งแต่ต้น
ยังมีประโยชน์เชิงปฏิบัติโดยตรงอีกอย่าง: รายงานที่คำนวณใน ClickHouse ไม่ผ่านการสุ่มตัวอย่าง ตัวเลขครบถ้วนจากข้อมูลที่เก็บไว้แล้ว
รายงานร้านค้าและมาร์เก็ตเพลซ — สิ่งที่โมดูลจะมอบให้
สำหรับร้านค้าออนไลน์ ClickHouse จะหมายถึงคำตอบต่อคำถามที่สำคัญ: สินค้าใดขายได้ แหล่งที่มาใดนำลูกค้าที่ซื้อจริงมา ตะกร้าถูกทิ้งที่ไหน สำหรับมาร์เก็ตเพลซหลายผู้ขาย การรวมผลแบบเดียวกันจะรันกับคำสั่งซื้อทั้งหมด: ปริมาณต่อผู้ขาย ค่าคอมมิชชัน สินค้าขายดีตามหมวด — ไม่ต้องส่งออกด้วยมือและไม่ต้องใช้สเปรดชีต
และเมื่อขยายขนาด การบีบอัดแบบคอลัมน์ลดขนาดข้อมูลได้หลายเท่าเมื่อเทียบกับรูปแบบดิบ คุณจึงเก็บประวัติหลายปีได้ด้วยต้นทุนการจัดเก็บต่ำ เมื่อทราฟฟิกเพิ่มจากหลักพันเป็นหลักล้านอีเวนต์ การรวมผลก็ยังทำได้ในระดับที่ใช้งานได้จริง — เอนจินนี้ออกแบบมาสำหรับข้อมูลหลายพันล้านแถวตั้งแต่ต้น ไม่ได้มาดัดแปลงทีหลัง
ข้อดีและข้อจำกัด
ข้อดี
- รวมผลข้อมูลหลายล้านอีเวนต์ — รายงานอ่านจากผลที่คำนวณไว้ล่วงหน้า
- การวิเคราะห์ทำงานบนระบบแยกจากระบบที่ส่งหน้าเว็บ
- ข้อมูลทราฟฟิกยังเป็นของคุณ อยู่บนโครงสร้างพื้นฐานของแพลตฟอร์ม — ไม่ถ่ายโอนไปยัง Google หรือเครือข่ายโฆษณา
- ไม่มีคุกกี้ติดตามของบุคคลที่สาม — ปฏิบัติตาม GDPR ได้ง่ายขึ้น
- การบีบอัดแบบคอลัมน์ที่แข็งแกร่ง — เก็บประวัติหลายปีด้วยต้นทุนจัดเก็บต่ำ
- โอเพนซอร์ส (Apache 2.0) ไม่มีค่าลิขสิทธิ์ตามปริมาณ — ต้นทุนไม่พุ่งเมื่อทราฟฟิกโต
ข้อจำกัด
- ไม่ใช่ฐานข้อมูลธุรกรรม — การอัปเดตหรือลบทีละแถวเป็นงานหนัก จึงเก็บคำสั่งซื้อและการชำระเงินไว้ใน PostgreSQL
- ปรับให้เหมาะกับการเขียนเป็นก้อนขนาดใหญ่ การแทรกข้อมูลเล็ก ๆ บ่อย ๆ ต้องรวมเป็นแบตช์ — แพลตฟอร์มจัดการให้ แต่เป็นข้อจำกัดจริงของเอนจิน
- JOIN ที่ซับซ้อนยืดหยุ่นน้อยกว่าใน PostgreSQL — ต้องออกแบบสคีมาอีเวนต์เพื่อการวิเคราะห์ตั้งแต่เริ่ม
- การค้นหาแถวเดียว (point lookup) ช้ากว่าในฐานข้อมูล OLTP ที่มีดัชนี — จึงไม่ใช่ฐานข้อมูลหลักแทนของร้านค้า
สรุปสั้น ๆ
ClickHouse เป็นตัวเลือกที่เหมาะสำหรับการวิเคราะห์ข้อมูลปริมาณมาก: สถิติทราฟฟิกและยอดขายด้วยข้อมูลของคุณเอง โดยแยกจากการเสิร์ฟเว็บไซต์ ส่วนคำสั่งซื้อ การชำระเงิน และสต็อกยังอยู่กับ PostgreSQL — ด้วยเหตุนี้สแตกของ 4buildsite จึงรวมทั้งสอง โดยแต่ละตัวทำสิ่งที่ถนัดที่สุด โมดูลสถิติที่สร้างบน ClickHouse อยู่ระหว่างพัฒนา
ตารางสเปก
| ความสามารถ | ขีดจำกัด / เกณฑ์ | การใช้งานทั่วไป | |
|---|---|---|---|
| การรวมผลเชิงวิเคราะห์ | รวมผลได้โดยไม่ต้องอ่านทุกแถว แม้กับอีเวนต์หลายล้านรายการ (แบบคอลัมน์ + เวกเตอร์) | ช้าเมื่อค้นหาทีละแถว — ไม่เหมาะกับการอ่านแบบ point read ของ OLTP | รายงานทราฟฟิกและยอดขาย (โมดูลสถิติ อยู่ระหว่างพัฒนา) |
| การรับอีเวนต์เข้า | ปริมาณสูง เขียนเป็นแบตช์ | การแทรกเล็ก ๆ บ่อย ๆ ต้องใช้แบตช์ / async insert | เก็บ pageview การคลิก คำสั่งซื้อ |
| การจัดเก็บและการบีบอัด | การบีบอัดแบบคอลัมน์ (LZ4/ZSTD) เล็กกว่าปริมาณดิบหลายเท่า | ข้อมูลสุ่มสูงบีบอัดได้น้อยกว่า | ประวัติอีเวนต์หลายเดือนหลายปี ด้วยต้นทุนต่ำ |
| การอัปเดตและการลบ | mutation แบบอะซิงโครนัสสำหรับการแก้ไขเป็นครั้งคราว | ไม่เหมาะกับ UPDATE ทีละแถวบ่อย ๆ | การลบตาม GDPR (ข้อมูลของผู้ใช้หนึ่งราย ตามคำขอ) |
| Materialized view | คำนวณผลรวมล่วงหน้าทุกครั้งที่เขียน | ต้องนิยามผลรวมไว้ล่วงหน้าต่อรายงาน | แดชบอร์ดจากผลที่คำนวณไว้: ยอดขายต่อวัน สินค้า แหล่งที่มา |
| เรียลไทม์ | อีเวนต์สืบค้นได้หลังจากบันทึกแล้ว | ไม่ใช่ระบบสตรีมมิงระดับมิลลิวินาที | สถิติทราฟฟิกและคอนเวอร์ชัน |
ClickHouse เทียบกับ PostgreSQL เทียบกับ Google Analytics / BigQuery — สำหรับการวิเคราะห์
| เกณฑ์ | ClickHouse (4buildsite) | PostgreSQL (สำหรับการวิเคราะห์) | Google Analytics / BigQuery |
|---|---|---|---|
| ความเร็วการรวมผลเมื่อข้อมูลมาก | รวมผลได้โดยอ่านเฉพาะคอลัมน์ที่ต้องใช้ แม้กับหลายล้านแถว | ช้าลงชัดเจนเมื่อถึงหลายสิบล้านแถว (จัดเก็บแบบแถว) | BigQuery เร็ว ส่วน GA4 มีรายงานมาตรฐานที่รวมผลไว้ก่อน ไม่มีการสืบค้นแบบอิสระ |
| ความเป็นเจ้าของข้อมูล / GDPR | ข้อมูลของคุณ บนโครงสร้างพื้นฐานของแพลตฟอร์มในยุโรป | ข้อมูลของคุณ บนเซิร์ฟเวอร์ของคุณ | ข้อมูลอยู่ที่ Google; หน่วยงานของ EU ตัดสินในปี 2022 ว่าการถ่ายโอนของ GA ไปสหรัฐฯ ไม่สอดคล้องกับ GDPR |
| คุกกี้และการขอความยินยอม | ไม่มีคุกกี้ติดตามของบุคคลที่สาม | ขึ้นอยู่กับการพัฒนาของคุณเอง | ต้องมีแบนเนอร์ขอความยินยอมสำหรับการติดตาม |
| เรียลไทม์ | สืบค้นข้อมูลได้หลังบันทึกแล้ว | ทำได้ แต่รายงานหนักจะทำให้ฐานข้อมูลธุรกรรมรับภาระ | รายงานมาตรฐานของ GA4 อาจล่าช้าเป็นชั่วโมง; BigQuery streaming มีค่าใช้จ่ายเพิ่ม |
| ต้นทุนเมื่อข้อมูลมาก | โอเพนซอร์ส — ต้นทุนมีแค่โครงสร้างพื้นฐาน รวมอยู่ในค่าสมาชิกแล้ว | เพิ่มตามดัชนี vacuum และฮาร์ดแวร์เมื่อข้อมูลมาก | BigQuery คิดตามปริมาณที่สืบค้น; ระดับ enterprise ของ GA มีราคาสูง |
| ผลต่อความเร็วเว็บไซต์ | น้อยมาก — เก็บข้อมูลแบบ async รายงานอยู่บนระบบแยก | รายงานอาจแย่งทรัพยากรกับคำสั่งซื้อบนฐานข้อมูลเดียวกัน | สคริปต์ของบุคคลที่สาม (gtag.js) บนหน้าเว็บ — JavaScript และคำขอภายนอกเพิ่มขึ้น |
คำถามที่พบบ่อย
ClickHouse ทำให้เว็บไซต์หรือร้านค้าของฉันช้าลงไหม
สถาปัตยกรรมออกแบบให้ ClickHouse ทำงานบนระบบแยกจากระบบที่ส่งหน้าเว็บของคุณ อีเวนต์ทราฟฟิกถูกส่งแบบอะซิงโครนัส และรายงานไม่แตะฐานข้อมูลของร้านค้า
ทำไมไม่ใช้ Google Analytics ล่ะ
มีสามเหตุผล ข้อมูลยังเป็นของคุณ อยู่บนโครงสร้างพื้นฐานของแพลตฟอร์ม ไม่ใช่ที่ Google คุณไม่ต้องใช้คุกกี้ติดตามของบุคคลที่สาม การปฏิบัติตาม GDPR จึงง่ายกว่า — ในปี 2022 หน่วยงานของออสเตรีย ฝรั่งเศส และอิตาลีตัดสินว่า GA ไม่สอดคล้องกับ GDPR และรายงานครบถ้วน ไม่ผ่านการสุ่มตัวอย่าง
ClickHouse ต่างจาก PostgreSQL อย่างไร — ทำไมต้องมีทั้งสอง
PostgreSQL คือฐานข้อมูลธุรกรรม (OLTP): ประมวลผลคำสั่งซื้อ การชำระเงิน และสต็อกทีละรายการพร้อมการรับประกันความถูกต้อง ClickHouse คือฐานข้อมูลเชิงวิเคราะห์ (OLAP): อ่านอีเวนต์หลายล้านรายการพร้อมกันเพื่อทำรายงาน การแยกกันช่วยลดโอกาสที่รายงานหนัก ๆ จะทำให้คำสั่งซื้อของลูกค้าช้าลง
ข้อมูลทราฟฟิกของฉันปลอดภัยและเป็นไปตาม GDPR หรือไม่
สถิติถูกออกแบบให้เป็นแบบ first-party: อยู่บนโครงสร้างพื้นฐานของแพลตฟอร์มในยุโรป และไม่ถูกขายหรือแบ่งปันกับเครือข่ายโฆษณา แนวทางนี้ไม่ใช้คุกกี้ติดตามของบุคคลที่สาม และรองรับการลบข้อมูลของผู้ใช้ตามคำขอตาม GDPR
สถิติเป็น “เรียลไทม์” แค่ไหน
อีเวนต์ — การเข้าชม การคลิก คำสั่งซื้อ — จะปรากฏในรายงานหลังจากถูกบันทึกแล้ว การรวมผลในช่วงเวลายาว (หลายเดือน หลายปี) ก็ทำได้จากข้อมูลที่เก็บไว้ เพราะ ClickHouse ถูกสร้างมาเพื่อการสืบค้นแบบนี้โดยเฉพาะ
ฉันต้องตั้งค่าอะไรเพื่อให้มีสถิติบนเว็บไซต์ไหม
คุณจะไม่ต้องตั้งค่า โมดูลสถิติอยู่ระหว่างพัฒนาและสร้างเป็นส่วนหนึ่งของแพลตฟอร์ม: เมื่อเปิดใช้งานในแผงผู้ดูแล การเก็บข้อมูลจะเริ่มอัตโนมัติสำหรับเว็บไซต์ที่เผยแพร่แล้ว — ไม่ต้องติดตั้งสคริปต์และไม่ต้องมีบัญชีภายนอก