ในช่วงไม่กี่ปีที่ผ่านมา ฐานข้อมูลอนุกรมเวลาได้เปลี่ยนจากสิ่งที่แปลกประหลาด (ซึ่งมีความเชี่ยวชาญสูงที่ใช้ทั้งในระบบตรวจสอบแบบเปิด (และเชื่อมโยงกับโซลูชันเฉพาะ) หรือในโครงการ Big Data) ให้กลายเป็น "ผลิตภัณฑ์ผู้บริโภค" ในอาณาเขตของสหพันธรัฐรัสเซียต้องขอขอบคุณ Yandex และ ClickHouse เป็นพิเศษสำหรับสิ่งนี้ จนถึงจุดนี้ หากคุณต้องการจัดเก็บข้อมูลอนุกรมเวลาจำนวนมาก คุณจะต้องตกลงกับความจำเป็นในการสร้างสแต็ก Hadoop ขนาดใหญ่และดูแลรักษามัน หรือสื่อสารกับโปรโตคอลแต่ละระบบสำหรับแต่ละระบบ
อาจดูเหมือนว่าในปี 2019 บทความที่ TSDB น่าใช้จะมีเพียงประโยคเดียว: “แค่ใช้ ClickHouse” แต่... มีความแตกต่าง
แท้จริงแล้ว ClickHouse กำลังพัฒนาอย่างแข็งขัน ฐานผู้ใช้กำลังเติบโต และการสนับสนุนก็มีบทบาทอย่างมาก แต่เราได้กลายเป็นตัวประกันต่อความสำเร็จสาธารณะของ ClickHouse ซึ่งบดบังโซลูชันอื่น ๆ ที่อาจมีประสิทธิผล/เชื่อถือได้มากกว่าหรือไม่
เมื่อต้นปีที่แล้ว เราได้เริ่มปรับปรุงระบบการตรวจสอบของเราเอง ซึ่งในระหว่างนั้นก็มีคำถามเกิดขึ้นเกี่ยวกับการเลือกฐานข้อมูลที่เหมาะสมสำหรับการจัดเก็บข้อมูล ฉันต้องการพูดคุยเกี่ยวกับประวัติของตัวเลือกนี้ที่นี่
คำแถลงปัญหา
ก่อนอื่น คำนำที่จำเป็น เหตุใดเราจึงต้องมีระบบการตรวจสอบของเราเอง และได้รับการออกแบบอย่างไร?
เราเริ่มให้บริการสนับสนุนในปี 2008 และในปี 2010 เป็นที่ชัดเจนว่าเป็นการยากที่จะรวบรวมข้อมูลเกี่ยวกับกระบวนการที่เกิดขึ้นในโครงสร้างพื้นฐานไคลเอนต์ด้วยโซลูชันที่มีอยู่ในเวลานั้น (เรากำลังพูดถึง พระเจ้ายกโทษให้ฉัน Cacti, Zabbix และกราไฟท์ที่เกิดขึ้นใหม่)
ข้อกำหนดหลักของเราคือ:
- การสนับสนุน (ในเวลานั้น - หลายสิบและในอนาคต - หลายร้อย) ลูกค้าภายในระบบเดียวและในขณะเดียวกันก็มีระบบการจัดการการแจ้งเตือนแบบรวมศูนย์
- ความยืดหยุ่นในการจัดการระบบการแจ้งเตือน (การเพิ่มการแจ้งเตือนระหว่างเจ้าหน้าที่ประจำการ การกำหนดเวลา ฐานความรู้)
- ความสามารถในการแสดงกราฟที่มีรายละเอียดเชิงลึก (ในขณะนั้น Zabbix แสดงกราฟในรูปแบบของรูปภาพ)
- การจัดเก็บข้อมูลจำนวนมากในระยะยาว (หนึ่งปีหรือมากกว่า) และความสามารถในการดึงข้อมูลได้อย่างรวดเร็ว
ในบทความนี้เราสนใจประเด็นสุดท้าย
เมื่อพูดถึงการจัดเก็บข้อกำหนดมีดังนี้:
- ระบบจะต้องทำงานได้อย่างรวดเร็ว
- เป็นที่พึงประสงค์ว่าระบบมีอินเทอร์เฟซ SQL
- ระบบจะต้องมีเสถียรภาพและมีฐานผู้ใช้และการสนับสนุนที่ใช้งานอยู่ (เมื่อเราเผชิญกับความจำเป็นในการรองรับระบบเช่น MemcacheDB ซึ่งไม่ได้รับการพัฒนาอีกต่อไป หรือ MooseFS ที่เก็บข้อมูลแบบกระจาย ซึ่งมีตัวติดตามจุดบกพร่องที่ถูกเก็บไว้เป็นภาษาจีน: เราทำซ้ำเรื่องราวนี้สำหรับโครงการของเราที่ไม่ต้องการ);
- การปฏิบัติตามทฤษฎีบท CAP: ความสอดคล้อง (จำเป็น) - ข้อมูลจะต้องทันสมัย เราไม่ต้องการให้ระบบการจัดการการแจ้งเตือนไม่รับข้อมูลใหม่และคายการแจ้งเตือนเกี่ยวกับการไม่มาถึงของข้อมูลสำหรับทุกโครงการ Partition Tolerance (จำเป็น) - เราไม่ต้องการระบบ Split Brain ความพร้อมใช้งาน (ไม่สำคัญ หากมีแบบจำลองที่ใช้งานอยู่) - เราสามารถสลับไปใช้ระบบสำรองข้อมูลได้ด้วยตนเองในกรณีที่เกิดอุบัติเหตุ โดยใช้รหัส
น่าแปลกที่ในเวลานั้น MySQL กลายเป็นทางออกที่ดีสำหรับเรา โครงสร้างข้อมูลของเราเรียบง่ายมาก: รหัสเซิร์ฟเวอร์ รหัสตัวนับ การประทับเวลา และค่า การสุ่มตัวอย่างข้อมูลร้อนอย่างรวดเร็วได้รับการรับรองโดยพูลบัฟเฟอร์ขนาดใหญ่ และการสุ่มตัวอย่างข้อมูลในอดีตได้รับการรับรองโดย SSD
ดังนั้นเราจึงได้ตัวอย่างข้อมูลใหม่สองสัปดาห์ โดยมีรายละเอียดเหลือเพียง 200 มิลลิวินาทีก่อนที่ข้อมูลจะแสดงผลอย่างสมบูรณ์ และอยู่ในระบบนี้เป็นเวลานาน
ในขณะเดียวกัน เวลาผ่านไปและปริมาณข้อมูลก็เพิ่มขึ้น ภายในปี 2016 ปริมาณข้อมูลสูงถึงหลายสิบเทราไบต์ ซึ่งเป็นค่าใช้จ่ายที่สำคัญในบริบทของพื้นที่จัดเก็บข้อมูล SSD ที่เช่า
มาถึงตอนนี้ฐานข้อมูลแบบเรียงเป็นแนวแพร่หลายอย่างแพร่หลายซึ่งเราเริ่มคิดอย่างแข็งขัน: ในฐานข้อมูลแบบเรียงเป็นแนวข้อมูลจะถูกจัดเก็บในคอลัมน์ตามที่คุณเข้าใจและถ้าคุณดูข้อมูลของเราก็จะง่ายต่อการดูข้อมูลขนาดใหญ่ จำนวนรายการที่ซ้ำกันที่สามารถทำได้ หากคุณใช้ฐานข้อมูลแบบเรียงเป็นแนว ให้บีบอัดโดยใช้การบีบอัด
อย่างไรก็ตาม ระบบหลักของบริษัทยังคงทำงานได้อย่างเสถียร และฉันไม่ต้องการทดลองเปลี่ยนไปใช้ระบบอื่น
ในปี 2017 ที่การประชุม Percona Live ในซานโฮเซ นักพัฒนา Clickhouse อาจจะประกาศตัวเองเป็นครั้งแรก เมื่อมองแวบแรก ระบบก็พร้อมสำหรับการผลิต (เช่น Yandex.Metrica เป็นระบบการผลิตที่รุนแรง) การสนับสนุนทำได้อย่างรวดเร็วและง่ายดาย และที่สำคัญที่สุดคือ การดำเนินการก็ง่ายดาย ตั้งแต่ปี 2018 เราได้เริ่มกระบวนการเปลี่ยนแปลง แต่เมื่อถึงเวลานั้น มีระบบ TSDB “สำหรับผู้ใหญ่” และผ่านการทดสอบตามเวลาจำนวนมาก และเราตัดสินใจที่จะสละเวลาพอสมควรและเปรียบเทียบทางเลือกอื่นเพื่อให้แน่ใจว่าไม่มีทางเลือกอื่นสำหรับ Clickhouse ตามความต้องการของเรา
นอกเหนือจากข้อกำหนดการจัดเก็บที่ระบุไว้แล้ว ยังมีข้อกำหนดใหม่อีกด้วย:
- ระบบใหม่ควรให้ประสิทธิภาพอย่างน้อยเท่ากับ MySQL บนฮาร์ดแวร์จำนวนเท่ากัน
- การจัดเก็บระบบใหม่ควรใช้พื้นที่น้อยลงอย่างมาก
- DBMS จะต้องยังง่ายต่อการจัดการ
- ฉันต้องการเปลี่ยนแอปพลิเคชันให้น้อยที่สุดเมื่อเปลี่ยน DBMS
เราเริ่มพิจารณาระบบอะไรบ้าง?
อาปาเช่ไฮฟ์/อาปาเช่อิมพาลา
สแต็ก Hadoop เก่าที่ผ่านการทดสอบการต่อสู้แล้ว โดยพื้นฐานแล้ว มันเป็นอินเทอร์เฟซ SQL ที่สร้างขึ้นจากการจัดเก็บข้อมูลในรูปแบบดั้งเดิมบน HDFS
จุดเด่น
- ด้วยการทำงานที่เสถียร ทำให้ปรับขนาดข้อมูลได้ง่ายมาก
- มีโซลูชันคอลัมน์สำหรับการจัดเก็บข้อมูล (พื้นที่น้อยกว่า)
- ดำเนินงานคู่ขนานได้รวดเร็วมากเมื่อมีทรัพยากรเพียงพอ
จุดด้อย
- มันคือ Hadoop และมันใช้งานยาก หากเราไม่พร้อมที่จะใช้โซลูชั่นสำเร็จรูปบนคลาวด์ (และเราไม่พร้อมในเรื่องต้นทุน) สแตกทั้งหมดจะต้องได้รับการประกอบและสนับสนุนโดยมือของผู้ดูแลระบบ และเราไม่ต้องการจริงๆ นี้.
- ข้อมูลถูกรวบรวม .
แต่:
ความเร็วทำได้โดยการปรับขนาดจำนวนเซิร์ฟเวอร์คอมพิวเตอร์ พูดง่ายๆ ก็คือ หากเราเป็นบริษัทขนาดใหญ่ที่มีส่วนร่วมในการวิเคราะห์ และเป็นสิ่งสำคัญสำหรับธุรกิจในการรวบรวมข้อมูลโดยเร็วที่สุด (แม้จะต้องเสียค่าใช้จ่ายในการใช้ทรัพยากรคอมพิวเตอร์จำนวนมาก) นี่อาจเป็นทางเลือกของเรา แต่เรายังไม่พร้อมที่จะเพิ่มจำนวนฮาร์ดแวร์เพื่อเร่งงาน
ดรูอิด/ปิโนต์
มีข้อมูลเพิ่มเติมมากมายเกี่ยวกับ TSDB โดยเฉพาะ แต่นั่นก็คือสแต็ก Hadoop
มี .
พูดง่ายๆ ก็คือ Druid/Pinot ดูดีกว่า Clickhouse ในกรณีที่:
- คุณมีลักษณะของข้อมูลที่แตกต่างกัน (ในกรณีของเรา เราบันทึกเฉพาะอนุกรมเวลาของการวัดเซิร์ฟเวอร์ และอันที่จริง นี่คือตารางเดียว แต่อาจมีกรณีอื่น ๆ เช่น อนุกรมเวลาของอุปกรณ์ อนุกรมเวลาทางเศรษฐกิจ ฯลฯ - แต่ละอันมี โครงสร้างของตัวเองซึ่งจำเป็นต้องรวบรวมและประมวลผล)
- นอกจากนี้ยังมีข้อมูลจำนวนมากอีกด้วย
- ตารางและข้อมูลที่มีอนุกรมเวลาปรากฏขึ้นและหายไป (นั่นคือ ชุดข้อมูลบางชุดที่มาถึง ถูกวิเคราะห์และลบ)
- ไม่มีเกณฑ์ที่ชัดเจนในการแบ่งพาร์ติชันข้อมูล
ในกรณีตรงกันข้าม ClickHouse ทำงานได้ดีกว่า และนี่คือกรณีของเรา
คลิกเฮาส์
- เหมือน SQL
- ง่ายต่อการจัดการ
- มีคนบอกว่ามันได้ผล
ได้รับการคัดเลือกให้ทำการทดสอบ
InfluxDB
ทางเลือกต่างประเทศสำหรับ ClickHouse ข้อเสีย: ความพร้อมใช้งานสูงมีอยู่ในเวอร์ชันเชิงพาณิชย์เท่านั้น แต่จำเป็นต้องเปรียบเทียบ
ได้รับการคัดเลือกให้ทำการทดสอบ
คาสซานดรา
ในด้านหนึ่ง เรารู้ว่ามันถูกใช้เพื่อจัดเก็บอนุกรมเวลาแบบเมตริกโดยระบบติดตามเช่น ตัวอย่างเช่น หรือ OkMeter อย่างไรก็ตาม มีความเฉพาะเจาะจง
Cassandra ไม่ใช่ฐานข้อมูลแบบเรียงเป็นแนวในความหมายดั้งเดิม ดูเหมือนมุมมองแถวมากกว่า แต่แต่ละบรรทัดสามารถมีจำนวนคอลัมน์ที่แตกต่างกันได้ ทำให้ง่ายต่อการจัดระเบียบมุมมองแบบเรียงเป็นแนว ในแง่นี้ เป็นที่ชัดเจนว่าด้วยขีดจำกัด 2 พันล้านคอลัมน์ จึงเป็นไปได้ที่จะจัดเก็บข้อมูลบางส่วนไว้ในคอลัมน์ (และอนุกรมเวลาเดียวกัน) ตัวอย่างเช่น ใน MySQL มีการจำกัดคอลัมน์ไว้ที่ 4096 คอลัมน์ และเป็นเรื่องง่ายที่จะสะดุดกับข้อผิดพลาดด้วยรหัส 1117 หากคุณพยายามทำแบบเดียวกัน
กลไก Cassandra มุ่งเน้นไปที่การจัดเก็บข้อมูลจำนวนมากในระบบแบบกระจายโดยไม่มีต้นแบบ และทฤษฎีบท Cassandra CAP ที่กล่าวถึงข้างต้นมีเรื่องเกี่ยวกับ AP มากกว่า นั่นคือเกี่ยวกับความพร้อมใช้งานของข้อมูลและการต้านทานต่อการแบ่งพาร์ติชัน ดังนั้นเครื่องมือนี้จึงมีประโยชน์มากหากคุณต้องการเขียนลงในฐานข้อมูลนี้และไม่ค่อยได้อ่านจากฐานข้อมูลนั้น และนี่ก็สมเหตุสมผลที่จะใช้ Cassandra เป็นที่เก็บข้อมูล "เย็น" นั่นคือเป็นสถานที่ที่เชื่อถือได้ในระยะยาวในการจัดเก็บข้อมูลทางประวัติศาสตร์จำนวนมากซึ่งไม่ค่อยจำเป็น แต่สามารถเรียกคืนได้หากจำเป็น อย่างไรก็ตามเพื่อความสมบูรณ์เราจะทดสอบด้วย แต่อย่างที่ฉันได้กล่าวไว้ก่อนหน้านี้ ไม่มีความปรารถนาที่จะเขียนโค้ดใหม่สำหรับโซลูชันฐานข้อมูลที่เลือก ดังนั้นเราจะทดสอบมันค่อนข้างจำกัด - โดยไม่ต้องปรับโครงสร้างฐานข้อมูลให้เข้ากับข้อมูลเฉพาะของ Cassandra
โพร
ด้วยความอยากรู้อยากเห็น เราจึงตัดสินใจทดสอบประสิทธิภาพของพื้นที่จัดเก็บข้อมูล Prometheus เพียงเพื่อทำความเข้าใจว่าเราเร็วกว่าหรือช้ากว่าโซลูชันปัจจุบันและมากน้อยเพียงใด
วิธีการทดสอบและผลลัพธ์
ดังนั้นเราจึงทดสอบ 5 ฐานข้อมูลในการกำหนดค่า 6 รายการต่อไปนี้: ClickHouse (1 โหนด), ClickHouse (ตารางแบบกระจายสำหรับ 3 โหนด), InfluxDB, Mysql 8, Cassandra (3 โหนด) และ Prometheus แผนการทดสอบมีดังนี้:
- อัปโหลดข้อมูลประวัติเป็นเวลาหนึ่งสัปดาห์ (840 ล้านค่าต่อวัน 208 เมตริก)
- เราสร้างโหลดการบันทึก (พิจารณาโหมดโหลด 6 โหมด ดูด้านล่าง)
- ควบคู่ไปกับการบันทึก เราจะทำการเลือกเป็นระยะๆ โดยเลียนแบบคำขอของผู้ใช้ที่ทำงานกับแผนภูมิ เพื่อไม่ให้สิ่งต่าง ๆ ซับซ้อนมากเกินไป เราเลือกข้อมูลสำหรับ 10 ตัวชี้วัด (นั่นคือจำนวนที่มีอยู่ในกราฟ CPU) เป็นเวลาหนึ่งสัปดาห์
เราโหลดโดยจำลองพฤติกรรมของเอเจนต์การตรวจสอบของเรา ซึ่งจะส่งค่าไปยังแต่ละเมตริกทุกๆ 15 วินาที ในขณะเดียวกัน เราก็สนใจที่จะเปลี่ยนแปลง:
- จำนวนตัวชี้วัดทั้งหมดที่เขียนข้อมูล
- ช่วงเวลาในการส่งค่าไปยังหนึ่งเมตริก
- ขนาดชุด
เกี่ยวกับขนาดชุด เนื่องจากไม่แนะนำให้โหลดฐานข้อมูลทดลองเกือบทั้งหมดของเราด้วยการแทรกเดี่ยว เราจึงจำเป็นต้องมีรีเลย์ที่รวบรวมตัววัดที่เข้ามาและจัดกลุ่มให้เป็นกลุ่มและเขียนลงในฐานข้อมูลเป็นการแทรกแบบแบตช์
นอกจากนี้ เพื่อให้เข้าใจวิธีตีความข้อมูลที่ได้รับได้ดีขึ้น ลองจินตนาการว่าเราไม่ได้เพียงส่งตัววัดจำนวนมากเท่านั้น แต่ตัววัดถูกจัดเป็นเซิร์ฟเวอร์ - 125 ตัววัดต่อเซิร์ฟเวอร์ ที่นี่เซิร์ฟเวอร์เป็นเพียงเอนทิตีเสมือน - เพียงเพื่อให้เข้าใจว่า ตัวอย่างเช่น 10000 ตัววัดสอดคล้องกับเซิร์ฟเวอร์ประมาณ 80 เครื่อง
และนี่คือโหมดโหลดการเขียนฐานข้อมูล 6 โหมดของเราโดยคำนึงถึงทั้งหมดนี้:
มีสองจุดที่นี่ ประการแรก สำหรับ Cassandra ขนาดแบตช์เหล่านี้ใหญ่เกินไป เราจึงใช้ค่า 50 หรือ 100 ที่นั่น และประการที่สอง เนื่องจาก Prometheus ทำงานในโหมดดึงอย่างเคร่งครัด เช่น ตัวมันเองไปและรวบรวมข้อมูลจากแหล่งเมตริก (และแม้แต่เกตเวย์แม้จะชื่อ แต่ก็ไม่ได้เปลี่ยนสถานการณ์โดยพื้นฐาน) โหลดที่เกี่ยวข้องถูกนำไปใช้โดยใช้การกำหนดค่าแบบคงที่รวมกัน
ผลการทดสอบมีดังนี้:
สิ่งที่ควรค่าแก่การสังเกต: ตัวอย่างที่รวดเร็วอย่างน่าอัศจรรย์จาก Prometheus, ตัวอย่างที่ช้ามากจาก Cassandra, ตัวอย่างที่ช้าอย่างไม่อาจยอมรับได้จาก InfluxDB; ในแง่ของความเร็วในการบันทึก ClickHouse ชนะทุกคนและ Prometheus ไม่ได้เข้าร่วมการแข่งขันเพราะมันสร้างส่วนแทรกขึ้นมาเองและเราไม่ได้วัดอะไรเลย
เป็นผลให้: ClickHouse และ InfluxDB แสดงให้เห็นว่าตัวเองดีที่สุด แต่คลัสเตอร์จาก Influx สามารถสร้างได้บนพื้นฐานของเวอร์ชัน Enterprise เท่านั้น ซึ่งต้องเสียเงิน ในขณะที่ ClickHouse ไม่มีค่าใช้จ่ายใด ๆ และผลิตในรัสเซีย เป็นเหตุผลที่ในสหรัฐอเมริกา ตัวเลือกนั้นน่าจะเข้าข้าง inInfluxDB และในประเทศของเรา ตัวเลือกนี้ก็เข้าข้าง ClickHouse
ที่มา: will.com