เป็นระบบจัดการฐานข้อมูลเรียงเป็นแนวโอเพ่นซอร์สสำหรับการประมวลผลแบบสอบถามเชิงวิเคราะห์ออนไลน์ (OLAP) ที่สร้างโดย Yandex Yandex, CloudFlare, VK.com, Badoo และบริการอื่น ๆ ทั่วโลกใช้เก็บข้อมูลจำนวนมาก (การแทรกหลายพันแถวต่อวินาทีหรือข้อมูลที่เก็บไว้ในดิสก์)
ใน DBMS แบบ "สตริง" ปกติ ตัวอย่างคือ MySQL, Postgres, MS SQL Server ข้อมูลจะถูกจัดเก็บตามลำดับนี้:
ในกรณีนี้ ค่าที่เกี่ยวข้องกับแถวหนึ่งจะถูกเก็บไว้ทางกายภาพแบบเคียงข้างกัน ใน DBMS แบบเรียงเป็นแนว ค่าจากคอลัมน์ต่างๆ จะถูกจัดเก็บแยกกัน และข้อมูลของคอลัมน์เดียวจะถูกเก็บไว้ด้วยกัน:
ตัวอย่างของ DBMS แบบเรียงเป็นแนวได้แก่ Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+
บริษัทเป็นผู้ส่งไปรษณีย์ ฉันเริ่มใช้ Clickhouse ในปี 2018 เพื่อการรายงานและประทับใจมากกับความเรียบง่าย ความสามารถในการปรับขนาด การรองรับ SQL และความเร็ว ความเร็วของ DBMS นี้ล้อมรอบไปด้วยเวทย์มนตร์
ความเรียบง่าย
Clickhouse ติดตั้งบน Ubuntu ด้วยคำสั่งเดียว หากคุณรู้จัก SQL คุณสามารถเริ่มใช้ Clickhouse ตามความต้องการของคุณได้ทันที อย่างไรก็ตาม นี่ไม่ได้หมายความว่าคุณสามารถ "แสดงตารางสร้าง" ใน MySQL และคัดลอกและวาง SQL ใน Clickhouse ได้
เมื่อเปรียบเทียบกับ MySQL แล้ว มีความแตกต่างประเภทข้อมูลที่สำคัญในคำจำกัดความสคีมาตารางใน DBMS นี้ ดังนั้นคุณยังต้องใช้เวลาในการเปลี่ยนคำจำกัดความสคีมาตารางและเรียนรู้กลไกของตารางเพื่อให้คุ้นเคย
Clickhouse ใช้งานได้ดีโดยไม่ต้องใช้ซอฟต์แวร์เพิ่มเติม แต่ถ้าคุณต้องการใช้การจำลอง คุณจะต้องติดตั้ง ZooKeeper การวิเคราะห์ประสิทธิภาพการค้นหาแสดงผลลัพธ์ที่ยอดเยี่ยม - ตารางระบบมีข้อมูลทั้งหมด และข้อมูลทั้งหมดสามารถรับได้โดยใช้ SQL เก่าและน่าเบื่อ
การปฏิบัติ
- การเปรียบเทียบ Clickhouse กับ Vertica และ MySQL บนเซิร์ฟเวอร์การกำหนดค่า: สองซ็อกเก็ต Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; แรม 128 กิ๊บ; md RAID-5 บน HDD SATA 8 6TB, ext4
- การเปรียบเทียบ Clickhouse กับพื้นที่จัดเก็บบนคลาวด์ของ Amazon RedShift
- ข้อความที่ตัดตอนมาจากบล็อก :
ฐานข้อมูล ClickHouse มีการออกแบบที่เรียบง่าย - โหนดทั้งหมดในคลัสเตอร์มีฟังก์ชันการทำงานเหมือนกัน และใช้เฉพาะ ZooKeeper สำหรับการประสานงาน เราสร้างคลัสเตอร์เล็กๆ ของโหนดต่างๆ และทำการทดสอบ ในระหว่างนั้นเราพบว่าระบบมีประสิทธิภาพค่อนข้างน่าประทับใจ ซึ่งสอดคล้องกับข้อได้เปรียบที่อ้างไว้ในเกณฑ์มาตรฐาน DBMS เชิงวิเคราะห์ เราตัดสินใจที่จะพิจารณาแนวคิดเบื้องหลัง ClickHouse ให้ละเอียดยิ่งขึ้น อุปสรรคแรกในการวิจัยคือการไม่มีเครื่องมือและชุมชนเล็กๆ ของ ClickHouse ดังนั้นเราจึงเจาะลึกการออกแบบ DBMS นี้เพื่อทำความเข้าใจวิธีการทำงาน
ClickHouse ไม่รองรับการรับข้อมูลจาก Kafka โดยตรง เนื่องจากเป็นเพียงฐานข้อมูล ดังนั้นเราจึงเขียนบริการอะแดปเตอร์ของเราเองใน Go อ่านข้อความที่เข้ารหัส Cap'n Proto จาก Kafka แปลงเป็น TSV และแทรกลงใน ClickHouse เป็นชุดผ่านอินเทอร์เฟซ HTTP ต่อมาเราได้เขียนบริการนี้ใหม่เพื่อใช้ไลบรารี Go ร่วมกับอินเทอร์เฟซ ClickHouse ของเราเองเพื่อปรับปรุงประสิทธิภาพ เมื่อประเมินประสิทธิภาพของการรับแพ็กเก็ตเราค้นพบสิ่งสำคัญ - ปรากฎว่าสำหรับ ClickHouse ประสิทธิภาพนี้ขึ้นอยู่กับขนาดของแพ็กเก็ตอย่างมากนั่นคือจำนวนแถวที่แทรกในเวลาเดียวกัน เพื่อทำความเข้าใจว่าเหตุใดจึงเกิดเหตุการณ์เช่นนี้ เราได้ศึกษาวิธีที่ ClickHouse จัดเก็บข้อมูล
เอ็นจิ้นหลักหรือค่อนข้างจะเป็นตระกูลของเอ็นจิ้นตารางที่ ClickHouse ใช้เพื่อจัดเก็บข้อมูลคือ MergeTree กลไกนี้มีแนวคิดคล้ายกับอัลกอริทึม LSM ที่ใช้ใน Google BigTable หรือ Apache Cassandra แต่หลีกเลี่ยงการสร้างตารางหน่วยความจำระดับกลางและเขียนข้อมูลลงดิสก์โดยตรง สิ่งนี้ทำให้มีปริมาณงานการเขียนที่ยอดเยี่ยม เนื่องจากแต่ละแพ็กเก็ตที่แทรกจะถูกจัดเรียงตามคีย์หลัก "คีย์หลัก" เท่านั้น บีบอัด และเขียนลงดิสก์เพื่อสร้างเซ็กเมนต์
การไม่มีตารางหน่วยความจำหรือแนวคิดเรื่อง "ความสดใหม่" ของข้อมูลยังหมายความว่าสามารถเพิ่มได้เท่านั้น ระบบไม่รองรับการเปลี่ยนแปลงหรือการลบ ณ วันนี้ วิธีเดียวที่จะลบข้อมูลได้คือการลบข้อมูลตามเดือนตามปฏิทิน เนื่องจากกลุ่มต่างๆ จะไม่มีวันข้ามขอบเขตของเดือน ทีมงาน ClickHouse กำลังทำงานอย่างแข็งขันเพื่อทำให้คุณลักษณะนี้สามารถปรับแต่งได้ ในทางกลับกัน ช่วยให้การเขียนและการรวมส่วนต่างๆ ปราศจากข้อขัดแย้ง ดังนั้นรับระดับปริมาณงานเป็นเส้นตรงกับจำนวนส่วนแทรกแบบขนานจนกว่า I/O หรือคอร์จะอิ่มตัว
อย่างไรก็ตาม สถานการณ์นี้ยังหมายความว่าระบบไม่เหมาะสำหรับแพ็กเก็ตขนาดเล็ก ดังนั้นจึงใช้บริการของ Kafka และตัวแทรกสำหรับการบัฟเฟอร์ นอกจากนี้ ClickHouse ในพื้นหลังยังคงรวมส่วนต่างๆ อย่างต่อเนื่อง เพื่อให้ข้อมูลเล็กๆ จำนวนมากถูกนำมารวมกันและบันทึกครั้งมากขึ้น ซึ่งจะเป็นการเพิ่มความเข้มข้นของการบันทึก อย่างไรก็ตาม ชิ้นส่วนที่ไม่เกี่ยวข้องมากเกินไปจะทำให้เม็ดมีดควบคุมปริมาณอย่างรุนแรงตราบใดที่การผสานยังคงดำเนินต่อไป เราพบว่าการประนีประนอมที่ดีที่สุดระหว่างการนำเข้าข้อมูลแบบเรียลไทม์และประสิทธิภาพการนำเข้าคือการยอมรับจำนวนการแทรกต่อวินาทีในตารางที่จำกัด
กุญแจสำคัญในประสิทธิภาพการอ่านตารางคือการจัดทำดัชนีและตำแหน่งของข้อมูลบนดิสก์ ไม่ว่าการประมวลผลจะเร็วแค่ไหน เมื่อเอ็นจิ้นจำเป็นต้องสแกนข้อมูลหลายเทราไบต์จากดิสก์และใช้เพียงเศษเสี้ยวของข้อมูล มันก็ต้องใช้เวลา ClickHouse เป็นที่เก็บคอลัมน์ ดังนั้นแต่ละส่วนจึงมีไฟล์สำหรับแต่ละคอลัมน์ (คอลัมน์) พร้อมค่าที่เรียงลำดับสำหรับแต่ละแถว ดังนั้น จึงสามารถข้ามคอลัมน์ทั้งหมดที่ไม่ปรากฏในแบบสอบถามได้ก่อน จากนั้นจึงสามารถประมวลผลหลายเซลล์ควบคู่ไปกับการดำเนินการแบบเวกเตอร์ เพื่อหลีกเลี่ยงการสแกนแบบเต็ม แต่ละส่วนจะมีไฟล์ดัชนีขนาดเล็ก
เนื่องจากคอลัมน์ทั้งหมดจัดเรียงตาม "คีย์หลัก" ไฟล์ดัชนีจึงมีเพียงป้ายกำกับ (แถวที่บันทึก) ของแถวที่ N ทุกแถว เพื่อให้สามารถเก็บไว้ในหน่วยความจำแม้ในตารางที่มีขนาดใหญ่มาก ตัวอย่างเช่น คุณสามารถตั้งค่าเริ่มต้นเป็น "ทำเครื่องหมายทุกแถวที่ 8192" จากนั้นจึงสร้างดัชนี "น้อย" ของตารางด้วย 1 ล้านล้าน บรรทัดที่พอดีกับหน่วยความจำได้ง่ายจะมีอักขระเพียง 122 ตัว
การพัฒนาระบบ
สามารถติดตามการพัฒนาและปรับปรุง Clickhouse ได้ และตรวจสอบให้แน่ใจว่ากระบวนการ “เติบโต” เกิดขึ้นอย่างรวดเร็วอย่างน่าประทับใจ
ความนิยม
ดูเหมือนว่าความนิยมของ Clickhouse กำลังเพิ่มขึ้นอย่างมาก โดยเฉพาะในชุมชนที่พูดภาษารัสเซีย การประชุม High load 2018 เมื่อปีที่แล้ว (มอสโก 8-9 พฤศจิกายน 2018) แสดงให้เห็นว่าสัตว์ประหลาดอย่าง vk.com และ Badoo ใช้ Clickhouse ซึ่งแทรกข้อมูล (เช่น บันทึก) จากเซิร์ฟเวอร์นับหมื่นเครื่องพร้อมกัน ในวิดีโอความยาว 40 นาที . เร็วๆ นี้เราจะโพสต์ข้อความถอดเสียงบน Habr เพื่อความสะดวกในการทำงานกับเนื้อหา
การใช้งาน
หลังจากใช้เวลาค้นคว้ามาบ้างแล้ว ฉันคิดว่ามีหลายส่วนที่ ClickHouse สามารถมีประโยชน์หรือสามารถแทนที่โซลูชันแบบดั้งเดิมและยอดนิยมอื่น ๆ ได้อย่างสมบูรณ์ เช่น MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot และ ดรูอิด. ต่อไปนี้เป็นรายละเอียดการใช้ ClickHouse เพื่ออัพเกรดหรือแทนที่ DBMS ข้างต้นทั้งหมด
การขยาย MySQL และ PostgreSQL
ล่าสุด เราได้แทนที่ MySQL บางส่วนด้วย ClickHouse สำหรับแพลตฟอร์มจดหมายข่าว . ปัญหาคือ MySQL เนื่องจากการออกแบบที่ไม่เหมาะสม บันทึกทุกอีเมลที่ส่งและทุกลิงก์ในอีเมลนั้นด้วยแฮช base64 ทำให้เกิดตาราง MySQL ขนาดใหญ่ (email_stats) หลังจากส่งอีเมลไปยังสมาชิกของบริการเพียง 10 ล้านอีเมล ตารางนี้ก็กินพื้นที่ไฟล์ 150 GB และ MySQL ก็เริ่ม "งี่เง่า" กับข้อความค้นหาง่ายๆ เพื่อแก้ไขปัญหาพื้นที่ไฟล์ เราใช้การบีบอัดตาราง InnoDB ได้สำเร็จ ซึ่งลดขนาดลง 4 เท่า อย่างไรก็ตาม ยังคงไม่สมเหตุสมผลที่จะจัดเก็บอีเมลมากกว่า 20-30 ล้านอีเมลใน MySQL เพียงเพื่อประโยชน์ในการอ่านประวัติ เนื่องจากการสืบค้นง่ายๆ ที่ต้องสแกนแบบเต็มด้วยเหตุผลบางประการในการสลับและ I/O จำนวนมาก ค่าใช้จ่ายซึ่งเราได้รับคำเตือนจาก Zabbix เป็นประจำ
Clickhouse ใช้อัลกอริธึมการบีบอัดสองแบบที่ลดปริมาณข้อมูลลงประมาณ แต่ในกรณีนี้ ข้อมูลจะ "บีบอัดได้" เป็นพิเศษ
การเปลี่ยน ELK
จากประสบการณ์ของฉันเอง สแต็ก ELK (ElasticSearch, Logstash และ Kibana ในกรณีนี้คือ ElasticSearch) ต้องใช้ทรัพยากรในการทำงานมากกว่าที่จำเป็นในการจัดเก็บบันทึก ElasticSearch เป็นเครื่องมือที่ยอดเยี่ยมหากคุณต้องการค้นหาบันทึกข้อความแบบเต็มที่ดี (ซึ่งฉันไม่คิดว่าคุณต้องการจริงๆ) แต่ฉันสงสัยว่าทำไมมันถึงกลายเป็นเครื่องมือบันทึกมาตรฐานโดยพฤตินัย ประสิทธิภาพการนำเข้าเมื่อรวมกับ Logstash ทำให้เราประสบปัญหาแม้ในปริมาณงานที่ค่อนข้างน้อย และจำเป็นต้องเพิ่ม RAM และพื้นที่ดิสก์มากขึ้นเรื่อยๆ ในฐานะฐานข้อมูล Clickhouse ดีกว่า ElasticSearch ด้วยเหตุผลดังต่อไปนี้:
- รองรับภาษา SQL;
- ระดับการบีบอัดข้อมูลที่จัดเก็บที่ดีที่สุด
- รองรับการค้นหา Regex แทนการค้นหาข้อความแบบเต็ม
- ปรับปรุงการกำหนดเวลาการค้นหาและประสิทธิภาพโดยรวมที่ดีขึ้น
ในปัจจุบัน ปัญหาใหญ่ที่สุดที่เกิดขึ้นเมื่อเปรียบเทียบ ClickHouse กับ ELK คือการขาดวิธีแก้ปัญหาในการอัปโหลดบันทึก ตลอดจนการขาดเอกสารและบทช่วยสอนในหัวข้อนี้ ในเวลาเดียวกัน ผู้ใช้แต่ละคนสามารถตั้งค่า ELK โดยใช้คู่มือ Digital Ocean ซึ่งมีความสำคัญมากสำหรับการใช้เทคโนโลยีดังกล่าวอย่างรวดเร็ว มีกลไกฐานข้อมูลอยู่ที่นี่ แต่ยังไม่มี Filebeat สำหรับ ClickHouse ใช่มีอยู่ และระบบการทำงานกับบันทึก ,มีเครื่องมือ เพื่อป้อนข้อมูลไฟล์บันทึกลงใน ClickHouse แต่ทั้งหมดนี้ต้องใช้เวลามากขึ้น อย่างไรก็ตาม ClickHouse ยังคงเป็นผู้นำเนื่องจากความเรียบง่าย ดังนั้นแม้แต่ผู้เริ่มต้นก็สามารถติดตั้งได้อย่างง่ายดายและเริ่มการใช้งานเต็มรูปแบบในเวลาเพียง 10 นาที
ฉันชอบโซลูชันแบบมินิมอลลิสต์ ฉันพยายามใช้ FluentBit ซึ่งเป็นเครื่องมืออัปโหลดบันทึกหน่วยความจำที่ต่ำมากกับ ClickHouse ในขณะที่พยายามหลีกเลี่ยงการใช้ Kafka อย่างไรก็ตาม จำเป็นต้องแก้ไขความไม่เข้ากันเล็กน้อย เช่น ก่อนที่จะสามารถทำได้โดยไม่ต้องใช้ชั้นพร็อกซีที่แปลงข้อมูลจาก FluentBit เป็น ClickHouse
ทางเลือกแทน Kibana คุณสามารถใช้ ClickHouse เป็นแบ็กเอนด์ได้ . เท่าที่ฉันเข้าใจ สิ่งนี้อาจทำให้เกิดปัญหาด้านประสิทธิภาพเมื่อเรนเดอร์จุดข้อมูลจำนวนมาก โดยเฉพาะอย่างยิ่งกับ Grafana เวอร์ชันเก่า ใน Qwintry เรายังไม่ได้ลองทำเช่นนี้ แต่ข้อร้องเรียนเกี่ยวกับเรื่องนี้จะปรากฏขึ้นเป็นครั้งคราวในช่องทางการสนับสนุน ClickHouse ใน Telegram
การแทนที่ Google Big Query และ Amazon RedShift (โซลูชันสำหรับบริษัทขนาดใหญ่)
กรณีการใช้งานที่เหมาะสมที่สุดสำหรับ BigQuery คือการโหลดข้อมูล JSON ขนาด 1TB และเรียกใช้การค้นหาเชิงวิเคราะห์กับข้อมูลดังกล่าว Big Query เป็นผลิตภัณฑ์ที่ยอดเยี่ยมซึ่งมีความสามารถในการปรับขนาดซึ่งประเมินค่าสูงไปได้ยาก นี่เป็นซอฟต์แวร์ที่ซับซ้อนกว่า ClickHouse ที่ทำงานบนคลัสเตอร์ภายในมาก แต่จากมุมมองของลูกค้า มันมีหลายอย่างที่เหมือนกันกับ ClickHouse BigQuery สามารถ "ขึ้นราคา" ได้อย่างรวดเร็วเมื่อคุณเริ่มจ่ายเงินสำหรับ SELECT แต่ละรายการ จึงเป็นโซลูชัน SaaS ที่แท้จริงที่มีทั้งข้อดีและข้อเสียทั้งหมด
ClickHouse เป็นตัวเลือกที่ดีที่สุดเมื่อคุณเรียกใช้การสืบค้นที่มีราคาแพงในการคำนวณจำนวนมาก ยิ่งคุณเรียกใช้คำสั่ง SELECT ทุกวันมากเท่าไร การแทนที่ Big Query ด้วย ClickHouse ก็จะยิ่งมีประโยชน์มากขึ้นเท่านั้น เนื่องจากการแทนที่ดังกล่าวจะช่วยให้คุณประหยัดเงินได้หลายพันดอลลาร์เมื่อต้องประมวลผลข้อมูลหลายเทราไบต์ สิ่งนี้ใช้ไม่ได้กับข้อมูลที่จัดเก็บซึ่งมีราคาค่อนข้างถูกในการประมวลผลใน Big Query
ในบทความโดย Alexander Zaitsev ผู้ร่วมก่อตั้ง Altinity อธิบายประโยชน์ของการย้าย DBMS ดังกล่าว
การเปลี่ยน TimescaleDB
TimescaleDB เป็นส่วนขยาย PostgreSQL ที่ปรับการทำงานให้เหมาะสมที่สุดกับอนุกรมเวลาในฐานข้อมูลปกติ (, ).
แม้ว่า ClickHouse จะไม่ใช่คู่แข่งที่สำคัญในกลุ่มอนุกรมเวลา แต่ในแง่ของโครงสร้างคอลัมน์และการดำเนินการคิวรีแบบเวกเตอร์ จะเร็วกว่า TimescaleDB มากในกรณีส่วนใหญ่ของการประมวลผลคิวรีเชิงวิเคราะห์ ในเวลาเดียวกันประสิทธิภาพของการรับข้อมูลแพ็คเก็ต ClickHouse นั้นสูงกว่าประมาณ 3 เท่า นอกจากนี้ยังใช้พื้นที่ดิสก์น้อยลง 20 เท่า ซึ่งสำคัญมากสำหรับการประมวลผลข้อมูลประวัติปริมาณมาก: .
ต่างจาก ClickHouse วิธีเดียวที่จะประหยัดพื้นที่ดิสก์ใน TimescaleDB คือการใช้ ZFS หรือระบบไฟล์ที่คล้ายกัน
การอัปเดต ClickHouse ที่กำลังจะมีขึ้นมีแนวโน้มที่จะแนะนำการบีบอัดแบบเดลต้า ซึ่งจะทำให้เหมาะสำหรับการประมวลผลและจัดเก็บข้อมูลอนุกรมเวลามากยิ่งขึ้น TimescaleDB อาจเป็นตัวเลือกที่ดีกว่า ClickHouse เปล่าในกรณีต่อไปนี้:
- การติดตั้งขนาดเล็กที่มี RAM น้อยมาก (<3 GB)
- INSERT ขนาดเล็กจำนวนมากที่คุณไม่ต้องการบัฟเฟอร์เป็นแฟรกเมนต์ขนาดใหญ่
- ความสม่ำเสมอ ความสม่ำเสมอ และข้อกำหนดด้านกรดที่ดีขึ้น
- รองรับ PostGIS;
- ผสานกับตาราง PostgreSQL ที่มีอยู่ เนื่องจาก Timescale DB นั้นเป็น PostgreSQL เป็นหลัก
แข่งขันกับระบบ Hadoop และ MapReduce
Hadoop และผลิตภัณฑ์ MapReduce อื่นๆ สามารถทำการคำนวณที่ซับซ้อนได้มากมายแต่มีแนวโน้มที่จะทำงานด้วยเวลาแฝงที่สูง ClickHouse แก้ไขปัญหานี้โดยการประมวลผลข้อมูลหลายเทราไบต์และสร้างผลลัพธ์แทบจะในทันที ดังนั้น ClickHouse จึงมีประสิทธิภาพมากกว่ามากในการดำเนินการวิจัยเชิงวิเคราะห์เชิงโต้ตอบที่รวดเร็ว ซึ่งนักวิทยาศาสตร์ข้อมูลควรสนใจ
แข่งขันกับ Pinot และ Druid
คู่แข่งที่ใกล้เคียงที่สุดของ ClickHouse คือผลิตภัณฑ์โอเพ่นซอร์สแบบเรียงเป็นแนวและปรับขนาดได้เชิงเส้น Pinot และ Druid งานที่ยอดเยี่ยมเมื่อเปรียบเทียบระบบเหล่านี้มีการเผยแพร่ในบทความ 1 กุมภาพันธ์ 2018
บทความนี้จำเป็นต้องได้รับการอัปเดต - ระบุว่า ClickHouse ไม่รองรับการดำเนินการ UPDATE และ DELETE ซึ่งไม่เป็นความจริงทั้งหมดที่เกี่ยวข้องกับเวอร์ชันล่าสุด
เราไม่มีประสบการณ์มากนักกับ DBMS เหล่านี้ แต่ฉันไม่ชอบความซับซ้อนของโครงสร้างพื้นฐานที่จำเป็นในการรัน Druid และ Pinot - มันเป็น "ส่วนที่เคลื่อนไหว" จำนวนมากที่ล้อมรอบด้วย Java จากทุกด้าน
Druid และ Pinot เป็นโครงการบ่มเพาะ Apache ซึ่ง Apache กล่าวถึงรายละเอียดในหน้าโครงการ GitHub ปิโนต์ปรากฏตัวในตู้ฟักเมื่อเดือนตุลาคม 2018 และดรูอิดเกิดเมื่อ 8 เดือนก่อนหน้านี้ในเดือนกุมภาพันธ์
การขาดข้อมูลเกี่ยวกับวิธีการทำงานของ AFS ทำให้เกิดคำถามบางอย่างและอาจโง่เขลาสำหรับฉัน ฉันสงสัยว่าผู้เขียน Pinot สังเกตเห็นหรือไม่ว่ามูลนิธิ Apache มีทัศนคติต่อดรูอิดมากกว่าและทัศนคติต่อคู่แข่งทำให้เกิดความรู้สึกอิจฉาหรือไม่? การพัฒนาของ Druid จะช้าลงหรือไม่ และการพัฒนาของ Pinot จะเร่งเร็วขึ้นหรือไม่ หากผู้สนับสนุนที่สนับสนุนปิโนต์เริ่มสนใจปิโนต์อย่างหลังอย่างกะทันหัน?
ข้อเสียของ ClickHouse
ยังไม่บรรลุนิติภาวะ: แน่นอนว่านี่ยังคงเป็นเทคโนโลยีที่น่าเบื่อ แต่ไม่ว่าในกรณีใด ไม่มีอะไรแบบนี้ให้เห็นใน DBMS แบบเรียงเป็นแนวอื่น
เม็ดมีดขนาดเล็กทำงานได้ไม่ดีที่ความเร็วสูง: เม็ดมีดจะต้องแบ่งออกเป็นชิ้นใหญ่ เนื่องจากประสิทธิภาพของเม็ดมีดขนาดเล็กจะลดลงตามสัดส่วนของจำนวนคอลัมน์ในแต่ละแถว นี่คือวิธีที่ ClickHouse จัดเก็บข้อมูลบนดิสก์ - แต่ละคอลัมน์หมายถึง 1 ไฟล์ขึ้นไป ดังนั้นในการแทรก 1 แถวที่มี 100 คอลัมน์ คุณจะต้องเปิดและเขียนไฟล์อย่างน้อย 100 ไฟล์ นี่คือสาเหตุที่การแทรกบัฟเฟอร์ต้องใช้ตัวกลาง (เว้นแต่ว่าไคลเอนต์จะจัดเตรียมการบัฟเฟอร์เอง) - โดยทั่วไปคือ Kafka หรือระบบคิวบางประเภท คุณยังสามารถใช้กลไกตารางบัฟเฟอร์เพื่อคัดลอกข้อมูลจำนวนมากลงในตาราง MergeTree ในภายหลังได้
การรวมตารางถูกจำกัดโดย RAM ของเซิร์ฟเวอร์ แต่อย่างน้อยก็มีอยู่! ตัวอย่างเช่น Druid และ Pinot ไม่มีการเชื่อมต่อดังกล่าวเลย เนื่องจากเป็นการยากที่จะนำไปใช้โดยตรงในระบบแบบกระจายที่ไม่รองรับการย้ายข้อมูลจำนวนมากระหว่างโหนด
ผลการวิจัย
ในอีกไม่กี่ปีข้างหน้า เราวางแผนที่จะใช้งาน ClickHouse ใน Qwintry อย่างกว้างขวาง เนื่องจาก DBMS นี้ให้ความสมดุลที่ยอดเยี่ยมระหว่างประสิทธิภาพ ค่าใช้จ่ายที่ต่ำ ความสามารถในการปรับขนาด และความเรียบง่าย ฉันค่อนข้างแน่ใจว่ามันจะแพร่กระจายอย่างรวดเร็วเมื่อชุมชน ClickHouse มีวิธีใช้งานมากขึ้นในการติดตั้งขนาดเล็กและขนาดกลาง
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com