ในโลกของการประมวลผลข้อมูลปริมาณสูง บทความทางเทคนิคล่าสุดที่บรรยายการเดินทางของบริษัทหนึ่งจากการบันทึกคำขอระดับล้านไปสู่พันล้านรายการ ได้จุดประกายการอภิปรายอย่างเข้มข้นในหมู่ผู้เชี่ยวชาญด้านฐานข้อมูล ผู้เขียนเดิมได้อธิบายโซลูชันที่ซับซ้อนซึ่งเกี่ยวข้องกับ Kafka, Vector และ ClickHouse แต่ชุมชนนักพัฒนากลับตั้งคำถามอย่างรวดเร็วว่าทางเลือกที่เรียบง่ายกว่าอาจจะเพียงพอแล้วหรือไม่
หัวข้อหลักของการอภิปรายด้านสถาปัตยกรรม
ชุมชนทางเทคนิคได้ตั้งคำถามสำคัญเกี่ยวกับความจำเป็นของสถาปัตยกรรมสามส่วนนี้ ผู้แสดงความคิดเห็นหลายคนชี้ให้เห็นถึงฟีเจอร์ async_insert ในตัวของ ClickHouse ว่าเป็นโซลูชันที่มีศักยภาพสำหรับข้อผิดพลาด TOO_MANY_PARTS ที่สร้างปัญหาให้กับการใช้งานในครั้งแรก ฟีเจอร์นี้ช่วยให้ฐานข้อมูลสามารถจัดกลุ่มการเขียนข้อมูลขาเข้าได้โดยอัตโนมัติ ซึ่งช่วยลดจำนวนส่วนที่ก่อให้เกิดปัญหาความไม่มั่นคงก่อนหน้านี้ ฉันทามติของชุมชนชี้ให้เห็นว่าการออกแบบโครงสร้างข้อมูลที่เหมาะสมด้วยคีย์การแบ่งพาร์ทิชันและคีย์หลักที่เหมาะสมสามารถป้องกันปัญหาต่างๆ ในช่วงเริ่มต้นได้โดยไม่จำเป็นต้องมีส่วนประกอบโครงสร้างพื้นฐานเพิ่มเติม
ปัญหาหลักคือคีย์หลักของ merge tree คุณตั้งค่าผิด ClickHouse async_insert น่าจะแก้ไขปัญหาทั้งหมดของคุณได้แล้ว
ปัญหาทั่วไปของ ClickHouse ที่มีการกล่าวถึง
- ข้อผิดพลาด TOO_MANY_PARTS จากการแทรกข้อมูลที่รวดเร็ว
- การออกแบบ schema ที่ไม่ดี (partition key และ primary key)
- การใช้หน่วยความจำสูงในระหว่างการนำเข้าข้อมูล
- ปัญหาเสถียรภาพกับการผสานรวม Kafka แบบ native
- กลยุทธ์การโยกย้ายข้อมูลที่ซับซ้อน
การตั้งคำถามเกี่ยวกับสแต็กของส่วนประกอบ
ผู้ใช้ ClickHouse ที่มีประสบการณ์หลายคนแสดงความสับสนเกี่ยวกับบทบาทของแต่ละส่วนประกอบในสถาปัตยกรรมสุดท้าย ความคิดเห็นระบุว่า Vector มีความสามารถในการบัฟเฟอร์ในตัวอยู่แล้ว ทำให้การมี Kafka อาจซ้ำซ้อนสำหรับกรณีการใช้งานนี้ ในทางกลับกัน บางคนตั้งข้อสังเกตว่า ClickHouse สามารถรับข้อมูลจาก Kafka โดยตรงได้ผ่านการผสานรวมแบบเนทีฟ ซึ่งทำให้เกิดคำถามว่าทำไมถึงจำเป็นต้องมี Vector ด้วย สิ่งนี้นำไปสู่การอภิปรายว่าโซลูชันดังกล่าวได้กลายเป็นสิ่งที่ออกแบบให้ซับซ้อนเกินไปสำหรับปัญหาที่โดยพื้นฐานแล้วเป็นเพียงการนำเข้าข้อมูลปริมาณสูงหรือไม่
การอภิปรายได้ขยายไปถึงกลยุทธ์การบัฟเฟอร์ทางเลือก โดยมีข้อเสนอแนะตั้งแต่โซลูชันที่ใช้ Redis ไปจนถึงเครื่องมือเฉพาะทางอย่าง kittenhouse ผู้แสดงความคิดเห็นบางคนได้แบ่งปันการใช้งานที่ประสบความสำเร็จของพวกเขาเองโดยใช้สถาปัตยกรรมที่เรียบง่ายกว่า โดยมีผู้หนึ่งระบุถึงประสิทธิภาพที่น่าประทับใจ: ฉันรู้สึกทึ่งกับประสิทธิภาพอยู่แล้ว (200ms ในการสอบถามสิ่งที่ Postgres ใช้เวลา 500-600ms) แต่แล้วฉันก็ตระหนักว่าฉันยังไม่ได้ใส่ดัชนีในตาราง Clickhouse ตอนนี้คำขอส่งคืนผลใน 50-70ms
การเปรียบเทียบประสิทธิภาพของ ClickHouse
- คิวรี PostgreSQL เดิม: 500-600ms
- ClickHouse แบบไม่มีดัชนี: 200ms
- ClickHouse แบบมีดัชนี: 50-70ms (รวมเวลาเครือข่าย)
กลยุทธ์การโยกย้ายและการเลือกเครื่องมือ
สมาชิกในชุมชนยังตั้งคำถามเกี่ยวกับแนวทางการโยกย้ายข้อมูล โดยเฉพาะอย่างยิ่งการตัดสินใจนำ Kafka เข้ามาเป็นส่วนประกอบถาวรของสถาปัตยกรรมสำหรับสิ่งที่ดูเหมือนจะเป็นข้อกำหนดการเขียนคู่ขนานชั่วคราวในช่วงการโยกย้าย หลายคนแนะนำว่าการเขียนข้อมูลไปยังทั้ง MariaDB และ ClickHouse พร้อมกันในช่วงเปลี่ยนผ่านน่าจะเพียงพอแล้ว โดยไม่ต้องยึดติดกับความซับซ้อนในการดำเนินงานของการดูแลคลัสเตอร์ Kafka ในระยะยาว
การอภิปรายเผยให้เห็นว่าในขณะที่โซลูชันที่เลือกใช้งานได้ แต่วิศวกรที่มีประสบการณ์หลายคนเชื่อว่าแนวทางที่เรียบง่ายกว่าสามารถบรรลุผลลัพธ์ที่คล้ายกันได้ด้วยภาระการดำเนินงานที่น้อยกว่า ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุไว้ Kafka + Vector เป็นโซลูชันที่ไม่ถูกต้องอย่างแน่นอน ปัญหาหลักของพวกเขาคือโครงสร้างตารางปลายทางและการเลือกคีย์หลัก + การแบ่งพาร์ทิชันที่แย่มาก
ทางเลือกอื่นที่เสนอโดยชุมชน
- ฟีเจอร์ async_insert ของ ClickHouse
- ตาราง Buffer ที่มีการกำหนดค่าที่เหมาะสม
- การบัฟเฟอร์ด้วย Redis พร้อม cron jobs
- Kittenhouse (เครื่องมือบัฟเฟอร์เฉพาะทาง)
- การเชื่อมต่อ Kafka กับ ClickHouse โดยตรง
- การเขียนข้อมูลแบบคู่ไปยังฐานข้อมูลต้นทางและ ClickHouse ในระหว่างการย้ายข้อมูล
การแลกเปลี่ยนของการเลือกทางสถาปัตยกรรม
บทสนทนาได้เน้นย้ำถึงความตึงเครียดที่สำคัญในการตัดสินใจทางวิศวกรรม นั่นคือความสมดุลระหว่างการใช้โซลูชันที่พิสูจน์แล้วแต่ซับซ้อน กับการปรับให้เหมาะสมเพื่อความเรียบง่าย บางคนปกป้องแนวทางเดิม โดยระบุว่าการใช้โซลูชันที่ค่อนข้างซับซ้อนมากขึ้นซึ่งเกี่ยวข้องกับสถาปัตยกรรมเพิ่มเติม แต่ได้รับการทดลองและทดสอบโดยบุคคลที่สามที่คุณไว้วางใจ บางครั้งก็สามารถให้ผลลัพธ์สุดท้ายที่เหมาะสมกว่าได้ ความมั่นใจมักมีน้ำหนักมากกว่าความเรียบง่าย
สิ่งนี้สะท้อนให้เห็นถึงรูปแบบทั่วไปในความท้าทายในการขยายขนาด สิ่งที่เริ่มต้นจากการเปลี่ยนฐานข้อมูลแบบตรงไปตรงมา มักจะพัฒนากลายเป็นการทบทวนสถาปัตยกรรมในวงกว้าง การอภิปรายของชุมชนทำหน้าที่เป็นกรณีศึกษาที่มีค่าเกี่ยวกับวิธีที่ทีมวิศวกรรมต่างๆ อาจเข้าใกล้ปัญหาเดียวกันด้วยปรัชญาที่แตกต่างกันเกี่ยวกับความซับซ้อน ความสามารถในการบำรุงรักษา และภาระการดำเนินงาน
บทสนทนาที่ยังคงดำเนินอยู่แสดงให้เห็นว่าแม้จะมีเทคโนโลยีที่成熟 อย่าง ClickHouse ก็ไม่มีโซลูชันใดที่เหมาะกับทุกกรณีสำหรับการปรับขนาดระบบข้อมูล สถาปัตยกรรมที่เหมาะสมที่สุดขึ้นอยู่กับกรณีการใช้งานเฉพาะ ทักษะความเชี่ยวชาญของทีม และการพิจารณาการบำรุงรักษาระยะยาว เป็นอย่างมาก มากกว่าที่จะขึ้นอยู่กับขีดความสามารถทางเทคนิคเพียงอย่างเดียว