10 ปีของ ClickHouse โอเพนซอร์ส

 (clickhouse.com)
2 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ClickHouse เปิดเป็นโอเพนซอร์สเมื่อ 15 มิถุนายน 2016 และตลอด 10 ปีที่ผ่านมา มีผู้ร่วมพัฒนามากกว่า 2,000 คน จนเติบโตเป็นหนึ่งในโปรเจ็กต์ฐานข้อมูลเชิงวิเคราะห์โอเพนซอร์สชั้นนำ
  • เป้าหมายไม่ใช่แค่เปิดเผยโค้ด แต่ยังเปิดเผยคู่มือการมีส่วนร่วม การรีวิวโค้ด โรดแมป CI การรีลีส และเอกสารต่าง ๆ ในแนวทางของ โอเพนซอร์สระดับ 3
  • จุดเริ่มต้นมาจากข้อจำกัดของระบบวิเคราะห์เว็บที่ใช้ MySQL และประสบการณ์จาก OLAPServer กับ Metrage ได้นำไปสู่การประมวลผลแบบคอลัมน์และการออกแบบ MergeTree
  • ClickHouse ไม่ใช่ส่วนขยายบน DBMS เดิม แต่เป็น DBMS ที่สร้างขึ้นใหม่ตั้งแต่ต้น โดยค่อย ๆ พัฒนาการแสดงผลแบบคอลัมน์ ฟังก์ชัน aggregate table engine การบีบอัด SQL parser เซิร์ฟเวอร์·ไคลเอนต์ และ ReplicatedMergeTree ตั้งแต่ปี 2009
  • หลังจากใช้งานจริงภายในองค์กรตั้งแต่ปี 2014 เพื่อประมวลผลเรกคอร์ดวันละหลายแสนล้านรายการ ClickHouse ก็ผ่านกระบวนการเผยแพร่บทความและอนุมัติภายในในปี 2015 ก่อนเปิดสู่สาธารณะทั่วโลกในปี 2016

10 ปีนับจากการเปิดเป็นโอเพนซอร์ส

  • ClickHouse เปิดเป็นโอเพนซอร์สเมื่อ 15 มิถุนายน 2016
  • หลังจากนั้นมีผู้ร่วมพัฒนามากกว่า 2,000 คน และกลายเป็น “ฐานข้อมูลเชิงวิเคราะห์โอเพนซอร์สที่ได้รับความนิยมมากที่สุด”
  • เป้าหมายหลักของโปรเจ็กต์ไม่ใช่เพียงเปิดเผยโค้ด แต่คือการเปิดเผย กระบวนการพัฒนาและกระบวนการมีส่วนร่วม ให้มากที่สุด

ระดับโอเพนซอร์สที่ ClickHouse มุ่งไป

  • โอเพนซอร์สมีอยู่หลายระดับ
    • Level 0: เปิดให้คนอ่านโค้ดได้ แต่ไม่มีอะไรมากกว่านั้น ตัวอย่างคือการเผยแพร่เชิงเก็บถาวรหรือเชิงพิพิธภัณฑ์อย่าง Doom และ MS-DOS
    • Level 1: อัปเดตผ่าน commit ใน repository สาธารณะ แต่ไม่ได้จำเป็นต้องรับ contribution ตัวอย่างคือ SQLite และ Ladybird
    • Level 2: รับ contribution แต่กระบวนการพัฒนาไม่ได้โปร่งใสและเปิดเผยอย่างเต็มที่ โปรเจ็กต์โอเพนซอร์สที่เคลื่อนไหวอยู่ส่วนใหญ่อยู่ในระดับนี้
    • Level 3: มีทั้งคู่มือการมีส่วนร่วม การติดตามงาน การรีวิวโค้ด โรดแมปการพัฒนา การทดสอบและ CI รอบการรีลีส การซัพพอร์ตผู้ใช้ และเอกสาร
  • ClickHouse มุ่งเป็นโอเพนซอร์ส Level 3
  • อีกเป้าหมายหนึ่งคือเป็นตัวอย่างทั้งในด้านโค้ดและแนวปฏิบัติการพัฒนาให้กับนักพัฒนาที่อยากสร้างฐานข้อมูลใหม่
    • โค้ดมุ่งให้เป็นแบบแยกส่วน เป็นอิสระต่อกัน และมีเอกสารกำกับ
    • เมื่อจำเป็นต้องใช้แนวคิดที่ซับซ้อน ก็จะอธิบายตั้งแต่ต้นในคอมเมนต์ เพื่อให้ผู้อ่านไม่ต้องไปเปิดตำรา Wikipedia หรือ AI เพิ่มเติม

พื้นที่สำหรับการพัฒนา C++ และการทดลองด้านประสิทธิภาพ

  • ClickHouse เป็นหนึ่งใน repository โอเพนซอร์ส C++ ที่ได้รับความนิยม และตั้งใจให้เป็นพื้นที่ที่สามารถเรียนรู้ทั้งฟีเจอร์ภาษาใหม่อย่าง C++23 รวมถึงระบบ build การทำ continuous integration และการทดสอบ ตลอดจนแนวปฏิบัติด้าน code review
  • การทดลองด้านโครงสร้างข้อมูลและ การปรับแต่งประสิทธิภาพ ก็เป็นอีกการใช้งานสำคัญ
    • แม้แต่ Pull Request เชิงทดลองที่ไม่ได้ตั้งเป้าจะ merge ก็ยังถูกทดสอบในระดับเดียวกับ production release
    • สามารถใช้ ClickHouse เป็นสนามพิสูจน์ตัวจัดสรรหน่วยความจำใหม่ ไลบรารีบีบอัด hash table รูปแบบข้อมูล หรืออัลกอริทึมการเรียงลำดับใหม่ ๆ ได้
  • ในโรดแมปยังมีรายการที่เป็นการทดลอง แปลกประหลาด หรือแม้แต่ชวนขำรวมอยู่ด้วย
  • ผู้ร่วมพัฒนาทุกคนได้รับเครดิตใน CHANGELOG และในตาราง system.contributors ภายในฐานข้อมูล
  • หลายครั้งฟีเจอร์ที่เริ่มต้นมายังไม่สมบูรณ์ก็ถูกช่วยกันพัฒนาต่อจนเสร็จ และแม้จะต้องเขียนโค้ดใหม่ทั้งก้อน ก็ยังให้คุณค่ากับเจตนาและ use case ของผู้เขียนคนแรก

ปัญหาก่อนมี ClickHouse และต้นแบบรุ่นแรก

  • commit แรกของ ClickHouse ถูกสร้างเมื่อ 29 พฤษภาคม 2009 และเป็น การปรับแต่งประสิทธิภาพ เพื่อลดปัญหาที่ฟังก์ชัน libc อย่าง localtime, mktime, gmtime ช้าเกินไปจนโผล่ใน profiler
  • จุดเริ่มต้นคือการทดลองประมวลผลข้อมูลสำหรับระบบวิเคราะห์เว็บ
    • ระบบรับ pageview log ที่ส่งมาจากเว็บไซต์ คล้ายกับ Google Analytics
    • ใช้ทั้ง MySQL การประมวลผลข้อมูลด้วย C++ และโครงสร้างข้อมูล C++ แบบคัสตอมสำหรับส่วนที่ MySQL รับไม่ไหว
    • ฐานข้อมูล MySQL ใช้เก็บรายงานแบบ pre-aggregate สำหรับลูกค้า ส่วนโครงสร้างข้อมูลคัสตอมใช้คำนวณ session และประวัติผู้ใช้
  • ข้อมูลเพิ่มขึ้นตลอดเวลา และ log ใหม่ก็ไหลเข้ามาแบบเรียลไทม์ หากประมวลผล log ทุก 5 นาทีไม่เสร็จภายใน 5 นาที ความล่าช้าก็จะสะสมต่อเนื่อง
  • ยังมีการลองใช้ฐานข้อมูลและไลบรารีอื่น ๆ ด้วย
    • มีการพิจารณา TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog เอกสารด้านการบีบอัดข้อมูล และเอกสารของเซิร์ฟเวอร์แบบ event loop
  • ความต้องการให้ผู้ใช้ประกอบรายงานเองได้อย่างอิสระ ทำให้ข้อจำกัดของรายงานแบบ pre-aggregate ชัดเจนขึ้น และนำไปสู่การพิจารณาฐานข้อมูลแบบคอลัมน์

OLAPServer และ Metrage

  • แนวทางแบบคอลัมน์คือเก็บ structured log แบบไม่ aggregate ไว้ก่อน แล้วค่อย aggregate แบบทันทีในขณะที่ลูกค้ากำลังรอหน้าเว็บโหลด
  • มีการทดสอบทั้ง Infobright และ InfiniDB ที่เป็นส่วนขยายของ MySQL รวมถึงฐานข้อมูลวิเคราะห์แบบอิสระอย่าง Vertica, MonetDB และ LucidDB แต่ทั้งหมดไม่สามารถรองรับเงื่อนไขการโหลดที่ระดับ 100 พันล้านเรกคอร์ดต่อวันและ 500 คอลัมน์ได้
  • ต้นแบบคัสตอมตัวแรกคือ OLAPServer
    • พัฒนาในเดือนธันวาคม 2008 และนำไปใช้งานในเดือนมกราคม 2009
    • เก็บทุกคอลัมน์ไว้ในไฟล์ไบนารีเดียว แยกตามวันและตามเว็บไซต์
    • ใช้ hash แทน string และรองรับเฉพาะชนิดข้อมูลจำนวนเต็ม
    • ใช้การบีบอัดแบบเบา และอัปเดตวันละครั้งโดยมีดีเลย์หลายชั่วโมง
    • มี API สำหรับระบุคอลัมน์ที่ใช้ group ฟังก์ชัน aggregate ตัวกรอง และการเรียงลำดับ โดย query ถูกระบุเป็น XML
    • งานเติมข้อมูลจากข้อมูล aggregate เดิมใน MySQL ให้ “ย้อนกลับเป็นข้อมูลไม่ aggregate” เพื่อให้ได้ผลลัพธ์เดิมนั้น Evgenii Gatov เป็นผู้แก้ปัญหาได้
  • OLAPServer ยังใช้ได้ดีกับ endpoint ที่วิเคราะห์ข้อมูลอินเทอร์เน็ตทั้งองค์กรในภาพรวม ไม่ใช่เฉพาะเว็บไซต์เดียว และตอบสนองได้เร็วพอที่นักวิเคราะห์ภายในจะใช้แทน MapReduce ภายในองค์กร
  • ต้นแบบตัวที่สองคือ Metrage
    • ข้อมูลใน MySQL มีราว 50TB กระจายอยู่ใน 50 shard และโครงสร้างข้อมูลคัสตอมจำนวนมากถูกเก็บเป็น BLOB
    • เวลาจะ aggregate โปรแกรมต้องอ่าน BLOB ออกมา ใช้โค้ดคัสตอมประมวลผล แล้วค่อยเขียนกลับเข้าไปใหม่
    • ข้อมูลใน MySQL ไม่ได้ถูกบีบอัด และลำดับการมาถึงของข้อมูลก็ไม่ตรงกับลำดับช่วงที่ query มักต้องอ่าน จึงอ่านได้ช้า
    • Metrage คือโครงสร้างข้อมูลคัสตอมสำหรับ incremental aggregate ที่ใช้ background merge โดยแต่ละ record ถูกกำหนดเป็น C++ struct ที่มีเมธอด add, update, merge, serializeText/Binary, deserializeText/Binary
  • OLAPServer เป็นโครงสร้างแบบคอลัมน์ที่ยังไม่ aggregate ส่วน Metrage เป็นโครงสร้างแบบแถวเรียลไทม์ที่มี CRDT แบบใดก็ได้
  • ClickHouse เริ่มต้นจากการนำความเร็วของการ aggregate แบบคอลัมน์มารวมกับการอัปเดตแบบเรียลไทม์และ data locality บน merge tree แล้วทำให้เป็นระบบทั่วไปที่รองรับภาษาคิวรีและชนิดข้อมูลจริง

DBMS ที่สร้างขึ้นใหม่ตั้งแต่ต้น

  • ClickHouse เป็นหนึ่งในกรณีที่หาได้ยากของ DBMS ที่ไม่ได้ต่อยอดจากฐานข้อมูลเดิม แต่เป็นระบบที่ สร้างขึ้นใหม่ตั้งแต่ต้น
  • commit แรก ๆ ในปี 2009 เกี่ยวข้องกับการปรับแต่งโครงสร้างข้อมูลอื่นใน monorepository เดียวกัน และยังคงอยู่เพราะตอนแยก repository ออกมาเพื่อเปิดเป็นโอเพนซอร์ส ได้เก็บประวัติเดิมไว้
  • ขั้นแรกของการสร้าง DBMS ใหม่คือการพัฒนาโครงสร้างคอลัมน์ในหน่วยความจำ และคลาส IColumn กับ Field ที่คุ้นเคยจนถึงทุกวันนี้ก็เกิดขึ้นในช่วงนั้น
    • มันอาจดูคล้าย Apache Arrow แต่ในเวลานั้น Apache Arrow ยังไม่เกิดขึ้น
    • ฟอร์แมตแบบคอลัมน์อื่นอย่าง RCFile, Trevni, ORC, Parquet ก็ยังไม่มีในตอนนั้นเช่นกัน
  • หลังจากนั้นจึงมี ฟังก์ชัน aggregate ซึ่งจนถึงวันนี้ก็ยังเป็นหนึ่งในส่วนที่สำคัญที่สุดของ ClickHouse
  • ต่อมามีการเพิ่ม table engine
    • ช่วงแรกใช้ชื่อว่า “primary key” อยู่ไม่กี่วัน
    • ทำให้สามารถอ่านและเขียนคอลัมน์บนดิสก์ได้
    • table engine ตัวแรกคล้ายกับ TinyLog ที่ยังมีอยู่จนทุกวันนี้
  • การบีบอัดในช่วงแรกใช้ QuickLZ แต่ภายหลังเปลี่ยนมาใช้ LZ4 หลังจากอ่านบล็อกของ Yann Collet

Query pipeline และการทำ SQL

  • block streams คือคอมโพเนนต์ใน data processing pipeline ที่ทำหน้าที่สร้าง รับใช้ และแปลงสตรีมของ column chunk
    • ปัจจุบันถูกแทนที่ด้วย Processors
    • มันกลายเป็นรากฐานของการจัดรูปแบบผลลัพธ์และการทำ table query
  • ใน commit เดียวกันยังมีการเพิ่ม StorageSystemNumbers สำหรับทดสอบ ซึ่งปัจจุบันยังคงอยู่ในชื่อ table system.numbers
  • query pipeline แรกมีหน้าที่พิมพ์ตัวเลขออกมาเป็น TSV และ relational operator ตัวแรกคือ LIMIT
  • ตัว parser ของ SQL ตอนแรกลองใช้ boost::spirit แต่ไม่สำเร็จ ก่อนจะหันไปสร้าง recursive descent parser ขึ้นมาเอง
  • ยังมีแนวคิดบางอย่างที่เคยถูกเพิ่มเข้ามาในช่วงแรก ก่อนจะถูกถอดออกหรือถูกนำกลับมาใหม่ในภายหลัง
    • คอลัมน์ตัวเลขแบบ variable-length encoding ถูกถอดออกเพราะช้า และอีกนานมากจึงมี custom compression codec ที่แยกอิสระจากคอลัมน์เข้ามาแทน
    • ชนิดคอลัมน์ Variant ที่เก็บค่า field ได้หลายแบบก็ถูกถอดออกเพราะช้า และ Variant ที่ดีกว่าถูกเพิ่มเข้ามาในปี 2025
    • ชนิด array ขนาดคงที่ถูกถอดออกเพราะความจำเป็นต่ำ และตอนนี้กำลังมีการพิจารณานำกลับมาอีกครั้ง
  • สิ่งนี้สะท้อนหลักการพัฒนาว่า การลบโค้ดที่ไม่จำเป็นสำคัญกว่าการเพิ่มโค้ดใหม่

การนำขึ้น production และ ReplicatedMergeTree

  • โครงสร้างตารางจริงตัวแรกที่ถูกทดสอบบน ClickHouse คือ table hits ซึ่งยังสามารถเห็นได้ใน ClickBench จนถึงทุกวันนี้
  • ระหว่างการอ่านเขียนตารางนี้ พบว่า C++ iostreams ช้า จึงมีการเพิ่ม WriteBuffer และ ReadBuffer ซึ่งยังใช้อยู่ในปัจจุบัน
  • ฟังก์ชันแรกของ SQL คือ arithmetic operator และมันนำไปสู่การสร้าง interpreter ของ SELECT query ตัวแรก
  • เซิร์ฟเวอร์ ClickHouse ถูกเพิ่มเข้ามาเมื่อ 9 มีนาคม 2012 และ clickhouse-client เมื่อ 25 มีนาคม 2012
  • เมื่อรวมกับ table engine อย่าง Log, TinyLog, Merge, Distributed, Memory ก็ทำให้สามารถนำขึ้น production ได้
    • use case แรกใน production คือเก็บ log chunk สำหรับการประมวลผลต่อ และ query แบบรวมศูนย์บน raw log
    • มันถูกใช้เหมือน persistent log queue ที่ query ด้วย SQL ได้
  • หลังจากนั้นมีการเพิ่ม MergeTree
    • แม้ข้อมูลจะไหลเข้ามาตามลำดับเวลา ก็ยังจัดเรียงแบบ incremental ใน background ได้
    • ทำให้ query แบบช่วงข้อมูลของเว็บไซต์เดียวทำได้รวดเร็ว
    • ส่งผลให้สามารถนำไปใช้ production เพื่อแทน OLAPServer และ Metrage ได้
  • ในปี 2012 Michael Kolupaev เข้าร่วมทีมเป็นพนักงานคนที่สอง และมีส่วนร่วมในการพัฒนา ReplicatedMergeTree
  • production ถูกกระจายอยู่ในหลายดาต้าเซ็นเตอร์ และทีม infrastructure มี “drills” ที่ปิดดาต้าเซ็นเตอร์หนึ่งแห่งนานหนึ่งชั่วโมงทุกเดือน
    • บริการ production ทั้งหมดจึงต้องมีการทำ replication ข้ามหลายดาต้าเซ็นเตอร์
    • ช่วงแรกใช้วิธี double-write แบบง่ายและ backfill หลังจาก downtime
    • แต่การได้มาซึ่งความสอดคล้อง 100% และการกู้คืนอัตโนมัติ จำเป็นต้องมี distributed consensus
    • จึงมีการพัฒนา ReplicatedMergeTree ที่ใช้ ZooKeeper เป็น metadata layer
  • ReplicatedMergeTree ทำให้ ClickHouse สามารถใช้งาน production สำหรับ query ที่ผู้ใช้เรียกโดยตรงได้ในปี 2014

เส้นทางสู่การเปิดเป็นโอเพนซอร์ส

  • ในปี 2014 ClickHouse ใช้งานจริงใน production เพื่อเก็บข้อมูลวันละหลายแสนล้านเรกคอร์ดและตอบ query แบบเรียลไทม์ให้ลูกค้า
  • นักวิทยาศาสตร์ข้อมูลภายในบริษัทใช้ ClickHouse คำนวณเทรนด์อินเทอร์เน็ต และยังมีการเปิดเผยเอกสารการใช้งานแบบพื้นฐานด้วย
  • ฝ่ายอื่น ๆ เช่น โฆษณา อีคอมเมิร์ซ infrastructure และการวิเคราะห์ธุรกิจ ก็เริ่มทดลองใช้ ClickHouse และย้ายบาง use case มาจาก MapReduce ภายใน MySQL และ Postgres
  • ปลายปี 2014 ClickHouse ถูกใช้อย่างแพร่หลายภายในบริษัทเดียว และมีกรณีพิเศษคือ CERN ที่นำไปใช้งานผ่านความร่วมมือใน LHCb experiment
  • ยังพบด้วยว่าวิศวกรในบริษัทอื่น ๆ ก็กำลังสร้างระบบคล้าย OLAPServer หรือ Metrage เพราะฐานข้อมูลที่มีอยู่ไม่รองรับ use case ของพวกเขาได้ดี
  • เมื่อมีการเผยแพร่บทความเกี่ยวกับ ClickHouse ในปี 2015 พร้อมฉบับแปล ก็ยิ่งยืนยันว่ามีความสนใจอยู่มาก
  • ก่อนเปิดเป็นสาธารณะ มีการเตรียมรายการข้อดีและความเสี่ยงที่อาจเกิดขึ้นเพื่อใช้โน้มน้าวผู้บริหารของบริษัท
  • หลังได้รับอนุมัติ ก็มีการเตรียมแผนรีลีส โลโก้แรก เว็บไซต์แรก บล็อกโพสต์ และ Debian repository ก่อนที่ ClickHouse จะเปิดสู่สาธารณะทั่วโลกในวันที่ 15 มิถุนายน 2016
  • ปัจจุบัน ClickHouse กลายเป็นฐานข้อมูลเชิงวิเคราะห์ยอดนิยมที่องค์กรขนาดใหญ่ทั่วโลกใช้งาน

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • ราว ๆ ปี 2017~2018 ฉันค้นพบ ClickHouse และทำ proof of concept เพื่อแทนที่ Elasticsearch ซึ่งภายในไม่กี่สัปดาห์ก็ได้ผลลัพธ์ว่าพื้นที่จัดเก็บและจำนวนคิวรีต่อวินาทีดีขึ้น 5 เท่า
    แต่ผู้บริหารปฏิเสธ เพราะมันยังไม่เป็นที่รู้จักและดูเหมือน “ฐานข้อมูลอะไรสักอย่างที่คนรัสเซียทำ”
    ส่วนตัวเสียดายมากที่เห็นรถไฟมาถึงเร็วขนาดนั้นแล้วกลับไม่ได้ขึ้น

    • ฉันเพิ่งเจออะไรคล้าย ๆ กันมาไม่นานนี้ ถ้าเปลี่ยนไปใช้ ClickHouse งานดูแลฐานข้อมูลจะลดลง 60% ไม่ต้องมีฐานข้อมูล time-series แยกต่างหาก และเวลา query จะลดจากประมาณ 300~500ms เหลือราว 75ms
      อัตราการบีบอัดก็มหาศาลมาก และ benchmark ต้นทุนสตอเรจลดลงจนอยู่ระดับค่าใช้จ่ายของ S3
      สรุปคือชั้นจัดเก็บข้อมูลที่เคยเสียหลายล้านดอลลาร์ต่อเดือน ลดลงเหลือระดับไม่กี่พันดอลลาร์ต่อเดือน
      ClickHouse ไม่ใช่ยาครอบจักรวาล แต่ถ้าเข้าใจว่าข้อมูลถูกเข้าถึงอย่างไรและจัดวางให้เหมาะสม ก็ได้ประสิทธิภาพมหาศาล
    • เราก็ติดอยู่กับ Elasticsearch เหมือนกัน อยากย้ายไป ClickHouse แต่ยังทำไม่ได้เพราะภาระงานเดิมที่มีอยู่
    • สงสัยว่าใช้กับการค้นหาแบบ grep ง่าย ๆ หรือจำเป็นต้องใช้การค้นหาขั้นสูงแบบ BM25
      เท่าที่เข้าใจ ClickHouse น่าจะช่วยได้แค่การค้นหาแบบ grep มากกว่า
    • มี ความเสี่ยงด้านซัพพลายเชน
    • สงสัยว่า ClickHouse ทำ search ได้หรือไม่ ถ้าไม่ได้ก็ไม่เข้าใจว่าทำไมถึงพยายามใช้แทน Elasticsearch

  • ในฐานะคนที่ใช้ TimescaleDB มานาน ClickHouse ให้ความรู้สึกสดใหม่มาก psql นั้นยอดเยี่ยม และการพึ่งพาระบบฐานข้อมูลเดียวสำหรับทุกอย่างก็ดี แต่ในแง่การดูแล migration และขั้นตอน deployment มันค่อนข้างเจ็บปวด
    TimescaleDB ยังให้ความรู้สึกว่าโครงสร้างเปลี่ยนไปทุกเวอร์ชัน และทิศทางการพัฒนาก็ค่อนข้างไม่นิ่ง จนบางครั้งรู้สึกเหมือนเป็นผลิตภัณฑ์ระดับ alpha quality

    • ฉันเคยใช้ TimescaleDB เมื่อนานมากแล้ว และดูเหมือนว่าหลังจากนั้นมันเปลี่ยนไปเยอะ ตอนนี้กำลังคิดจะอัปเกรด PostgreSQL เป็น TimescaleDB เพื่อเก็บข้อมูลเก่า พร้อมกับ deploy ClickHouse แบบขนานไปด้วย
      ยังลังเลอยู่ว่าจะใช้ PeerDB ทำ mirror ขนาดใหญ่ไปที่ ClickHouse หรือจะ deploy แยกโดยไม่เพิ่มชั้นที่เปราะบางอีกชั้น
      อยากรู้ว่าคุณถึงขั้นไม่แนะนำ TimescaleDB เลยหรือเปล่า เพราะ PostgreSQL เป็นส่วนที่แข็งแรงที่สุดในสแตกตอนนี้ และฉันอยากหลีกเลี่ยงความเจ็บปวดจากซอฟต์แวร์ระดับ alpha quality ให้แน่ชัด
    • ใน ecosystem ของ PostgreSQL เองก็มีงานจำนวนมากที่พยายามทำให้ “รันทุกอย่างในระบบเดียว” เป็นจริง ParadeDB เป็นหนึ่งในระบบที่ผลักดัน full-text search, vector search และการ aggregate แบบเบาที่ระดับดัชนี
      ฝั่ง DuckDB ก็มีงานอย่าง pg_duckdb และยังมี Xata ด้วย
      เผื่อบอกไว้ ฉันทำงานอยู่ที่ ParadeDB

  • เอนจิน metrics และ autoscaling ของ Cloud 66 ผ่านการทำซ้ำมา 5 รอบก่อนจะลงตัวที่ ClickHouse: Redis, Cassandra, ทำเองด้วย Ruby+RabbitMQ, ทำเองด้วย Go+RabbitMQ และสุดท้ายคือ ClickHouse
    แต่ละครั้งจะเจอข้อจำกัดบางอย่างหรือภาระการ optimize ที่รับไม่ไหว และ ClickHouse ก็เสถียรมากตลอด 4 ปีที่ผ่านมา

    • ยังนึกภาพไม่ค่อยออกว่ากำลังแก้ปัญหาอะไรอยู่ ชุด Redis, Cassandra, RabbitMQ, ClickHouse นี้มี RabbitMQ ที่ดูโดดออกมาเป็นพิเศษ

  • กว่าที่จะเปลี่ยน Loki มาเป็น ClickHouse ได้ สแตก observability ของเราถึงค่อยรู้สึกว่า “ลงตัว” จริง ๆ มันทรงพลังมากสำหรับ logs และคิวรีเชิงวิเคราะห์ทั่วไป

    • เราก็ใช้ LGTM แบบเต็มรูปแบบอยู่เหมือนกัน อันนี้น่าสนใจมาก แต่เราก็ใช้ Loki ได้ดีอยู่ เลยสงสัยว่านอกจาก SQL จะ expressive กว่า LogQL แล้ว ClickHouse เหนือกว่าตรงไหนอีก
    • สงสัยว่าทำ visualization กันอย่างไร ใช้ ClickStack หรือใช้อย่างอื่น

  • นอกจากจะเป็น ฐานข้อมูล OLAP ที่ยอดเยี่ยมแล้ว ตัวเชื่อมต่อในตัวที่ดึงข้อมูลจากแหล่งข้อมูลระยะไกลได้ก็เป็น game changer
    มันสามารถ import อัตโนมัติเป็นระยะจากโฟลเดอร์ S3 ที่มีไฟล์ Parquet/JSON อยู่ และยังเชื่อมต่อกับ Postgres ได้โดยตรง
    ใน data warehouse ของสำนักข่าวขนาดกลางแห่งหนึ่ง เราเปลี่ยนจากชุด Druid+Postgres+Trino มาเป็น ClickHouse node ใหญ่เพียงตัวเดียว และไม่เคยมองย้อนกลับไปอีกเลย
    มันเร็วกว่า ใช้งานจริงได้มากกว่า และดูแลรักษาน้อยกว่ามาก

  • ฉันชอบ ClickHouse มากจริง ๆ และประสิทธิภาพก็น่าประทับใจ แม้จะต้องปรับแต่งคิวรีบางตัวเพราะเหตุผลด้านประสิทธิภาพ แต่โดยรวมก็ดีกว่าที่คาดไว้
    ตอนแรกเราสร้าง ingestion ของ real-time pipeline ขึ้นมาเพื่อรับมือกับ incremental load ขนาดใหญ่ เพราะ Redshift ที่เคยใช้มาก่อนนั้นทั้งแพงและค่อนข้างช้า
    แต่จนถึงตอนนี้ ClickHouse จัดการข้อมูลจำนวนมากและการแปลงข้อมูลขนาดใหญ่ได้สบายมาก จน pipeline นั้นไม่จำเป็นแล้ว
    ปัญหาเดียวคือมีฟีเจอร์ tracing ที่ค่อนข้างหนักเปิดอยู่ในค่าเริ่มต้น และบนเครื่องที่ค่อนข้างเล็กมันทำให้ประสิทธิภาพตกลงมาก
    หลังจากนั้นเราขยายขนาดระบบ และตอนนี้มันกลายเป็นหัวใจของ data stack ไปแล้ว
    ถ้าเป็นสเกลใหญ่มากจริง ๆ อาจเลือกอย่างอื่น แต่ตราบใดที่ยังอยู่ระดับไม่กี่ node ความซับซ้อนก็ยังจัดการได้และใช้งานสนุก

    • สงสัยว่าฟีเจอร์ tracing หนัก ๆ ที่ว่าเปิดไว้โดยค่าเริ่มต้นนั้นคืออะไร

  • ข้อความที่ว่า “คุณสามารถเปิด pull request ในฐานะการทดลองได้โดยไม่จำเป็นต้องหวังว่าจะถูก merge และมันจะได้รับการตรวจสอบในระดับเดียวกับ release สำหรับ production คุณเจอ memory allocator, compression library, hash table, data format หรือ sorting algorithm ตัวใหม่หรือไม่? เอาเข้ามาใน ClickHouse แล้วมันจะเผยทุกอย่างออกมา” นี่สุดยอดมาก

    • ฉันเป็นนักพัฒนา ClickHouse และคำพูดนี้เป็นเรื่องจริง ClickHouse มีส่วนช่วยค้นพบบั๊กในไลบรารี third-party หลายตัว และเท่าที่ฉันจัดการเองก็มี jemalloc กับ librdkafka
      มันยังพบบั๊กใน Linux kernel และแทบทุกที่อีกด้วย
      เรามี fuzzer ที่เข้มงวดมาก มีหลายตัวทำงานในหลายระดับ และรันทดสอบด้วยชุดการตั้งค่าจำนวนมหาศาลแบบไม่น่าเชื่อ
      ตัวเลขล่าสุดที่ฉันได้ยินเมื่อประมาณหนึ่งปีก่อนคือ การรัน CI แบบเต็มใช้เวลารวมราว 400 ชั่วโมง ต่อหนึ่ง commit เดี่ยว
      เพราะงั้นมันจึงบ้าดีเดือดในทางที่ดีพอสมควร

  • น่าสนใจที่บทความบล็อกยก SQLite กับ Ladybird มาไว้บนสเปกตรัม แต่กลับละ DuckDB ซึ่งเป็นคู่แข่งโอเพนซอร์สหลักออกไป
    ฉันเห็นด้วยว่า ความไว้วางใจต้องผ่าน 3 ขั้น
    แต่ถ้าจะอยู่รอดได้ในยุคของฐานข้อมูลที่ทำด้วย vibe coding ก็ต้องคิดโมเดลธุรกิจใหม่ขึ้นมา

    • ฉันคิดว่าข้อได้เปรียบหลักที่ ClickHouse มีเหนือ DuckDB คือ ตระกูล MergeTree มันสามารถจัดเรียงข้อมูลในเบื้องหลังได้ และถ้าใช้อย่างถูกต้องก็ให้ทั้งอัตราการบีบอัดและประสิทธิภาพที่สูงแบบเหลือเชื่อ
      เวลาคิวรีคอลัมน์ที่ไม่ได้ทำดัชนี ClickHouse อาจเร็วกว่า DuckDB ที่คิวรี Parquet ได้ง่าย ๆ ถึง 10 เท่า และเมื่อแตะ primary key แล้วก็แทบเทียบกันไม่ได้ในแง่ความเร็ว
      มีบทความเปรียบเทียบทั้งสองอยู่มาก แต่ในความเป็นจริง ClickHouse กับ DuckDB อยู่กันคนละพื้นที่โดยสิ้นเชิง
      DuckDB เป็นเอนจินวิเคราะห์ที่ทรงพลัง ส่วน ClickHouse เป็นระบบจัดการฐานข้อมูลเต็มรูปแบบที่มีทั้งการทำ replication และเอนจิน MergeTree เป็นต้น
    • ClickHouse สามารถย่อขนาดลงมาแข่งขันกับ DuckDB ได้ แต่ฉันไม่แน่ใจว่า DuckDB จะขยายขึ้นไปใหญ่แบบ ClickHouse ได้หรือไม่
      คนส่วนใหญ่ไม่ได้มีปัญหาเรื่องสเกลแบบนั้น แต่ถ้ามีขึ้นมา ความต่างจะชัดเจนมาก

  • น่าเสียดายที่ในหน้าดังกล่าวดูเหมือนจะไม่ค่อยอยากบอกว่า “การประมวลผลข้อมูลสำหรับระบบวิเคราะห์เว็บคล้าย Google Analytics” นั้นจริง ๆ แล้วเคยถูกใช้ที่ Yandex

    • ดูเหมือนในส่วนอื่นของหน้าก็พยายามเลี่ยงการพูดถึง Yandex เหมือนกัน ฉันไม่แน่ใจด้วยซ้ำว่ามีการพูดถึง Yandex สักครั้งไหม
      อาจเป็นเพราะไม่ต้องการโฆษณาบริษัทนั้น แต่ก็ไม่ค่อยเข้าใจว่าทำไมเรื่องนั้นถึงน่าเศร้านัก

  • ClickHouse เคยเป็น game changer ในหลายบริษัทที่ฉันเคยทำงานด้วย มันทำให้นึกถึงตอนเกี่ยวกับการนำ Rust มาใช้ในพอดแคสต์ Rust in Production
    https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1