แทนที่ OTel และขยายแพลตฟอร์มสังเกตการณ์ด้วย Wide Events

 (clickhouse.com)
1 คะแนน โดย GN⁺ 2025-06-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LogHouse ขยายจาก 19PiB เป็น ข้อมูลล็อกมากกว่า 100PB ภายใน 1 ปี และเติบโตได้ถึงราว 500 ล้านล้านแถว
  • เนื่องจากข้อจำกัดด้านการประมวลผลข้อมูลและปัญหาความไม่มีประสิทธิภาพของ OpenTelemetry(OTel) จึงเปลี่ยนมาใช้ ไปป์ไลน์แบบปรับแต่งเฉพาะ (SysEx) ที่เหมาะกับระบบหลัก
  • การเปลี่ยนแปลงนี้ทำให้ ปริมาณการประมวลผลอีเวนต์เพิ่มขึ้น 20 เท่า แต่ยังคงใช้ CPU ต่ำกว่า 10%
  • การนำ HyperDX และ ClickStack ของ ClickHouse มาใช้ ช่วยสร้างการผสานรวมระหว่าง UI กับข้อมูล ความยืดหยุ่นด้านสคีมา และสภาพแวดล้อมการสำรวจข้อมูลที่ทรงพลัง
  • ด้วยการใช้โมเดล wide events และ high cardinality จึงสามารถเก็บและวิเคราะห์ทุกอีเวนต์ได้โดยไม่ต้องทำ pre-aggregation

เบื้องหลังและการเปลี่ยนแปลง

  • LogHouse แพลตฟอร์มบันทึกล็อกภายในสำหรับ ClickHouse Cloud เติบโตเป็นระบบขนาดใหญ่ภายใน 1 ปี โดยปริมาณข้อมูลเพิ่มจาก 19PiB เป็นมากกว่า 100PB และจาก 37 ล้านล้านแถวเป็นเกือบ 500 ล้านล้านแถว
  • ในช่วงแรกมีการรวบรวม telemetry ทั้งหมดผ่าน OpenTelemetry(OTel) แต่เมื่ออยู่ในสภาพแวดล้อมข้อมูลขนาดมหาศาล ปัญหาด้านประสิทธิภาพ ข้อจำกัดของทรัพยากร รวมถึง การสิ้นเปลือง CPU และการสูญหายของข้อมูล ระหว่างกระบวนการแปลงข้อมูลก็เริ่มเด่นชัด

ข้อจำกัดของ OTel และเหตุผลที่นำไปป์ไลน์แบบปรับแต่งมาใช้

  • ไปป์ไลน์ของ OTel มีความไม่มีประสิทธิภาพสูงมาก เพราะล็อกถูกแปลงเป็น JSON ก่อน แล้วจึงแมปกลับเป็นฟอร์แมตของ OTel ทำให้เกิดการแปลงและการ marshal ซ้ำหลายรอบ
  • ในทางปฏิบัติ หากต้องประมวลผล 20 ล้านแถวต่อวินาทีด้วย OTel จะต้องใช้ราว 8,000 CPU cores
  • เมื่อทราฟฟิกพุ่งสูง Collector จะโอเวอร์โหลดจนเกิดการดรอปล็อก และทำให้มีข้อมูลบางส่วนถูกรวบรวมไม่ทัน

การนำ SysEx มาใช้และโครงสร้าง

  • SysEx(System Tables Exporter) ย้ายข้อมูลจาก system tables ของ ClickHouse ไปยัง LogHouse โดยตรงในชนิดข้อมูลดั้งเดิมโดยไม่ต้องแปลง
  • ใช้โครงสร้าง distributed scraping ผ่าน hash ring พร้อม time-delay buffer และวิธี sliding window เพื่อป้องกันข้อมูลตกหล่นและให้เป็นไปตาม SLA ภายใน
  • ใช้ภาษา Go และความสามารถแบบคัสตอมของ ClickHouse client เพื่อให้ส่งข้อมูลแบบ byte-to-byte ได้โดยไม่ต้อง marshal ข้อมูล
  • เพื่อรองรับสคีมาที่เปลี่ยนแปลงได้ มีการใช้ schema hash และการจัดการสคีมาแบบไดนามิก พร้อมรวมสคีมาหลายเวอร์ชันให้เป็น logical view เดียวด้วย Merge table engine
  • รองรับการเก็บข้อมูลจาก memory table แบบ snapshot และสนับสนุนงานวินิจฉัยกับการวิเคราะห์ขั้นสูง

การปรับปรุงด้านประสิทธิภาพและประสิทธิผล

  • หลังนำ SysEx มาใช้ OTel Collector ประมวลผลล็อกได้ 2 ล้านรายการต่อวินาทีด้วย CPU 800 ตัว ขณะที่ SysEx ประมวลผลได้ 37 ล้านรายการต่อวินาทีด้วย CPU 70 ตัว
  • ประสิทธิภาพที่เพิ่มขึ้นนี้ช่วยลดการใช้ทรัพยากรลงอย่างมาก ป้องกันการสูญหายของอีเวนต์ และรองรับสภาพแวดล้อมแบบเรียลไทม์ได้

บทบาทต่อเนื่องของ OTel

  • OTel ยังคงสำคัญในฐานะแพลตฟอร์ม มาตรฐานและเป็นกลางต่อผู้ขาย และยังจำเป็นในกรณีที่บริการล่มหรือเกิดสถานะผิดปกติ
  • สามารถจับล็อกได้แม้ในสถานการณ์ crash หรือความผิดปกติที่ SysEx จัดการไม่ได้
  • ปัจจุบันมีการตัดล็อกที่ต่ำกว่าระดับ trace ออก และเก็บเฉพาะระดับ info ขึ้นไปเพื่อเพิ่มประสิทธิภาพการใช้ทรัพยากร

การรวม UI กับ HyperDX และ ClickStack

  • กำลังค่อย ๆ เปลี่ยนจาก UI แบบคัสตอมบน Grafana เดิม ไปเป็น UI แบบ ClickHouse-native ที่ใช้ HyperDX
  • HyperDX รองรับ ไม่ยึดติดกับสคีมา รองรับ Lucene query รวมถึง SQL และเข้ากันได้อย่างสมบูรณ์กับชนิดข้อมูลที่หลากหลายของ ClickHouse
  • ข้อมูลจากโครงสร้างตารางที่หลากหลายและจาก exporter แบบคัสตอมก็สามารถถูกรวมเข้า UI เดียวกันได้โดยไม่ต้องเปลี่ยน UI
  • ส่วน Grafana ยังคงทำหน้าที่ด้าน metrics แบบอิง Prometheus และแดชบอร์ดคงที่ ทำให้ทั้งสองโซลูชันทำงานเสริมกัน

การยอมรับโมเดล Wide Events และ High Cardinality

  • Wide events คือแนวทางที่แต่ละแถวบรรจุบริบทหลากหลาย เช่น query ID, ชื่อ Pod, ข้อมูลเวอร์ชัน ทำให้เก็บข้อมูลทั้งหมดได้โดยไม่ต้อง aggregate ล่วงหน้า
  • วิธีนี้ต่างจาก Prometheus และระบบคล้ายกัน เพราะช่วยให้วิเคราะห์เชิงลึกและ query ได้ยืดหยุ่นโดยไม่ต้องกังวลเรื่อง pre-aggregation, ข้อจำกัดของ label หรือ cardinality explosion
  • การทำ aggregation ในช่วงเวลาที่วิเคราะห์จริงช่วยให้คุมได้ทั้ง ประสิทธิภาพและต้นทุน แม้อยู่ในสภาพแวดล้อมข้อมูลขนาดใหญ่

การแสดงภาพข้อมูลและความยืดหยุ่นของการ query

  • ClickHouse เชื่อมต่อกับ Plotly, Jupyter notebook และเครื่องมือแสดงผลอื่น ๆ ได้ดี จึงนำไปใช้ร่วมกับเครื่องมือ visualization ได้อย่างอิสระ
  • นอกจากการสำรวจอย่างรวดเร็วผ่าน HyperDX ที่ใช้ Lucene แล้ว ยังสามารถทำการวิเคราะห์หาสาเหตุเชิงลึกด้วย query ที่มีความสัมพันธ์หรือเงื่อนไขซับซ้อน เช่น SQL และ JOIN ได้โดยตรงใน ClickHouse

การเพิ่มขึ้นของแหล่งข้อมูลแบบ Wide Event ที่หลากหลาย

  • kubenetmon: โอเพนซอร์สสำหรับมอนิเตอร์เครือข่าย Kubernetes ใช้วิเคราะห์ทราฟฟิก L3/L4, การเชื่อมต่อ และต้นทุน
  • Kubernetes Event Exporter: ใช้งานฟอร์กที่เพิ่ม ClickHouse sink เพื่อติดตามการเปลี่ยนแปลงสถานะของคลัสเตอร์ขนาดใหญ่ และกำลังทดลอง snapshot ของอ็อบเจ็กต์ทั้งหมด
  • Control Plane Data, RUM(Real User Monitoring), Istio Access Log และข้อมูลจากหลายเลเยอร์อื่น ๆ ช่วยขยายขอบเขตการตีความและความสามารถในการทำ correlation analysis อย่างมาก

ประเด็นด้านการปฏิบัติการและทิศทางในอนาคต

  • แม้ SysEx อาจถูกเปิดเผยในระหว่างการ query ล็อกหรือ metrics แต่ถูกออกแบบให้มีข้อจำกัดหน่วยความจำและลดผลกระทบเมื่อเกิดข้อผิดพลาดให้เหลือน้อยที่สุด
  • Zero-impact scraping: กำลังศึกษาวิธีแบบ decoupling เต็มรูปแบบ (เช่น ใช้ plain rewritable disk บน S3) เพื่อกำจัดผลกระทบต่อคลัสเตอร์อย่างถึงราก
  • OTel ยังเป็นองค์ประกอบสำคัญสำหรับการเก็บล็อกในช่วงเริ่มต้นบริการหรือในสถานะผิดปกติ แต่เมื่อแนวทาง zero-impact มีเสถียรภาพมากขึ้น การพึ่งพา OTel ก็น่าจะลดลงอีก

วิวัฒนาการและการใช้งาน JSON type ของ ClickHouse

  • JSON type เปิดให้ใช้งานแบบ GA อย่างเป็นทางการแล้ว ทำให้สร้าง dynamic columns ตามฟิลด์ รองรับหลายชนิดข้อมูล และรับมือกับ schema explosion ได้ยืดหยุ่นมากขึ้น
  • ยังมีข้อจำกัดด้านการ optimize เมื่อ query JSON ที่มีคอลัมน์จำนวนมาก จึงมีการพัฒนาแนวทางอย่างการจัดเก็บคู่ขนานตามรูปแบบ และการยืนยันประโยชน์ใช้สอยของ Map type อีกครั้ง
  • เมื่อทำงานร่วมกับ HyperDX ก็สามารถดึงและวิเคราะห์ฟิลด์จาก Map และ JSON ได้อัตโนมัติ และมีแผนจะขยายการใช้งาน JSON ให้กว้างขึ้นในอนาคต

บทสรุปและการเปลี่ยนแปลงเชิงวัฒนธรรม

  • ตอนนี้ LogHouse ได้กลายเป็น แพลตฟอร์มสังเกตการณ์หลัก ของการปฏิบัติการ ClickHouse Cloud ตั้งแต่การวิเคราะห์ประสิทธิภาพไปจนถึงการดีบักแบบเรียลไทม์
  • จุดเริ่มต้นคือการลดต้นทุน แต่ด้วยเครื่องมือแบบปรับแต่งอย่าง SysEx, การทำงานร่วมกับ OTel และการขยาย UI ที่ยืดหยุ่นบนพื้นฐาน HyperDX ทำให้เกิด การเปลี่ยนผ่านทั้งด้านเทคนิคและวัฒนธรรม
  • โมเดลข้อมูลแบบ Wide Event ขนาดใหญ่และมีความแม่นยำสูง มอบ คุณค่าและประสิทธิภาพรูปแบบใหม่ ให้กับงานวิศวกรรม การซัพพอร์ต และการวิเคราะห์ข้อมูลทั้งหมด
  • จากประสบการณ์ที่ได้จากสเกลระดับ 100PB และ 500 ล้านล้านแถว บริษัทมีแผนจะเดินหน้านำอนาคตของ observability ต่อไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-23
ความคิดเห็นจาก Hacker News
  • พูดตรง ๆ ว่าผมไม่คิดว่านี่เป็นเรื่องน่าอวดอะไร การเก็บล็อกถึง 100PB เป็นหลักฐานว่าพวกคุณยังหาไม่เจอจริง ๆ ว่าควรเก็บอะไรไว้ ข้อมูลสำคัญส่วนใหญ่ดูได้จากเมตริกและอีเวนต์แบบมีโครงสร้างก็พอแล้ว ที่เหลือล่ะ? ก็เป็นแทรซล็อกรายละเอียดที่ไม่มีใครอ่าน ซึ่งจะเปิดดูแค่ตอนระบบพังจริง ๆ วิธีที่ดีกว่าคืออะไร? ใช้นโยบายการเก็บข้อมูลตาม “ระดับความสนใจ” เช่น ล็อกที่ไม่เคยถูกใช้ในอัลิร์ตเลย หรือ 3 เดือนแล้วยังไม่เคยถูกค้นหา ก็ลบทิ้งอัตโนมัติ ไม่งั้นมันก็เป็นแค่กองขยะดิจิทัลระดับไฮเอนด์ที่บีบอัดมานิดหน่อย
    • ผมกลับชอบแนวทางเก็บทุกอย่างไว้ก่อน แล้วค่อยกรองตอนที่ไม่ต้องใช้มากกว่า ปกติ debug log อาจไม่จำเป็น แต่พอถึงเวลาต้องใช้ มันคือสิ่งที่ขาดไม่ได้จริง ๆ ถ้ามีอีเวนต์บางอย่างที่เกิดขึ้นหายากจนแทบทำซ้ำไม่ได้ ตอนนั้นก็ไม่มีทางกลับไปรวบรวมข้อมูลใหม่ได้ ถ้าเก็บไว้หมดตั้งแต่แรก แค่ค้นหาก็จบ ซึ่งผมว่าดีกว่ามาก
    • ผมเคยใช้ Datadog ในหลายบริษัท แล้วพอค่าต่ออายุพุ่งแบบไร้เหตุผล ก็มักโดนกดดันให้เหลือแค่เมตริกกับอีเวนต์ที่จำกัดไว้ แล้วลดล็อกลง ปัญหาคือ ถ้ารู้ล่วงหน้าว่าจะเกิดอะไรขึ้น เราก็คงแก้มันไปนานแล้ว เวลาเกิดอะไรผิดปกติแล้วต้องไล่ว่าเกิดอะไรขึ้นจริง ๆ ล็อกรายละเอียดมีความจำเป็นมาก แต่ในโลกความจริง ถ้าไม่ใช่สถานการณ์ที่เกิดซ้ำ ๆ ก็แทบไม่มีทางรู้ล่วงหน้าว่าล็อกไหนสำคัญ
    • “นโยบายการเก็บข้อมูลตามระดับความสนใจ” เป็นไอเดียที่ดีมาก แค่นับจำนวนครั้งที่มีการ query/alert แยกตามแพตเทิร์นของล็อก ก็ใช้ตั้งนโยบาย TTL (ระยะเวลาจัดเก็บ) ได้แล้ว ทีมเราก็ใช้วิธีนี้จริง ลดค่าเก็บข้อมูลได้ 70% ขณะเดียวกันก็ยังเก็บข้อมูลสำคัญไว้ครบ
    • ค่าส่งล็อกก็ไม่ฟรีเหมือนกัน โดยเฉพาะภาษาที่เขียนล็อกลงดิสก์ให้เร็วที่สุดเพื่อหาสาเหตุของ crash ต้นทุนจะยิ่งสูง ข้อมูลเยอะเกินไปก็ทำให้หาความสัมพันธ์ที่สำคัญจริง ๆ ยากขึ้น และล็อกของบั๊กที่แก้ไปแล้วก็มักหมดค่าค่อนข้างเร็ว ผมชอบข้อมูลเชิงสถิติมากกว่า เพราะรวมค่าได้มีประสิทธิภาพกว่า และโดยเฉพาะในภาษาที่อิง GIL การใช้ OTEL ก็อาจมี overhead สูงเกินไปได้
    • ถ้าข้อมูลถูกเก็บไว้แล้ว หลังจากนั้นการกรองหรือเก็บกวาดก็ยังเป็นปัญหาที่จัดการได้ ผมคิดว่าการเก็บทุกอย่างไว้แล้วใช้ตอนจำเป็น ดีกว่าตอนต้องใช้แล้วไม่มีให้ใช้จนลำบาก แน่นอนว่ามันพูดได้ก็ต่อเมื่อมีทรัพยากรพอจะรันโครงสร้างพื้นฐานขนาดใหญ่นี้
  • อันที่จริงนี่เกี่ยวกับล็อกใน Clickhouse เท่านั้น แทบไม่เกี่ยวกับล็อกประเภทอื่นเลย ถึงอย่างนั้น Clickhouse เองก็เป็นโซลูชันที่ผมชอบมาก
    • น่าจะเป็นคนที่ทำให้ปาร์ตี้สนุกมากเลยนะ
  • ขอยกข้อควรระวังอย่างหนึ่ง ตอนที่บริการติด crash loop หรือดับจากเหตุขัดข้อง SysEx จะเข้าถึง system table ที่ต้องใช้ไม่ได้ จึงเก็บล็อกไม่ได้ แต่ OpenTelemetry(OTel) เป็นแนวทางแบบ passive ดังนั้นถึงบริการจะยังไม่ฟื้นเต็มที่ ก็ยังเก็บล็อกจาก stdout, stderr ได้ แบบนี้จึงสามารถรวบรวมล็อกระหว่างภาวะขัดข้องและวิเคราะห์ไปถึงสาเหตุรากได้
    • โปรเจกต์ OTel ที่ผมเคยทำมาทั้งหมดเป็นแบบ active เพราะงั้นข้อความนั้นสำหรับผมไม่ใช่ข้อมูลใหม่ แต่ดูเหมือนจะอธิบายผิดหรือไม่ครบมากกว่า
  • ผมสงสัยว่า “wide event” ต้องกินพื้นที่จัดเก็บมากขนาดนี้จริงหรือ การทำ Observability โดยเนื้อแท้แล้วเป็นปัญหาเรื่อง sampling ขอแค่สร้างสภาพของระบบ ณ ช่วงเวลาหนึ่งกลับขึ้นมาได้ดีที่สุดด้วยพื้นที่น้อยที่สุดก็พอ จะลดจำนวน sample หรือเพิ่มประสิทธิภาพการบีบอัดก็ได้ และผมก็ไม่คิดว่าเทคโนโลยีการบีบอัดจะไปสุดทางแล้วด้วย ข้อมูลที่เต็มไปด้วยความซ้ำซ้อนแบบนี้น่าจะมีโครงสร้าง low rank มหาศาลอยู่แน่ ๆ แน่นอนว่าตอนนี้ก็มีทั้ง inverted index และต้นไม้หลายแบบใช้อยู่แล้ว แต่ผมก็ยังรู้สึกว่าวิธีเชิงวิจัยที่ทดลองมากขึ้นอย่าง low-rank tensor decomposition ก็น่าจะมีหวังนะ ผมไม่ได้อยู่ในวงการนี้โดยตรง อาจจะพลาดอะไรไปก็ได้
  • ผมไม่เคยเจอสเกลระดับ ClickHouse ขนาดนี้ ล็อกปริมาณนี้ค้นหาได้จริงหรือ? เท่าที่รู้ ElasticSearch ก็ query ได้ดีในระบบขนาดเล็ก แล้วอะไรคือเหตุผลที่ต้องใช้ ClickHouse แทนการเก็บไฟล์ json สำหรับล็อกย้อนหลัง?
    • ผมทำงานอยู่ในสเกลนี้ คำตอบสั้น ๆ คือ ทำได้ แต่ต้นทุนประมวลผลอาจเกินจินตนาการ ถ้ากลยุทธ์ indexing, sorting, clustering เละเทะ การค้นหาแค่ “เรคคอร์ดที่มีสตริงนี้” ครั้งเดียวอาจเสีย $1~$10 จากประสบการณ์ของผมกับข้อมูลขนาดใหญ่ หลักการสำคัญคือ “แตะข้อมูลให้น้อยที่สุด เท่าที่จะเป็นไปได้” กับ “ย้ายข้อมูลให้น้อยที่สุด เท่าที่จะเป็นไปได้” ถ้ามีการ serialize/deserialize หรือ disk, network IO เพิ่มขึ้นแม้แต่ครั้งเดียว ค่าใช้จ่ายก็พุ่งมาก สำหรับ OTel นั่นอาจหมายความว่าการต้องผ่าน collector เพิ่มอีกชั้น ขัดกับประสิทธิภาพโดยตรง แต่ในระดับเพตะไบต์ การประหยัดจากการปรับจูนเล็ก ๆ แบบนี้อาจคุ้มกว่าค่าเงินเดือนวิศวกรที่ต้องเขียนโค้ด serialization ซับซ้อนเสียอีก
    • ทำไมถึงใช้ ClickHouse แทนไฟล์ json สำหรับล็อกย้อนหลัง? มีหลายเหตุผล (1) DB สำหรับล็อกอย่าง ClickHouse บีบอัดแบบรายคอลัมน์ แยกบีบอัดแต่ละฟิลด์ จึงใช้พื้นที่น้อยกว่าไฟล์ json ทั่วไปมาก แม้จะบีบอัดแล้วก็ตาม (2) DB สำหรับล็อก query ได้เร็วกว่าเยอะ มากกว่า 1000 เท่าก็เป็นไปได้ เพราะมันไม่อ่านข้อมูลที่ไม่จำเป็นเลย ลิงก์ที่เกี่ยวข้อง. (3) การ grep ไฟล์ json ปริมาณ 100PB นั้นแทบเป็นไปไม่ได้ในทางปฏิบัติ แต่ DB สำหรับล็อกสามารถขยายแบบแนวนอนได้ด้วยการเพิ่ม storage node และพื้นที่เก็บข้อมูล
    • มันเป็นเรื่องของขนาดและต้นทุน บริษัทผมก็เจอปัญหาปริมาณล็อกชนเพดาน ถ้าเอา json โยนเข้า Splunk ตรง ๆ ค่าใช้จ่ายจะเกิน 6 ล้านดอลลาร์ต่อปี แต่มีงบอนุมัติแค่ 5~10% ของจำนวนนั้น ในบทความบอกว่าการประมวลผล json log ต้องใช้ CPU 8,000 ตัว แต่หลัง optimize แล้วใช้แค่ 90 ตัว
    • เมื่อ 2~3 ปีก่อน ClickHouse ยังมีจุดอ่อนเรื่องประสิทธิภาพการค้นหาแบบ full text มันเร็วและรองรับปริมาณระดับ ElasticSearch ได้ก็จริง แต่ขึ้นอยู่กับ use case ถ้าไม่ได้ทำดัชนีไว้ล่วงหน้า ผมรู้สึกว่า ES ยังเร็วกว่าเยอะสำหรับการจัดเป็นชุด การจัดกลุ่ม และ FTS
  • ความสุดโต่งเรื่อง observability นี่ให้ความรู้สึกเหมือนลัทธิใหม่จริง ๆ แถมยังมีเงินเยอะมากด้วย
    • ถ้าจะขุดไปจนถึงความผิดปกติที่ยังไม่เคยรู้จักมาก่อน ก็เหมือนไม่มีทางเลือกที่เฉียบคมกว่านี้เท่าไร
    • สิ่งที่น่าขำคือ สุดท้ายสร้างปัญหาพวกนี้ขึ้นมาให้คนลำบาก แล้วก็กลับมาขายแนวทาง “จ่ายรายเดือนแล้วทุกอย่างจบ” ซะอย่างนั้น
  • ในบทความไม่ได้บอกเลยว่าเก็บล็อกไว้นานแค่ไหน พอเกินช่วงเวลาหนึ่งไปแล้ว จะเก็บแค่ข้อมูลสรุป/ข้อมูล aggregate ไว้ แล้วไม่ต้องเก็บข้อมูลดิบต่อหรือเปล่า ก็เป็นเรื่องที่น่าสงสัย
  • ทุกครั้งที่กลับจาก Clickhouse มาใช้ Postgres จะรู้สึกช็อกทางวัฒนธรรมตลอด การ import dump ขนาด 20GB แล้วต้องรอเป็นนาที ๆ มันฟังดูยอมรับไม่ได้เลยนะ เรื่องแบบนี้ไม่ควรจบได้ในไม่กี่วินาทีเหรอ
    • ทุกครั้งที่ใช้ Clickhouse ผมก็เหนื่อยมาก แน่นอนว่ามันมีงานที่ Clickhouse จำเป็นและ Postgres แทนไม่ได้ แต่โดยรวมแล้วผมรู้สึกว่า Clickhouse มี “พื้นที่เสี่ยง” เยอะ และถ้าไม่ใช่งานเฉพาะทางที่จำกัดมาก ๆ Postgres ก็ดูดีกว่าเกือบทุกด้าน
  • คนที่ผลักดันให้ใช้ wide event มักไม่ค่อยพูดถึงเรื่องต้นทุนข้อมูลล็อกที่พุ่งขึ้นเลย ถ้าเทียบกับแนวทางเดิม (เมตริก + เทรซ + ล็อกแบบอิงแซมเปิล) มันแพงกว่าชัดเจน แน่นอนว่ามีข้อดี แต่ประเด็นเรื่องต้นทุนมักหายไปเสมอ
    • โครงสร้าง wide event ที่ออกแบบมาดี อาจลดต้นทุนการจัดเก็บได้มากกว่าล็อกแบบดั้งเดิมเสียอีก เพราะคำขอจากภายนอกหนึ่งครั้งจะถูกเก็บเป็น wide event เดียว ทำให้มีข้อมูลครบสำหรับการดีบักหรือวิเคราะห์ในภายหลัง ดูบทความนี้ประกอบ A practitioner's guide to wide events
  • ผมสงสัยว่าเคล็ดลับหลักของระบบอย่าง Clickhouse หรือ Dynamo คืออะไร โดยแก่นแล้วมันเป็นอะไรคล้ายแฮชเทเบิลขนาดยักษ์หรือเปล่า?
    • มีเคล็ดลับร่วมกันอยู่สองข้อในฐานข้อมูลขนาดใหญ่แบบ Clickhouse และระบบคล้ายกัน ข้อแรกคือจัดวางข้อมูลบนดิสก์อย่างชาญฉลาด เพื่อจะได้มองข้ามข้อมูลส่วนใหญ่และอ่านเฉพาะก้อนที่ต้องใช้จริง ๆ เช่น การเก็บแบบคอลัมน์และตระกูล LSM tree รวมถึงบีบอัดข้อมูลทั้งหมดเพื่อลด disk IO ให้เหลือน้อยที่สุด ข้อสองคือการจูนแบบสุดขีดเพื่อใช้ทรัพยากรทุกอย่างให้เต็มที่ ทั้ง CPU, RAM, ดิสก์ และเครือข่าย ตัวอย่างเช่น Clickhouse สามารถประมวลผลได้มากกว่า 1 พันล้านแถวต่อวินาทีต่อ CPU core และยังขยายตามจำนวนคอร์ได้เกือบเชิงเส้น