ย้ายไป ClickHouse: 3 ปีต่อมา

สามปีที่แล้ว Viktor Tarnavsky และ Alexey Milovidov จาก Yandex บนเวที โหลดสูง++ บอกClickHouse ดีแค่ไหน และมันไม่ช้าลงแค่ไหน และในขั้นต่อไปก็มี Alexander Zaitsev с รายงาน เกี่ยวกับการย้ายไป คลิกเฮาส์ จาก DBMS วิเคราะห์อีกตัวหนึ่งและได้ข้อสรุปว่า คลิกเฮาส์แน่นอนว่าดีแต่ไม่สะดวกมากนัก เมื่อในปี 2016 บริษัทฯ LifeStreetซึ่งอเล็กซานเดอร์ทำงานในขณะนั้น กำลังแปลงระบบการวิเคราะห์หลายเพตะไบต์เป็น คลิกเฮาส์มันเป็น “ถนนอิฐสีเหลือง” อันน่าทึ่งที่เต็มไปด้วยอันตรายที่ไม่รู้จัก - คลิกเฮาส์ เมื่อก่อนมันดูเหมือนกับทุ่นระเบิด

สามปีต่อมา คลิกเฮาส์ ดีขึ้นมาก - ในช่วงเวลานี้ Alexander ก่อตั้ง บริษัท Altinity ซึ่งไม่เพียงช่วยให้ผู้คนย้ายไปอยู่เท่านั้น คลิกเฮาส์ หลายสิบโครงการ แต่ยังปรับปรุงผลิตภัณฑ์ร่วมกับเพื่อนร่วมงานจาก Yandex ตอนนี้ คลิกเฮาส์ ยังไม่ได้เดินเล่นอย่างไร้กังวล แต่ก็ไม่ใช่เขตที่วางทุ่นระเบิดอีกต่อไป

Alexander ทำงานร่วมกับระบบแบบกระจายมาตั้งแต่ปี 2003 โดยพัฒนาโครงการขนาดใหญ่ มายเอสคิวแอล, ออราเคิล и เวอร์ติกา. เมื่อสุดท้าย โหลดสูง ++ 2019 Alexander หนึ่งในผู้บุกเบิกการใช้ คลิกเฮาส์บอกว่าตอนนี้ DBMS นี้คืออะไร เราจะเรียนรู้เกี่ยวกับคุณสมบัติหลัก คลิกเฮาส์: แตกต่างจากระบบอื่นอย่างไร และกรณีไหนจะมีประสิทธิภาพมากกว่าในการใช้งาน จากตัวอย่าง เราจะดูแนวทางปฏิบัติล่าสุดและที่ผ่านการทดสอบแล้วสำหรับระบบการสร้างตาม คลิกเฮาส์.

ย้อนหลัง: เกิดอะไรขึ้นเมื่อ 3 ปีที่แล้ว

เมื่อสามปีที่แล้วเราย้ายบริษัท LifeStreet บน คลิกเฮาส์ จากฐานข้อมูลการวิเคราะห์อื่น และการโยกย้ายการวิเคราะห์เครือข่ายโฆษณามีลักษณะดังนี้:

• มิถุนายน 2016 ใน โอเพ่นซอร์ส ปรากฏ คลิกเฮาส์ และโครงการของเราก็เริ่มต้นขึ้น
• สิงหาคม การพิสูจน์แนวคิด: เครือข่ายโฆษณาขนาดใหญ่ โครงสร้างพื้นฐาน และข้อมูลขนาด 200-300 เทราไบต์
• ตุลาคม. ข้อมูลการผลิตครั้งแรก
• ธันวาคม. ปริมาณผลิตภัณฑ์ทั้งหมดคือ 10-50 พันล้านเหตุการณ์ต่อวัน
• มิถุนายน 2017 การย้ายผู้ใช้ไปที่สำเร็จแล้ว คลิกเฮาส์ข้อมูลขนาด 2,5 เพตะไบต์บนคลัสเตอร์เซิร์ฟเวอร์ 60 เครื่อง

ในระหว่างกระบวนการโยกย้าย มีความเข้าใจเพิ่มมากขึ้นว่า คลิกเฮาส์ เป็นระบบที่ดีที่น่าใช้งาน แต่นี่เป็นโครงการภายในของ Yandex ดังนั้นจึงมีความแตกต่าง: ยานเดกซ์จะจัดการกับลูกค้าภายในของตัวเองก่อนแล้วจึงจัดการกับชุมชนและความต้องการของผู้ใช้ภายนอกเท่านั้นจากนั้น ClickHouse ก็ไปไม่ถึงระดับองค์กรในหลาย ๆ ด้านการทำงาน นั่นเป็นเหตุผลที่เราก่อตั้ง Altinity ในเดือนมีนาคม 2017 เพื่อผลิต คลิกเฮาส์ เร็วและสะดวกยิ่งขึ้นไม่เพียง แต่สำหรับยานเดกซ์เท่านั้น แต่ยังรวมถึงผู้ใช้รายอื่นด้วย และตอนนี้เรา:

• เราฝึกอบรมและช่วยสร้างโซลูชันตาม คลิกเฮาส์ เพื่อให้ลูกค้าไม่ประสบปัญหาและเพื่อให้การแก้ปัญหาใช้งานได้ในที่สุด
• เราให้การสนับสนุนตลอด 24 ชั่วโมงทุกวัน คลิกเฮาส์- การติดตั้ง;
• เราพัฒนาโครงการระบบนิเวศของเราเอง
• เรามุ่งมั่นกับตัวเองอย่างแข็งขัน คลิกเฮาส์ตอบสนองต่อคำขอจากผู้ใช้ที่ต้องการดูคุณสมบัติบางอย่าง

และแน่นอนว่าเราช่วยเรื่องการย้ายไปอยู่ด้วย คลิกเฮาส์ с MySQL, เวอร์ติกา, คำพยากรณ์, กรีนพลัม, redshift และระบบอื่นๆ เรามีส่วนร่วมในการเคลื่อนไหวต่างๆ มากมาย และทั้งหมดนี้ก็ประสบความสำเร็จ

ย้ายไปทำไม. คลิกเฮาส์

ไม่ลดความเร็ว! นี่คือเหตุผลหลัก คลิกเฮาส์ - ฐานข้อมูลที่รวดเร็วมากสำหรับสถานการณ์ที่แตกต่างกัน:

คำคมสุ่มจากคนที่ทำงานกับคนมายาวนาน คลิกเฮาส์.

ความสามารถในการปรับขนาด ในฐานข้อมูลอื่น ๆ คุณสามารถบรรลุประสิทธิภาพที่ดีบนฮาร์ดแวร์ชิ้นเดียวได้ คลิกเฮาส์ คุณสามารถปรับขนาดได้ไม่เพียงแต่ในแนวตั้งเท่านั้น แต่ยังรวมถึงแนวนอนด้วย เพียงแค่เพิ่มเซิร์ฟเวอร์ ทุกอย่างไม่ได้ทำงานได้อย่างราบรื่นอย่างที่เราต้องการ แต่มันก็ได้ผล คุณสามารถขยายระบบได้เมื่อธุรกิจของคุณเติบโตขึ้น สิ่งสำคัญคือเราต้องไม่ถูกจำกัดด้วยโซลูชันในตอนนี้และมีศักยภาพในการพัฒนาอยู่เสมอ

การพกพา. ไม่มีความผูกพันกับสิ่งใดสิ่งหนึ่ง ตัวอย่างเช่นด้วย อเมซอน Redshift มันยากที่จะย้ายไปที่ไหนสักแห่ง ก คลิกเฮาส์ คุณสามารถติดตั้งบนแล็ปท็อป เซิร์ฟเวอร์ ปรับใช้กับคลาวด์ ไปที่ Kubernetes — ไม่มีข้อจำกัดในการทำงานของโครงสร้างพื้นฐาน สิ่งนี้สะดวกสำหรับทุกคน และนี่เป็นข้อได้เปรียบใหญ่ที่ฐานข้อมูลอื่นที่คล้ายคลึงกันไม่สามารถอวดได้

มีความยืดหยุ่น. คลิกเฮาส์ ไม่ได้หยุดอยู่เพียงสิ่งเดียว เช่น Yandex.Metrica แต่พัฒนาและใช้ในโครงการและอุตสาหกรรมที่แตกต่างกันมากขึ้นเรื่อยๆ สามารถขยายได้โดยการเพิ่มความสามารถใหม่ๆ ในการแก้ปัญหาใหม่ๆ ตัวอย่างเช่น เชื่อกันว่าการจัดเก็บบันทึกในฐานข้อมูลเป็นมารยาทที่ไม่ดี จึงคิดขึ้นมา ElasticSearch. แต่ต้องขอบคุณความยืดหยุ่น คลิกเฮาส์คุณสามารถจัดเก็บบันทึกไว้ในนั้นได้และบ่อยครั้งจะดีกว่าในนั้นด้วยซ้ำ ElasticSearch - ใน คลิกเฮาส์ ซึ่งต้องใช้ธาตุเหล็กน้อยกว่าถึง 10 เท่า

ฟรี โอเพนซอร์ส. คุณไม่ต้องจ่ายอะไรเลย ไม่จำเป็นต้องเจรจาสิทธิ์ในการติดตั้งระบบบนแล็ปท็อปหรือเซิร์ฟเวอร์ของคุณ ไม่มีค่าธรรมเนียมแอบแฝง ในขณะเดียวกันไม่มีเทคโนโลยีฐานข้อมูลโอเพ่นซอร์สอื่นใดที่สามารถแข่งขันความเร็วได้ คลิกเฮาส์. MySQL, MariaDB, กรีนพลัม - พวกมันทั้งหมดช้ากว่ามาก

ชุมชนการขับเคลื่อนและ สนุก. ใน คลิกเฮาส์ ชุมชนที่ยอดเยี่ยม: การพบปะ การพูดคุย และ Alexey Milovidov ผู้ซึ่งเติมพลังให้กับเราทุกคนด้วยพลังและการมองโลกในแง่ดีของเขา

ย้ายไปคลิกเฮาส์

เพื่อไปที่ คลิกเฮาส์ ด้วยเหตุผลบางอย่าง คุณต้องการเพียงสามสิ่งเท่านั้น:

• เข้าใจข้อจำกัด คลิกเฮาส์ และอะไรที่ไม่เหมาะกับ
• เอาเปรียบ เทคโนโลยีและจุดแข็งที่ยิ่งใหญ่ที่สุด
• การทดลอง. แม้จะเข้าใจวิธีการทำงานก็ตาม คลิกเฮาส์เราไม่สามารถคาดเดาได้เสมอไปว่าเมื่อใดจะเร็วขึ้น เมื่อใดจะช้าลง เมื่อใดจะดีขึ้น และจะแย่ลงเมื่อใด ดังนั้นลองดู

ปัญหาการย้าย

มีเพียง "แต่" เท่านั้น: ถ้าคุณย้ายไป คลิกเฮาส์ จากอย่างอื่นก็มักจะมีบางอย่างผิดปกติเกิดขึ้น เราคุ้นเคยกับแนวปฏิบัติและสิ่งต่าง ๆ ที่ใช้ในฐานข้อมูลที่เราชื่นชอบ เช่น ใครก็ตามที่ทำงานด้วย SQฐานข้อมูล L พิจารณาชุดฟังก์ชันต่อไปนี้ที่บังคับ:

• ธุรกรรม;
• ข้อ จำกัด ;
• ความสม่ำเสมอ;
• ดัชนี;
• อัปเดต/ลบ;
• ค่าว่าง;
• มิลลิวินาที;
• การปลดเปลื้องแบบอัตโนมัติ
• การรวมหลายรายการ
• พาร์ติชันโดยพลการ;
• เครื่องมือการจัดการคลัสเตอร์

จำเป็นต้องมีการรับสมัคร แต่เมื่อสามปีที่แล้ว คลิกเฮาส์ ไม่มีฟังก์ชันเหล่านี้เลย! ขณะนี้เหลือน้อยกว่าครึ่งหนึ่งของสิ่งที่ยังไม่ได้ดำเนินการ: ธุรกรรม ข้อจำกัด ความสม่ำเสมอ มิลลิวินาที และการคัดเลือกประเภท

และสิ่งสำคัญก็คือใน คลิกเฮาส์ แนวทางปฏิบัติและแนวทางมาตรฐานบางอย่างไม่ได้ผลหรือแตกต่างไปจากที่เราคุ้นเคย ทุกสิ่งที่ปรากฏอยู่ใน คลิกเฮาส์สอดคล้องกับ "คลิกทางบ้าน", เช่น. ฟังก์ชั่นแตกต่างจากฐานข้อมูลอื่น ตัวอย่างเช่น:

• ไม่ได้เลือกดัชนี แต่ข้ามไป
• อัปเดต/ลบ ไม่ซิงโครนัส แต่อะซิงโครนัส
• มีการรวมหลายรายการ แต่ไม่มีตัววางแผนคิวรี โดยทั่วไปแล้ววิธีการดำเนินการเหล่านี้ยังไม่ชัดเจนสำหรับผู้ที่มาจากโลกฐานข้อมูล

สคริปต์ ClickHouse

ในปี 1960 นักคณิตศาสตร์ชาวอเมริกันเชื้อสายฮังการี วิกเนอร์ อีพี เขียนบทความ "ประสิทธิผลที่ไม่สมเหตุสมผลของคณิตศาสตร์ในวิทยาศาสตร์ธรรมชาติ” (“ ประสิทธิผลที่ไม่อาจเข้าใจได้ของคณิตศาสตร์ในวิทยาศาสตร์ธรรมชาติ”) ที่โลกรอบตัวเรานั้นด้วยเหตุผลบางประการที่อธิบายไว้อย่างดีโดยกฎทางคณิตศาสตร์ คณิตศาสตร์เป็นวิทยาศาสตร์เชิงนามธรรม และกฎฟิสิกส์ที่แสดงออกมาในรูปแบบทางคณิตศาสตร์นั้นไม่ใช่เรื่องเล็กน้อย และ วิกเนอร์ อีพี ย้ำว่าเรื่องนี้แปลกมาก

จากมุมมองของฉัน, คลิกเฮาส์ - ความแปลกประหลาดเดียวกัน หากต้องการใช้ถ้อยคำใหม่ของ Wigner เราสามารถพูดได้ดังนี้: ประสิทธิภาพที่เหลือเชื่อนั้นน่าทึ่งมาก คลิกเฮาส์ ในการใช้งานเชิงวิเคราะห์ที่หลากหลาย!

ตัวอย่างเช่น เอาล่ะ คลังข้อมูลแบบเรียลไทม์ซึ่งข้อมูลจะถูกโหลดเกือบอย่างต่อเนื่อง เราต้องการรับคำขอจากมันโดยล่าช้าเป็นครั้งที่สอง กรุณา - ใช้มัน คลิกเฮาส์เพราะนี่คือสถานการณ์ที่ออกแบบมาเพื่อ คลิกเฮาส์ นี่คือวิธีการใช้ไม่เพียงแต่บนเว็บเท่านั้น แต่ยังรวมถึงการวิเคราะห์การตลาดและการเงินด้วย แอดเทคh เช่นเดียวกับใน การตรวจจับการฉ้อโกงn. ใน คลังข้อมูลแบบเรียลไทม์ มีการใช้โครงร่างที่มีโครงสร้างที่ซับซ้อนเช่น "ดาว" หรือ "เกล็ดหิมะ" ในหลายตารางด้วย สมัคร (บางครั้งก็มีหลายรายการ) และโดยปกติแล้วข้อมูลจะถูกจัดเก็บและเปลี่ยนแปลงในบางระบบ

ลองใช้สถานการณ์อื่น - อนุกรมเวลา: การตรวจสอบอุปกรณ์ เครือข่าย สถิติการใช้งาน Internet of Things ที่นี่เราพบกับเหตุการณ์ที่ค่อนข้างง่ายซึ่งเรียงลำดับตามเวลา คลิกเฮาส์ เดิมทีไม่ได้ได้รับการพัฒนาเพื่อการนี้ แต่ได้แสดงให้เห็นว่าทำงานได้ดี ซึ่งเป็นสาเหตุที่บริษัทขนาดใหญ่ใช้ คลิกเฮาส์ เป็นที่เก็บข้อมูลการติดตามข้อมูล เพื่อสำรวจว่าเหมาะสมหรือไม่ คลิกเฮาส์ สำหรับอนุกรมเวลา เราได้จัดทำเกณฑ์มาตรฐานตามแนวทางและผลลัพธ์ InfluxDB и ไทม์สเกลDB - เฉพาะทาง อนุกรมเวลา ฐานข้อมูล ปรากฎว่าที่ คลิกเฮาส์แม้ว่าจะไม่มีการปรับให้เหมาะสมสำหรับงานดังกล่าว แต่ก็ชนะในสนามต่างประเทศ:

В อนุกรมเวลา โดยปกติจะใช้ตารางแคบ - คอลัมน์เล็ก ๆ หลายคอลัมน์ ข้อมูลจำนวนมากสามารถมาจากการตรวจสอบ—นับล้านบันทึกต่อวินาที—และมักจะมาในรูปแบบการระเบิดเล็กน้อย (เรียลไทม์ สตรีมมิ่ง) ดังนั้นจึงจำเป็นต้องใช้สคริปต์การแทรกที่แตกต่างกัน และการสืบค้นเองก็มีความเฉพาะเจาะจงของตัวเอง

จัดการเข้าสู่ระบบ. การรวบรวมบันทึกลงในฐานข้อมูลมักจะไม่ดี แต่ คลิกเฮาส์ ซึ่งสามารถทำได้โดยใช้ความคิดเห็นตามที่อธิบายไว้ข้างต้น หลายบริษัทใช้ คลิกเฮาส์ เพื่อการนี้อย่างแน่นอน ในกรณีนี้ เราใช้ตารางกว้างเรียบเพื่อจัดเก็บบันทึกทั้งหมด (เช่น ในแบบฟอร์ม JSON) หรือหั่นเป็นชิ้นๆ โดยปกติแล้วข้อมูลจะถูกโหลดเป็นชุดใหญ่ (ไฟล์) และเราค้นหาตามบางฟิลด์

สำหรับแต่ละฟังก์ชันเหล่านี้ โดยปกติจะใช้ฐานข้อมูลเฉพาะ คลิกเฮาส์ เราสามารถทำได้ทั้งหมดและทำได้ดีกว่าพวกเขาด้วย ตอนนี้เรามาดูกันดีกว่า อนุกรมเวลา สถานการณ์และวิธีการ “ปรุงอาหาร” อย่างถูกต้อง คลิกเฮาส์ สำหรับสถานการณ์นี้

อนุกรมเวลา

ขณะนี้นี่เป็นสถานการณ์หลักที่ คลิกเฮาส์ ถือเป็นการแก้ปัญหามาตรฐาน อนุกรมเวลา คือชุดของเหตุการณ์ที่เรียงลำดับตามเวลา ซึ่งแสดงถึงการเปลี่ยนแปลงในกระบวนการบางอย่างเมื่อเวลาผ่านไป ตัวอย่างเช่น อาจเป็นอัตราการเต้นของหัวใจต่อวันหรือจำนวนกระบวนการในระบบ ทุกสิ่งที่ให้เวลามีมิติบางอย่างคือ อนุกรมเวลา:

เหตุการณ์ประเภทนี้ส่วนใหญ่มาจากการติดตาม ซึ่งไม่เพียงแต่สามารถติดตามเว็บเท่านั้น แต่ยังรวมถึงอุปกรณ์จริงด้วย เช่น รถยนต์ ระบบอุตสาหกรรม IoTโรงงานหรือแท็กซี่ไร้คนขับซึ่งอยู่ในท้ายรถที่ยานเดกซ์วางไว้แล้ว คลิกเฮาส์-เซิร์ฟเวอร์

ตัวอย่างเช่น มีบริษัทที่รวบรวมข้อมูลจากเรือ ทุก ๆ ไม่กี่วินาที เซ็นเซอร์บนเรือคอนเทนเนอร์จะส่งการวัดที่แตกต่างกันหลายร้อยแบบ วิศวกรศึกษา สร้างแบบจำลอง และพยายามทำความเข้าใจว่าเรือถูกใช้อย่างมีประสิทธิภาพเพียงใด เพราะเรือคอนเทนเนอร์ไม่ควรจอดนิ่งแม้แต่วินาทีเดียว การหยุดทำงานถือเป็นการสูญเสียเงิน ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องคาดการณ์เส้นทางเพื่อให้การหยุดทำงานน้อยที่สุด

ปัจจุบันมีการเติบโตของฐานข้อมูลเฉพาะที่วัดผล อนุกรมเวลา. ออนไลน์ DB- เครื่องยนต์ ฐานข้อมูลที่แตกต่างกันได้รับการจัดอันดับ และคุณสามารถดูได้ตามประเภท:

ประเภทที่เติบโตเร็วที่สุดคือ อนุกรมเวลาส. ฐานข้อมูลกราฟก็มีการเติบโตเช่นกัน แต่ อนุกรมเวลามีการเติบโตเร็วขึ้นในช่วงไม่กี่ปีที่ผ่านมา ตัวแทนทั่วไปของฐานข้อมูลตระกูลนี้คือ InfluxDB, โพร, KDB, ไทม์สเกลDB (สร้างขึ้นบน PostgreSQL) โซลูชั่นจาก อเมซอน. คลิกเฮาส์ สามารถใช้ที่นี่ได้เช่นกันและถูกใช้ ผมขอยกตัวอย่างสาธารณะบางส่วนให้คุณฟัง

หนึ่งในผู้บุกเบิกคือบริษัท CloudFlare (CDN-ผู้ให้บริการ). พวกเขาติดตามพวกเขา CDN ตลอด คลิกเฮาส์ (DNS-คำขอ HTTP-queries) ที่มีการโหลดจำนวนมาก - 6 ล้านเหตุการณ์ต่อวินาที ทุกอย่างผ่านไปได้ Kafka, ไปที่ คลิกเฮาส์ซึ่งให้โอกาสในการดูแดชบอร์ดเหตุการณ์ในระบบแบบเรียลไทม์

Comcast - หนึ่งในผู้นำด้านโทรคมนาคมในสหรัฐอเมริกา: อินเทอร์เน็ต โทรทัศน์ระบบดิจิทัล โทรศัพท์ พวกเขาสร้างระบบควบคุมที่คล้ายกัน CDN ภายใน โอเพนซอร์ส โครงการ การควบคุมการจราจรของอาปาเช่ เพื่อทำงานกับข้อมูลขนาดใหญ่ของคุณ คลิกเฮาส์ ใช้เป็นแบ็กเอนด์สำหรับการวิเคราะห์

เพอร์โคนา สร้างขึ้นใน คลิกเฮาส์ ภายในของคุณ PMMเพื่อจัดเก็บการติดตามต่างๆ MySQL.

ข้อกำหนดเฉพาะ

ฐานข้อมูลอนุกรมเวลามีข้อกำหนดเฉพาะของตนเอง

• การแทรกซึมที่รวดเร็วจากตัวแทนจำนวนมาก. เราต้องแทรกข้อมูลจากหลาย ๆ สตรีมอย่างรวดเร็ว คลิกเฮาส์ ทำได้ดีเพราะส่วนแทรกทั้งหมดไม่มีการปิดกั้น ใดๆ แทรก เป็นไฟล์ใหม่บนดิสก์และการแทรกขนาดเล็กสามารถบัฟเฟอร์ได้ไม่ทางใดก็ทางหนึ่ง ใน คลิกเฮาส์ เป็นการดีกว่าที่จะแทรกข้อมูลเป็นกลุ่มใหญ่แทนที่จะแทรกทีละบรรทัด
• โครงการที่ยืดหยุ่น. ใน อนุกรมเวลา โดยปกติแล้วเราจะไม่ทราบโครงสร้างข้อมูลอย่างสมบูรณ์ เป็นไปได้ที่จะสร้างระบบตรวจสอบสำหรับแอปพลิเคชันเฉพาะ แต่ใช้งานกับแอปพลิเคชันอื่นได้ยาก สิ่งนี้ต้องการรูปแบบที่ยืดหยุ่นมากขึ้น คลิกเฮาส์ช่วยให้คุณทำสิ่งนี้ได้ แม้ว่าจะเป็นฐานที่พิมพ์ยากก็ตาม
• การจัดเก็บที่มีประสิทธิภาพและการลืมข้อมูล. ปกติจะเข้า. อนุกรมเวลา ข้อมูลจำนวนมากจึงต้องถูกจัดเก็บอย่างมีประสิทธิภาพมากที่สุด ตัวอย่างเช่นที่ InfluxDB การบีบอัดที่ดีเป็นคุณสมบัติหลัก แต่นอกเหนือจากการจัดเก็บแล้ว คุณยังต้องสามารถ “ลืม” ข้อมูลเก่าและดำเนินการบางอย่างได้ด้วย ลดขนาด - การนับมวลรวมอัตโนมัติ
• สืบค้นข้อมูลที่รวบรวมอย่างรวดเร็ว. บางครั้งการดู 5 นาทีสุดท้ายด้วยความแม่นยำระดับมิลลิวินาทีก็น่าสนใจ แต่อาจไม่จำเป็นต้องระบุรายละเอียดนาทีหรือวินาทีของข้อมูลรายเดือน - สถิติทั่วไปก็เพียงพอแล้ว จำเป็นต้องมีการสนับสนุนประเภทนี้ มิฉะนั้นคำขอเป็นเวลา 3 เดือนจะใช้เวลานานมากในการดำเนินการให้เสร็จสิ้น คลิกเฮาส์.
• คำขอเช่น "จุดสุดท้าย ณ วันที่». สิ่งเหล่านี้เป็นเรื่องปกติสำหรับ อนุกรมเวลา คำถาม: ดูการวัดล่าสุดหรือสถานะของระบบในขณะนั้น t. สิ่งเหล่านี้ไม่ใช่การสืบค้นที่น่าพอใจสำหรับฐานข้อมูล แต่คุณต้องสามารถดำเนินการได้เช่นกัน
• อนุกรมเวลา "การติดกาว". อนุกรมเวลา เป็นอนุกรมเวลา หากมีอนุกรมเวลาสองชุด มักจะจำเป็นต้องเชื่อมโยงและเชื่อมโยงกัน ไม่สะดวกที่จะทำเช่นนี้กับทุกฐานข้อมูล โดยเฉพาะอย่างยิ่งเมื่อมีอนุกรมเวลาที่ไม่สอดคล้องกัน: นี่คือจุดเวลาบางส่วน และจุดอื่นๆ อีกด้วย ถือว่าปานกลางก็ได้ แต่จู่ๆ ก็ยังมีรูตรงนั้นจึงไม่ชัดเจน

มาดูกันว่ามีคุณสมบัติตรงตามข้อกำหนดเหล่านี้อย่างไร คลิกเฮาส์.

โครงการนี้

В คลิกเฮาส์ โครงการสำหรับ อนุกรมเวลา สามารถทำได้หลายวิธี ขึ้นอยู่กับระดับความสม่ำเสมอของข้อมูล เป็นไปได้ที่จะสร้างระบบจากข้อมูลปกติเมื่อเราทราบตัวชี้วัดทั้งหมดล่วงหน้า ตัวอย่างเช่นฉันทำสิ่งนี้ CloudFlare กับการเฝ้าติดตาม CDN เป็นระบบที่ได้รับการปรับปรุงอย่างดี คุณสามารถสร้างระบบทั่วไปที่ตรวจสอบโครงสร้างพื้นฐานทั้งหมดและบริการต่างๆ ได้ ในกรณีของข้อมูลที่ผิดปกติ เราไม่ทราบล่วงหน้าว่าเรากำลังติดตามอะไรอยู่ และนี่อาจเป็นกรณีที่พบบ่อยที่สุด

ข้อมูลปกติ คอลัมน์ โครงร่างนั้นง่าย - คอลัมน์ที่มีประเภทที่ต้องการ:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

นี่คือตารางปกติที่ตรวจสอบกิจกรรมการโหลดระบบบางประเภท (ผู้ใช้งาน, ระบบ, ว่าง, ดี). ง่ายและสะดวก แต่ไม่ยืดหยุ่น หากเราต้องการรูปแบบที่ยืดหยุ่นมากขึ้น เราก็สามารถใช้อาร์เรย์ได้

ข้อมูลที่ผิดปกติ อาร์เรย์:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

โครงสร้าง ซ้อนกัน เป็นสองอาร์เรย์: metrics.name и metrics.value. ที่นี่คุณสามารถจัดเก็บข้อมูลการตรวจสอบที่กำหนดเองเป็นอาร์เรย์ของชื่อและอาร์เรย์ของการวัดสำหรับแต่ละเหตุการณ์ได้ สำหรับการเพิ่มประสิทธิภาพเพิ่มเติม แทนที่จะสร้างโครงสร้างดังกล่าวเพียงโครงสร้างเดียว คุณสามารถสร้างได้หลายโครงสร้าง ตัวอย่างเช่นหนึ่งรายการสำหรับ ลอย-value อีกประการหนึ่ง - สำหรับ int-ความหมายเพราะ int ฉันต้องการจัดเก็บอย่างมีประสิทธิภาพมากขึ้น

แต่โครงสร้างดังกล่าวเข้าถึงได้ยากกว่า คุณจะต้องใช้โครงสร้างพิเศษโดยใช้ฟังก์ชันพิเศษเพื่อดึงค่าของดัชนีแรกแล้วตามด้วยอาร์เรย์:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

แต่มันก็ยังทำงานได้ค่อนข้างเร็ว อีกวิธีหนึ่งในการจัดเก็บข้อมูลที่ผิดปกติคือเรียงตามแถว

ข้อมูลที่ผิดปกติ สตริง. ในวิธีการดั้งเดิมนี้ หากไม่มีอาร์เรย์ ชื่อและค่าจะถูกจัดเก็บพร้อมกัน หากการวัด 5 รายการมาจากอุปกรณ์เครื่องเดียวในคราวเดียว ระบบจะสร้างแถว 000 แถวในฐานข้อมูล:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

คลิกเฮาส์ รับมือกับสิ่งนี้ - มีส่วนขยายพิเศษ คลิกเฮาส์ SQL. ตัวอย่างเช่น สูงสุดถ้า — ฟังก์ชันพิเศษที่คำนวณค่าสูงสุดด้วยหน่วยเมตริกเมื่อตรงตามเงื่อนไขบางประการ คุณสามารถเขียนนิพจน์ดังกล่าวได้หลายรายการในคำขอเดียว และคำนวณค่าสำหรับเมตริกต่างๆ ได้ทันที

ลองเปรียบเทียบสามวิธี:

รายละเอียด

ที่นี่ฉันได้เพิ่ม "ขนาดข้อมูลดิสก์" สำหรับชุดข้อมูลทดสอบบางชุด ในกรณีของคอลัมน์ เรามีขนาดข้อมูลที่เล็กที่สุด ได้แก่ การบีบอัดสูงสุด ความเร็วการสืบค้นสูงสุด แต่เราจ่ายโดยต้องบันทึกทุกอย่างในครั้งเดียว

ในกรณีของอาร์เรย์ ทุกอย่างจะแย่ลงเล็กน้อย ข้อมูลยังคงมีการบีบอัดอย่างดีและสามารถจัดเก็บรูปแบบที่ไม่ปกติได้ แต่ คลิกเฮาส์ - ฐานข้อมูลแบบเรียงเป็นแนว และเมื่อเราเริ่มจัดเก็บทุกอย่างในอาร์เรย์ มันก็จะกลายเป็นฐานข้อมูลแถวหนึ่ง และเราต้องจ่ายค่าความยืดหยุ่นอย่างมีประสิทธิภาพ สำหรับการดำเนินการใด ๆ คุณจะต้องอ่านอาเรย์ทั้งหมดลงในหน่วยความจำจากนั้นค้นหาองค์ประกอบที่ต้องการในนั้น - และหากอาเรย์เพิ่มขึ้นความเร็วก็จะลดลง

ในบริษัทแห่งหนึ่งที่ใช้แนวทางนี้ (เช่น Uber) อาร์เรย์จะถูกตัดออกเป็นชิ้นๆ ละ 128 องค์ประกอบ ข้อมูลจากตัววัดหลายพันตัวที่มีปริมาณข้อมูล 200 TB ต่อวันไม่ได้จัดเก็บไว้ในอาร์เรย์เดียว แต่อยู่ใน 10 หรือ 30 อาร์เรย์ที่มีตรรกะการจัดเก็บข้อมูลพิเศษ

วิธีที่ง่ายที่สุดคือใช้สตริง แต่ข้อมูลได้รับการบีบอัดไม่ดี ตารางมีขนาดใหญ่ และแม้ว่าการสืบค้นจะขึ้นอยู่กับเมตริกหลายรายการ ClickHouse ก็ทำงานได้ไม่เต็มประสิทธิภาพ

โครงการไฮบริด

สมมติว่าเราได้เลือกวงจรอาเรย์ แต่ถ้าเรารู้ว่าแดชบอร์ดส่วนใหญ่ของเราแสดงเฉพาะเมตริกผู้ใช้และระบบ เราก็สามารถทำให้เมตริกเหล่านี้เป็นคอลัมน์จากอาร์เรย์ที่ระดับตารางเพิ่มเติมได้ในลักษณะนี้:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

เมื่อใส่ คลิกเฮาส์ จะนับให้โดยอัตโนมัติ วิธีนี้ทำให้คุณสามารถรวมธุรกิจเข้ากับความสุขได้: รูปแบบมีความยืดหยุ่นและเป็นทั่วไป แต่เราดึงคอลัมน์ที่ใช้บ่อยที่สุดออกมา โปรดทราบว่าสิ่งนี้ไม่จำเป็นต้องเปลี่ยนส่วนแทรกและ ETLซึ่งยังคงแทรกอาร์เรย์ลงในตารางต่อไป เราเพิ่งทำ แก้ไขตารางเพิ่มลำโพงสองสามตัว และเรามีรูปแบบไฮบริดที่เร็วกว่าซึ่งคุณสามารถเริ่มใช้งานได้ทันที

ตัวแปลงสัญญาณและการบีบอัด

สำหรับ อนุกรมเวลา สิ่งสำคัญคือคุณจะแพ็คข้อมูลได้ดีเพียงใด เนื่องจากปริมาณข้อมูลอาจมีขนาดใหญ่มาก ใน คลิกเฮาส์ มีชุดเครื่องมือเพื่อให้ได้เอฟเฟกต์การบีบอัดที่ 1:10, 1:20 และบางครั้งก็มากกว่านั้น ซึ่งหมายความว่าข้อมูลที่คลายแพ็กแล้ว 1 TB บนดิสก์จะใช้พื้นที่ 50-100 GB ขนาดที่เล็กลงก็ดี สามารถอ่านและประมวลผลข้อมูลได้เร็วขึ้น

เพื่อให้ได้การบีบอัดในระดับสูง คลิกเฮาส์ รองรับตัวแปลงสัญญาณต่อไปนี้:

ตารางตัวอย่าง:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

ที่นี่เรากำหนดตัวแปลงสัญญาณ ดับเบิลเดลต้า ในกรณีหนึ่ง ครั้งที่สอง - กอริลลาและเราจะเพิ่มมากขึ้นอย่างแน่นอน LZ4 การบีบอัด เป็นผลให้ขนาดของข้อมูลบนดิสก์ลดลงอย่างมาก:

นี่จะแสดงพื้นที่ที่ข้อมูลเดียวกันใช้ แต่ใช้ตัวแปลงสัญญาณและการบีบอัดต่างกัน:

• ในไฟล์ GZIP บนดิสก์
• ใน ClickHouse ที่ไม่มีตัวแปลงสัญญาณ แต่มีการบีบอัด ZSTD
• ใน ClickHouse พร้อมตัวแปลงสัญญาณและการบีบอัด LZ4 และ ZSTD

จะเห็นได้ว่าตารางที่มีตัวแปลงสัญญาณใช้พื้นที่น้อยกว่ามาก

เรื่องขนาด

สำคัญไม่น้อย выбрать ประเภทข้อมูลที่ถูกต้อง:

ในตัวอย่างทั้งหมดข้างต้นฉันใช้ ลอย 64. แต่ถ้าเราเลือก ลอย 32ถ้าอย่างนั้นมันจะดีกว่านี้อีก สิ่งนี้แสดงให้เห็นได้ดีโดยคนจาก Perkona ในบทความที่ลิงก์ด้านบน สิ่งสำคัญคือต้องใช้ประเภทที่กะทัดรัดที่สุดที่เหมาะกับงาน: ขนาดดิสก์จะเล็กกว่าความเร็วการสืบค้นด้วยซ้ำ คลิกเฮาส์ อ่อนไหวต่อสิ่งนี้มาก

ถ้าคุณสามารถใช้ int32 แทน int64จากนั้นคาดหวังว่าประสิทธิภาพจะเพิ่มขึ้นเกือบสองเท่า ข้อมูลใช้หน่วยความจำน้อยลง และ "เลขคณิต" ทั้งหมดทำงานเร็วขึ้นมาก คลิกเฮาส์ ภายในเป็นระบบที่พิมพ์อย่างเคร่งครัดโดยใช้ประโยชน์จากความเป็นไปได้ทั้งหมดที่ระบบสมัยใหม่มอบให้ให้เกิดประโยชน์สูงสุด

การรวมตัวและ มุมมองที่เป็นรูปธรรม

การรวมกลุ่มและมุมมองที่เป็นรูปธรรมทำให้คุณสามารถสร้างการรวมสำหรับโอกาสต่างๆ ได้:

ตัวอย่างเช่น คุณอาจมีข้อมูลต้นฉบับที่ไม่ได้รวบรวมไว้ และคุณสามารถแนบมุมมองที่เป็นรูปธรรมต่างๆ เข้ากับข้อมูลเหล่านั้นด้วยการสรุปอัตโนมัติผ่านกลไกพิเศษ SummingMergeTree (SMT). SMT เป็นโครงสร้างข้อมูลการรวมพิเศษที่คำนวณการรวมโดยอัตโนมัติ ข้อมูลดิบจะถูกแทรกลงในฐานข้อมูล และจะถูกรวบรวมโดยอัตโนมัติ และสามารถใช้แดชบอร์ดได้ทันที

TTL - “ลืม” ข้อมูลเก่า

จะ “ลืม” ข้อมูลที่ไม่จำเป็นอีกต่อไปได้อย่างไร? คลิกเฮาส์ รู้วิธีการทำเช่นนี้ เมื่อสร้างตารางคุณสามารถระบุได้ TTL นิพจน์: ตัวอย่างเช่น เราจัดเก็บข้อมูลนาทีเป็นเวลาหนึ่งวัน ข้อมูลรายวันเป็นเวลา 30 วัน และไม่เคยแตะข้อมูลรายสัปดาห์หรือรายเดือน:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

หลายชั้น - แบ่งข้อมูลข้ามดิสก์

เมื่อนำแนวคิดนี้ไปใช้เพิ่มเติม ก็สามารถจัดเก็บข้อมูลได้ คลิกเฮาส์ ในสถานที่ต่าง ๆ สมมติว่าเราต้องการเก็บข้อมูลยอดนิยมของสัปดาห์ที่แล้วไว้ในเครื่องที่รวดเร็วมาก SSDและเราได้ใส่ข้อมูลในอดีตเพิ่มเติมไว้ในที่อื่น ใน คลิกเฮาส์ ตอนนี้เป็นไปได้แล้ว:

คุณสามารถกำหนดค่านโยบายการจัดเก็บ (นโยบายการจัดเก็บ) ดังนั้น คลิกเฮาส์ จะถ่ายโอนข้อมูลโดยอัตโนมัติเมื่อถึงเงื่อนไขบางประการไปยังที่เก็บข้อมูลอื่น

แต่นั่นไม่ใช่ทั้งหมด ที่ระดับของตารางเฉพาะ คุณสามารถกำหนดกฎว่าข้อมูลจะเข้าสู่ห้องเย็นเมื่อใด ตัวอย่างเช่น ข้อมูลจะถูกจัดเก็บไว้ในดิสก์ที่เร็วมากเป็นเวลา 7 วัน และทุกสิ่งที่เก่ากว่าจะถูกถ่ายโอนไปยังดิสก์ที่ช้า นี่เป็นสิ่งที่ดีเพราะช่วยให้คุณรักษาระบบให้มีประสิทธิภาพสูงสุดในขณะที่ควบคุมต้นทุนและไม่เปลืองเงินกับข้อมูลที่เก็บไว้:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

คุณลักษณะเฉพาะ คลิกเฮาส์

ในแทบทุกเรื่อง คลิกเฮาส์ มี "ไฮไลท์" ดังกล่าว แต่ถูกชดเชยด้วยความพิเศษ - สิ่งที่ไม่ได้อยู่ในฐานข้อมูลอื่น ตัวอย่างเช่น ต่อไปนี้เป็นคุณลักษณะเฉพาะบางส่วน คลิกเฮาส์:

• อาร์เรย์. ใน คลิกเฮาส์ การสนับสนุนอาร์เรย์ที่ดีมากรวมถึงความสามารถในการคำนวณที่ซับซ้อน
• การรวมโครงสร้างข้อมูล. นี่เป็นหนึ่งใน "คุณสมบัตินักฆ่า" คลิกเฮาส์. แม้ว่าคนจากยานเดกซ์จะบอกว่าเราไม่ต้องการรวบรวมข้อมูล แต่ทุกอย่างก็รวมเข้าด้วยกัน คลิกเฮาส์เพราะมันสะดวกและรวดเร็ว
• มุมมองที่เป็นรูปธรรม. เมื่อรวมกับโครงสร้างข้อมูลที่รวบรวม มุมมองที่เป็นรูปธรรมช่วยให้คุณได้รับความสะดวก เรียลไทม์ การรวมตัว
• คลิกเฮาส์ SQL. นี่คือส่วนขยายภาษา SQL พร้อมคุณสมบัติพิเศษเพิ่มเติมบางอย่างที่มีเฉพาะใน คลิกเฮาส์. ก่อนหน้านี้เป็นเหมือนการขยายตัวในด้านหนึ่งและเป็นข้อเสียในอีกด้านหนึ่ง ตอนนี้ข้อเสียเกือบทั้งหมดเมื่อเทียบกับ เอสคิวแอล 92 เราลบมันออกไปแล้ว ตอนนี้มันเป็นเพียงส่วนขยาย
• แลมบ์ดา–การแสดงออก. พวกเขายังอยู่ในฐานข้อมูลใด ๆ หรือไม่?
• ML-สนับสนุน. ข้อมูลนี้มีอยู่ในฐานข้อมูลต่างๆ บ้างก็ดีกว่า บ้างก็แย่กว่า
• โอเพ่นซอร์ส. เราสามารถขยายได้ คลิกเฮาส์ ด้วยกัน. ตอนนี้เข้าแล้ว คลิกเฮาส์ มีผู้ร่วมให้ข้อมูลประมาณ 500 ราย และจำนวนนี้เพิ่มขึ้นอย่างต่อเนื่อง

คำถามหากิน

В คลิกเฮาส์ มีหลายวิธีในการทำสิ่งเดียวกัน ตัวอย่างเช่น คุณสามารถคืนค่าสุดท้ายจากตารางได้สามวิธี ซีพียู (ยังมีอันที่สี่ด้วย แต่มันแปลกใหม่ยิ่งกว่านั้นอีก)

อันแรกแสดงให้เห็นว่าสะดวกแค่ไหนในการทำ คลิกเฮาส์ สอบถามเมื่อคุณต้องการตรวจสอบสิ่งนั้น ทูเพิล ที่มีอยู่ในแบบสอบถามย่อย นี่คือสิ่งที่ฉันพลาดเป็นการส่วนตัวในฐานข้อมูลอื่น หากฉันต้องการเปรียบเทียบบางสิ่งกับแบบสอบถามย่อยในฐานข้อมูลอื่นสามารถเปรียบเทียบได้เฉพาะสเกลาร์เท่านั้น แต่สำหรับหลายคอลัมน์ฉันต้องเขียน สมัคร. ใน คลิกเฮาส์ คุณสามารถใช้สิ่งอันดับ:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

วิธีที่สองทำสิ่งเดียวกันแต่ใช้ฟังก์ชันการรวม หาเรื่องMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В คลิกเฮาส์ มีฟังก์ชันรวมหลายสิบฟังก์ชันและหากคุณใช้ตัวรวมกันคุณจะได้รับฟังก์ชันประมาณหนึ่งพันฟังก์ชันตามกฎหมายของตัวรวมกัน อาร์กแม็กซ์ - หนึ่งในฟังก์ชันที่คำนวณค่าสูงสุด: คำขอส่งคืนค่า การใช้งาน_ผู้ใช้ซึ่งถึงค่าสูงสุดแล้ว สร้าง_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF เข้าร่วม — “ติดกาว” แถวที่มีเวลาต่างกัน นี่เป็นคุณลักษณะเฉพาะสำหรับฐานข้อมูลที่มีเฉพาะในเท่านั้น เคดีบี+. หากมีอนุกรมเวลาสองชุดที่มีเวลาต่างกัน ASOF เข้าร่วม ช่วยให้คุณสามารถย้ายและรวมเข้าด้วยกันในคำขอเดียว สำหรับแต่ละค่าในอนุกรมเวลาหนึ่ง จะพบค่าที่ใกล้เคียงที่สุดในอีกค่าหนึ่ง และจะถูกส่งกลับในบรรทัดเดียวกัน:

ฟังก์ชั่นการวิเคราะห์

อยู่ในมาตรฐาน เอสคิวแอล-2003 คุณสามารถเขียนดังนี้:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В คลิกเฮาส์ คุณไม่สามารถทำเช่นนั้นได้ - มันไม่รองรับมาตรฐาน เอสคิวแอล-2003 และคงจะไม่มีวันทำแบบนั้น แทนใน คลิกเฮาส์ เป็นเรื่องปกติที่จะเขียนดังนี้:

ฉันสัญญากับแลมบ์ดา - นี่ไง!

นี่เป็นอะนาล็อกของการสืบค้นเชิงวิเคราะห์ในมาตรฐาน เอสคิวแอล-2003: เขานับความแตกต่างระหว่างทั้งสอง การประทับเวลา, ระยะเวลา, เลขลำดับ - ทุกสิ่งที่เรามักจะพิจารณาฟังก์ชันการวิเคราะห์ ใน คลิกเฮาส์ เรานับพวกมันผ่านอาร์เรย์ ขั้นแรกเราจะยุบข้อมูลลงในอาร์เรย์ หลังจากนั้นเราจะทำทุกอย่างที่เราต้องการในอาร์เรย์ จากนั้นจึงขยายกลับ ไม่สะดวกนัก ต้องอาศัยความรักในการเขียนโปรแกรมเชิงฟังก์ชันเป็นอย่างน้อย แต่ก็มีความยืดหยุ่นมาก

คุณสมบัติพิเศษ

นอกจากนี้ใน คลิกเฮาส์ ฟังก์ชั่นพิเศษมากมาย เช่น จะทราบได้อย่างไรว่าเซสชันต่างๆ ที่เกิดขึ้นพร้อมกันมีกี่เซสชัน? งานตรวจสอบทั่วไปคือการกำหนดโหลดสูงสุดด้วยคำขอเดียว ใน คลิกเฮาส์ มีฟังก์ชั่นพิเศษเพื่อการนี้:

โดยทั่วไป ClickHouse มีฟังก์ชั่นพิเศษเพื่อวัตถุประสงค์หลายประการ:

• runningDifference, runningAccumulate, เพื่อนบ้าน;
• sumMap(คีย์, ค่า);
• timeSeriesGroupSum(uid, การประทับเวลา, ค่า);
• timeSeriesGroupRateSum (uid, การประทับเวลา, ค่า);
• skewPop, skewSamp, เคิร์ตป๊อป, เคิร์ตแซม;
• ด้วยการกรอก / ด้วยความสัมพันธ์;
• simpleLinearRegression, stochasticLinearRegression

นี่ไม่ใช่รายการฟังก์ชันทั้งหมด มีทั้งหมด 500-600 รายการ คำแนะนำ: ฟังก์ชั่นทั้งหมดใน คลิกเฮาส์ อยู่ในตารางระบบ (ไม่ใช่ทั้งหมดที่ได้รับการบันทึกไว้ แต่ทั้งหมดน่าสนใจ):

select * from system.functions order by name

คลิกเฮาส์ มันเก็บข้อมูลมากมายเกี่ยวกับตัวมันเอง รวมถึง ตารางบันทึก, แบบสอบถาม_log, บันทึกการติดตาม, บันทึกการดำเนินการพร้อมบล็อกข้อมูล (part_log) บันทึกเมทริก และบันทึกระบบ ซึ่งโดยปกติจะเขียนลงดิสก์ ตัวชี้วัดบันทึกคือ อนุกรมเวลา в คลิกเฮาส์ จริงๆ แล้ว คลิกเฮาส์: ฐานข้อมูลเองก็สามารถมีบทบาทได้ อนุกรมเวลา ฐานข้อมูลจึง "กลืนกิน" ตัวมันเอง

นี่เป็นสิ่งพิเศษเช่นกัน เนื่องจากเราทำงานได้ดี อนุกรมเวลาเหตุใดเราจึงไม่สามารถเก็บทุกสิ่งที่เราต้องการไว้ในตัวเราเองได้? เราไม่จำเป็นต้อง โพร, เราเก็บทุกอย่างไว้กับตัวเอง เชื่อมต่อแล้ว กราฟาน่า และเราติดตามตัวเอง อย่างไรก็ตามหาก คลิกเฮาส์ ล้ม เราจะไม่เห็นสาเหตุ ดังนั้นพวกเขาจึงไม่ทำอย่างนั้น

เป็นกลุ่มใหญ่หรือกลุ่มเล็กจำนวนมาก คลิกเฮาส์

อะไรจะดีไปกว่า - คลัสเตอร์ขนาดใหญ่หนึ่งคลัสเตอร์หรือ ClickHouses ขนาดเล็กจำนวนมาก แนวทางดั้งเดิมในการ ด.ช เป็นคลัสเตอร์ขนาดใหญ่ที่มีการจัดสรรวงจรสำหรับแต่ละแอปพลิเคชัน เรามาหาผู้ดูแลฐานข้อมูล - ให้ไดอะแกรมแก่เรา และพวกเขาก็ให้อันหนึ่งแก่เรา:

В คลิกเฮาส์ คุณสามารถทำได้แตกต่างออกไป คุณสามารถทำให้แต่ละแอปพลิเคชันเป็นของคุณเองได้ คลิกเฮาส์:

เราไม่ต้องการสัตว์ประหลาดตัวใหญ่อีกต่อไป ด.ช และผู้ดูแลระบบที่ดื้อรั้น เราสามารถให้แต่ละแอปพลิเคชันเป็นของตัวเองได้ คลิกเฮาส์และผู้พัฒนาก็สามารถทำได้ด้วยตัวเองตั้งแต่นั้นเป็นต้นมา คลิกเฮาส์ ติดตั้งง่ายมากและไม่ต้องการการดูแลระบบที่ซับซ้อน:

แต่หากเรามีมาก คลิกเฮาส์และคุณต้องติดตั้งบ่อยครั้ง จากนั้นคุณต้องการทำให้กระบวนการนี้เป็นแบบอัตโนมัติ สำหรับสิ่งนี้ เราสามารถใช้ ตัวอย่างเช่น Kubernetes и คลิกเฮาส์-โอเปอเรเตอร์ ใน Kubernetes คลิกเฮาส์ คุณสามารถใส่มัน "เมื่อคลิก": ฉันสามารถคลิกปุ่ม เรียกใช้รายการและฐานข้อมูลก็พร้อม ฉันสามารถสร้างไดอะแกรมได้ทันที เริ่มอัปโหลดเมตริกที่นั่น และภายใน 5 นาที ฉันก็จะมีแดชบอร์ดที่พร้อม กราฟาน่า. มันง่ายมาก!

ผลหรือไม่

ดังนั้น คลิกเฮาส์ - นี่คือ:

• อย่างรวดเร็ว. ทุกคนรู้เรื่องนี้
• เพียงแค่. มีข้อโต้แย้งเล็กน้อย แต่ฉันเชื่อว่ามันยากในการฝึกฝนและง่ายในการต่อสู้ ถ้าคุณเข้าใจวิธีการ คลิกเฮาส์ มันใช้งานได้แล้วทุกอย่างก็ง่ายมาก
• อย่างกว้างขวาง. เหมาะสำหรับสถานการณ์ที่แตกต่างกัน: DWH, อนุกรมเวลา, การจัดเก็บบันทึก. แต่มันไม่ใช่ OLTP ดังนั้นอย่าพยายามแทรกสั้นๆ แล้วอ่านตรงนั้น
• อย่างน่าสนใจ. น่าจะเป็นคนที่ร่วมงานด้วย คลิกเฮาส์พบกับช่วงเวลาที่น่าสนใจมากมายทั้งในแง่ดีและไม่ดี ตัวอย่างเช่นมีรุ่นใหม่ออกมาทุกอย่างหยุดทำงาน หรือเมื่อคุณดิ้นรนกับงานเป็นเวลาสองวัน แต่หลังจากถามคำถามในการแชทของ Telegram งานก็ได้รับการแก้ไขภายในสองนาที หรือเช่นในการประชุมตามรายงานของ Lesha Milovidov ภาพหน้าจอจาก คลิกเฮาส์ ทำลายการออกอากาศ โหลดสูง++. เรื่องแบบนี้เกิดขึ้นตลอดเวลาและทำให้ชีวิตเราลำบาก คลิกเฮาส์ สดใสและน่าสนใจ!

ท่านสามารถรับชมการนำเสนอ ที่นี่.

การประชุมนักพัฒนาระบบโหลดสูงที่รอคอยมานานที่ โหลดสูง++ จะมีขึ้นในวันที่ 9 และ 10 พฤศจิกายนที่เมือง Skolkovo สุดท้ายนี้ จะเป็นการประชุมแบบออฟไลน์ (แม้ว่าจะมีข้อควรระวังทั้งหมด) เนื่องจากพลังงานของ HighLoad++ ไม่สามารถบรรจุทางออนไลน์ได้

สำหรับการประชุม เราค้นหาและแสดงกรณีต่างๆ เกี่ยวกับความสามารถสูงสุดของเทคโนโลยี: HighLoad++ เคยเป็น เป็น และจะเป็นสถานที่เดียวที่คุณสามารถเรียนรู้ได้ภายในสองวันว่า Facebook, Yandex, VKontakte, Google และ Amazon ทำงานอย่างไร

จัดการประชุมอย่างต่อเนื่องมาตั้งแต่ปี 2007 ปีนี้เราจะพบกันเป็นครั้งที่ 14 ในช่วงเวลานี้ การประชุมเติบโตขึ้น 10 ครั้ง โดยในปีที่แล้ว งานสำคัญในอุตสาหกรรมมีผู้เข้าร่วม 3339 คน วิทยากร 165 คน รายงาน และการพบปะ และมี 16 แทร็กที่ดำเนินไปพร้อมกัน
ปีที่แล้วมีรถบัส 20 คัน ชาและกาแฟ 5280 ลิตร เครื่องดื่มผลไม้ 1650 ลิตร และน้ำดื่ม 10200 ขวด และอาหารอีก 2640 กิโลกรัม จาน 16 จาน 000 ถ้วย ยังไงก็ตาม ด้วยเงินที่ได้จากกระดาษรีไซเคิล เราได้ปลูกต้นโอ๊ก 25 ต้น :)

คุณสามารถซื้อตั๋วได้ ที่นี่, รับข่าวสารเกี่ยวกับการประชุม - ที่นี่และพูดคุยบนโซเชียลเน็ตเวิร์กทั้งหมด: Telegram, Facebook, vkontakte и Twitter.

ที่มา: will.com