ทฤษฎีและปฏิบัติการใช้ ClickHouse ในการใช้งานจริง อเล็กซานเดอร์ ไซตเซฟ (2018)

แม้จะมีความจริงที่ว่าขณะนี้มีข้อมูลจำนวนมากเกือบทุกที่ แต่ฐานข้อมูลเชิงวิเคราะห์ยังคงค่อนข้างแปลกใหม่ พวกเขาเป็นที่รู้จักไม่ดีและแย่กว่านั้นคือสามารถใช้มันได้อย่างมีประสิทธิภาพ หลายคนยังคง "กินต้นกระบองเพชร" ด้วย MySQL หรือ PostgreSQL ซึ่งออกแบบมาสำหรับสถานการณ์อื่นๆ ประสบปัญหากับ NoSQL หรือจ่ายเงินมากเกินไปสำหรับโซลูชันเชิงพาณิชย์ ClickHouse เปลี่ยนกฎของเกมและลดเกณฑ์สำหรับการเข้าสู่โลกแห่งการวิเคราะห์ DBMS ลงอย่างมาก

รายงานจาก BackEnd Conf 2018 และเผยแพร่โดยได้รับอนุญาตจากวิทยากร

ฉันเป็นใครและทำไมฉันถึงพูดถึง ClickHouse? ฉันเป็นผู้อำนวยการฝ่ายพัฒนาที่ LifeStreet ซึ่งใช้ ClickHouse นอกจากนี้ ฉันยังเป็นผู้ก่อตั้ง Altinity เป็นพันธมิตร Yandex ที่ส่งเสริม ClickHouse และช่วย Yandex ทำให้ ClickHouse ประสบความสำเร็จมากขึ้น พร้อมแบ่งปันความรู้เกี่ยวกับ ClickHouse

และฉันไม่ใช่พี่ชายของ Petya Zaitsev ฉันมักถูกถามเกี่ยวกับเรื่องนี้ ไม่ เราไม่ใช่พี่น้องกัน

“ทุกคนรู้” ว่า ClickHouse:

• เร็วมาก,
• สะดวกสบายมาก
• ใช้ในยานเดกซ์

ไม่ค่อยมีใครรู้ว่า บริษัท ใดและใช้งานอย่างไร

ฉันจะบอกคุณว่าทำไมใช้ ClickHouse ที่ไหนและอย่างไรยกเว้น Yandex

ฉันจะบอกคุณว่างานบางอย่างได้รับการแก้ไขด้วยความช่วยเหลือของ ClickHouse ในบริษัทต่างๆ อย่างไร เครื่องมือ ClickHouse ใดที่คุณสามารถใช้กับงานของคุณ และวิธีการใช้งานในบริษัทต่างๆ

ฉันเลือกสามตัวอย่างที่แสดง ClickHouse จากมุมที่แตกต่างกัน ฉันคิดว่ามันจะน่าสนใจ

คำถามแรกคือ “ทำไมเราถึงต้องการ ClickHouse” ดูเหมือนจะเป็นคำถามที่ค่อนข้างชัดเจน แต่มีคำตอบมากกว่าหนึ่งข้อ

• คำตอบแรกสำหรับประสิทธิภาพ ClickHouse รวดเร็วมาก การวิเคราะห์บน ClickHouse นั้นเร็วมากเช่นกัน มักใช้ในกรณีที่อย่างอื่นช้ามากหรือแย่มาก
• คำตอบที่สองคือค่าใช้จ่าย และประการแรก ค่าใช้จ่ายในการปรับขนาด ตัวอย่างเช่น Vertica เป็นฐานข้อมูลที่ยอดเยี่ยมมาก ทำงานได้ดีมากหากคุณไม่มีข้อมูลเทราไบต์จำนวนมาก แต่เมื่อพูดถึงขนาดหลายร้อยเทราไบต์หรือเพตะไบต์ ค่าใช้จ่ายของใบอนุญาตและการสนับสนุนจะค่อนข้างสูง และมีราคาแพง และ ClickHouse นั้นฟรี
• คำตอบที่สามคือค่าใช้จ่ายในการดำเนินการ นี่เป็นแนวทางที่แตกต่างกันเล็กน้อย RedShift เป็นอะนาล็อกที่ยอดเยี่ยม บน RedShift คุณสามารถตัดสินใจได้อย่างรวดเร็ว มันจะทำงานได้ดี แต่ในขณะเดียวกัน ทุกชั่วโมง ทุกวัน และทุกเดือน คุณจะต้องจ่ายเงินให้กับ Amazon ค่อนข้างแพง เพราะนี่เป็นบริการที่มีราคาแพงมาก Google BigQuery ก็เช่นกัน หากมีคนใช้มัน เขารู้ว่าที่นั่นคุณสามารถส่งคำขอหลายรายการและรับเงินหลายร้อยดอลลาร์ในทันที

ClickHouse ไม่มีปัญหาเหล่านี้

ClickHouse ใช้อยู่ที่ไหนแล้ว นอกจากยานเดกซ์แล้ว ClickHouse ยังใช้ในธุรกิจและบริษัทต่างๆ มากมาย

• ประการแรก นี่คือการวิเคราะห์เว็บแอปพลิเคชัน เช่น นี่คือกรณีการใช้งานที่มาจากยานเดกซ์
• บริษัท AdTech หลายแห่งใช้ ClickHouse
• บริษัทจำนวนมากที่ต้องวิเคราะห์บันทึกธุรกรรมจากแหล่งต่างๆ
• หลายบริษัทใช้ ClickHouse เพื่อตรวจสอบบันทึกความปลอดภัย พวกเขาอัปโหลดไปยัง ClickHouse สร้างรายงาน และรับผลลัพธ์ที่ต้องการ
• บริษัทต่างๆ เริ่มนำมาใช้ในการวิเคราะห์ทางการเงิน เช่น ธุรกิจขนาดใหญ่ค่อยๆ เข้าใกล้ ClickHouse ด้วยเช่นกัน
• เปลวไฟ ถ้าใครติดตาม ClickHouse ก็คงเคยได้ยินชื่อบริษัทนี้มาบ้าง นี่เป็นหนึ่งในผู้มีส่วนร่วมที่สำคัญจากชุมชน และพวกเขามีการติดตั้ง ClickHouse ที่จริงจังมาก ตัวอย่างเช่น พวกเขาสร้าง Kafka Engine สำหรับ ClickHouse
• บริษัทโทรคมนาคมเริ่มใช้. หลายบริษัทใช้ ClickHouse เพื่อพิสูจน์แนวคิดหรืออยู่ในขั้นตอนการผลิตแล้ว
• บริษัทแห่งหนึ่งใช้ ClickHouse เพื่อตรวจสอบกระบวนการผลิต พวกเขาทดสอบไมโครเซอร์กิต ตัดค่าพารามิเตอร์ออก มีลักษณะประมาณ 2 รายการ จากนั้นพวกเขาก็วิเคราะห์ว่าเกมนั้นดีหรือไม่ดี
• การวิเคราะห์บล็อกเชน มี บริษัท รัสเซียเช่น Bloxy.info นี่คือการวิเคราะห์เครือข่าย ethereum พวกเขาทำสิ่งนี้ใน ClickHouse ด้วย

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

และถ้าคุณดูบันทึกแล้ว:

• ยานเดกซ์: เซิร์ฟเวอร์กว่า 500+ แห่ง พวกเขาจัดเก็บบันทึก 25 พันล้านรายการต่อวันที่นั่น
• LifeStreet: 60 เซิร์ฟเวอร์ ประมาณ 75 พันล้านบันทึกต่อวัน มีเซิร์ฟเวอร์น้อยกว่า บันทึกมากกว่าในยานเดกซ์
• CloudFlare: 36 เซิร์ฟเวอร์ บันทึก 200 พันล้านบันทึกต่อวัน พวกเขามีเซิร์ฟเวอร์น้อยลงและเก็บข้อมูลได้มากขึ้น
• Bloomberg: 102 เซิร์ฟเวอร์ ประมาณล้านล้านรายการต่อวัน เจ้าของสถิติ.

ในทางภูมิศาสตร์นี่ก็เป็นจำนวนมากเช่นกัน แผนที่นี้แสดงแผนที่ความร้อนของสถานที่ที่ใช้ ClickHouse ในโลก รัสเซีย จีน อเมริกา โดดเด่นตรงนี้ มีไม่กี่ประเทศในยุโรป และมี 4 กลุ่ม

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

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

นี่คือตัวอย่างการใช้งานจริงของ ClickHouse ในหลายบริษัท

• ตัวอย่างแรกคือเครือข่ายโฆษณา: การย้ายจาก Vertica ไปยัง ClickHouse และฉันรู้จักบริษัทไม่กี่แห่งที่เปลี่ยนจาก Vertica หรืออยู่ในกระบวนการเปลี่ยนผ่าน
• ตัวอย่างที่สองคือพื้นที่จัดเก็บธุรกรรมบน ClickHouse นี่เป็นตัวอย่างที่สร้างขึ้นจาก antipatterns ทุกสิ่งที่ไม่ควรทำใน ClickHouse ตามคำแนะนำของนักพัฒนาจะทำที่นี่ และทำได้อย่างมีประสิทธิภาพ และทำงานได้ดีกว่าโซลูชันการทำธุรกรรมทั่วไปมาก
• ตัวอย่างที่สามคือการคำนวณแบบกระจายบน ClickHouse มีคำถามว่า ClickHouse สามารถรวมเข้ากับระบบนิเวศ Hadoop ได้อย่างไร ฉันจะแสดงตัวอย่างวิธีที่บริษัททำบางอย่างที่คล้ายกับแผนที่ลดคอนเทนเนอร์บน ClickHouse การติดตามการแปลข้อมูล ฯลฯ เพื่อคำนวณงานที่ไม่สำคัญมาก

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

บริษัท มีเส้นทางที่ยาวและเต็มไปด้วยหนาม และฉันได้พูดคุยเกี่ยวกับเรื่องนี้ใน HighLoad ประการแรก LifeStreet ย้ายจาก MySQL (โดยหยุดที่ Oracle) เป็น Vertica และคุณจะพบเรื่องราวเกี่ยวกับเรื่องนี้

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

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

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

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

และไม่มีอะไรที่จะรวมความดีที่อยู่ในฐานข้อมูลเชิงพาณิชย์กับของฟรีทั้งหมดที่อยู่ในโอเพ่นซอร์ส

ไม่มีอะไรเกิดขึ้นจนกระทั่ง Yandex ดึง ClickHouse ออกมาโดยไม่คาดคิดเหมือนนักมายากลจากหมวกเหมือนกระต่าย และเป็นการตัดสินใจที่คาดไม่ถึง พวกเขายังคงตั้งคำถามว่า “ทำไม” แต่อย่างไรก็ตาม

และทันทีในฤดูร้อนปี 2016 เราเริ่มดูว่า ClickHouse คืออะไร และปรากฎว่าบางครั้งอาจเร็วกว่า Vertica เราทดสอบสถานการณ์ต่างๆ ตามคำขอที่แตกต่างกัน และหากแบบสอบถามใช้เพียงตารางเดียว นั่นคือไม่มีการรวมใดๆ (รวม) ClickHouse ก็จะเร็วกว่า Vertica ถึงสองเท่า

ฉันไม่ขี้เกียจเกินไปและดูการทดสอบยานเดกซ์เมื่อวันก่อน เหมือนกันทุกประการ: ClickHouse เร็วกว่า Vertica สองเท่า ดังนั้นพวกเขาจึงมักพูดถึงเรื่องนี้

แต่หากมีการรวมในแบบสอบถามทุกอย่างจะไม่ชัดเจนมากนัก และ ClickHouse อาจช้าเป็นสองเท่าของ Vertica และถ้าคุณแก้ไขคำขอเล็กน้อยและเขียนใหม่ ก็จะมีค่าเท่ากันโดยประมาณ ไม่เลว. และฟรี

หลังจากได้รับผลการทดสอบและมองจากมุมต่างๆ แล้ว LifeStreet ก็ไปที่ ClickHouse

นี่เป็นปีที่ 16 ฉันเตือนคุณ มันเหมือนกับเรื่องตลกเกี่ยวกับหนูที่ร้องไห้และทิ่มแทงตัวเอง แต่ยังคงกินกระบองเพชรต่อไป และนี่คือคำอธิบายโดยละเอียดมีวิดีโอเกี่ยวกับเรื่องนี้ ฯลฯ

ดังนั้นฉันจะไม่พูดถึงรายละเอียดฉันจะพูดถึงผลลัพธ์และสิ่งที่น่าสนใจบางอย่างที่ฉันไม่ได้พูดถึง

ผลลัพธ์คือ:

• การโอนย้ายที่ประสบความสำเร็จและกว่าหนึ่งปีที่ระบบกำลังทำงานอยู่ในการผลิต
• ผลผลิตและความยืดหยุ่นเพิ่มขึ้น จากบันทึก 10 ล้านรายการที่เราสามารถจัดเก็บได้ต่อวันและช่วงเวลาสั้นๆ ปัจจุบัน LifeStreet สามารถจัดเก็บบันทึกได้ 75 ล้านรายการต่อวัน และสามารถทำได้เป็นเวลา 3 เดือนขึ้นไป หากคุณนับที่จุดสูงสุด มากถึงหนึ่งล้านเหตุการณ์ต่อวินาที แบบสอบถาม SQL มากกว่าล้านรายการต่อวันมาถึงระบบนี้ ส่วนใหญ่มาจากโรบ็อตที่แตกต่างกัน
• แม้ว่าจะมีการใช้เซิร์ฟเวอร์สำหรับ ClickHouse มากกว่า Vertica แต่พวกเขาก็ประหยัดฮาร์ดแวร์ด้วยเนื่องจาก Vertica ใช้ดิสก์ SAS ที่ค่อนข้างแพง ClickHouse ใช้ SATA และทำไม? เนื่องจากใน Vertica insert เป็นแบบซิงโครนัส และการซิงโครไนซ์ต้องการให้ดิสก์ไม่ช้าลงมากเกินไปและเครือข่ายต้องไม่ช้าลงมากเกินไป นั่นคือการดำเนินการที่ค่อนข้างแพง และในการแทรก ClickHouse เป็นแบบอะซิงโครนัส ยิ่งไปกว่านั้น คุณสามารถเขียนทุกอย่างในเครื่องได้ตลอดเวลา ไม่มีค่าใช้จ่ายเพิ่มเติม ดังนั้นข้อมูลจึงสามารถแทรกลงใน ClickHouse ได้เร็วกว่าใน Vertika มาก แม้จะเป็นไดรฟ์ที่ช้ากว่าก็ตาม และการอ่านเป็นเรื่องเดียวกัน การอ่านบน SATA หากอยู่ใน RAID ทั้งหมดนี้เร็วพอ
• ไม่จำกัดโดยใบอนุญาต เช่น ข้อมูล 3 เพตะไบต์ใน 60 เซิร์ฟเวอร์ (20 เซิร์ฟเวอร์เป็นแบบจำลองเดียว) และบันทึกข้อเท็จจริงและการรวมรวม 6 ล้านล้านรายการ ไม่มีอะไรแบบนี้ที่ Vertica ซื้อได้

ตอนนี้ฉันหันไปใช้สิ่งที่เป็นประโยชน์ในตัวอย่างนี้

• ประการแรกคือรูปแบบที่มีประสิทธิภาพ มากขึ้นอยู่กับสคีมา
• ประการที่สองคือการสร้าง SQL ที่มีประสิทธิภาพ

แบบสอบถาม OLAP ทั่วไปเป็นแบบเลือก บางคอลัมน์ไปที่การจัดกลุ่ม บางคอลัมน์ไปที่ฟังก์ชันการรวม มีที่ไหนที่สามารถแสดงเป็นชิ้นของลูกบาศก์ได้ ทั้งกลุ่มโดยสามารถคิดเป็นประมาณการ และนั่นเป็นสาเหตุที่เรียกว่าการวิเคราะห์ข้อมูลหลายตัวแปร

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

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

แต่มันทำงานได้ไม่ดีใน ClickHouse มีสองเหตุผล:

• ประการแรกคือเนื่องจาก ClickHouse มีการรวมที่ไม่ดีนัก เช่น มีการรวมเข้าด้วยกัน แต่ไม่ดี ในขณะที่แย่.
• ประการที่สองคือตารางไม่ได้รับการปรับปรุง โดยปกติแล้วในจานเหล่านี้ซึ่งอยู่รอบๆ วงจรดวงดาว จะต้องมีการเปลี่ยนแปลงบางอย่าง ตัวอย่างเช่น ชื่อลูกค้า ชื่อบริษัท เป็นต้น และมันไม่ได้ผล

และมีทางออกใน ClickHouse แม้แต่สอง:

• ประการแรกคือการใช้พจนานุกรม พจนานุกรมภายนอกคือสิ่งที่ช่วยแก้ปัญหาเกี่ยวกับ star-schema ได้ 99% พร้อมการอัปเดตและอื่นๆ
• ประการที่สองคือการใช้อาร์เรย์ อาร์เรย์ยังช่วยกำจัดการรวมและปัญหาเกี่ยวกับการทำให้เป็นมาตรฐาน

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

• คุณไม่จำเป็นต้องเข้าร่วมเช่นกัน
• นี่เป็นการแสดงแบบ 1-to-man แบบกะทัดรัด
• และในความคิดของฉัน Array นั้นสร้างมาเพื่อคนที่เกินบรรยาย เหล่านี้คือฟังก์ชันแลมบ์ดาและอื่นๆ

นี่ไม่ใช่สำหรับคำสีแดง นี่เป็นฟังก์ชันที่ทรงพลังมากซึ่งช่วยให้คุณทำสิ่งต่างๆ ได้มากมายด้วยวิธีที่เรียบง่ายและสวยงาม

ตัวอย่างทั่วไปที่ช่วยแก้ปัญหาอาร์เรย์ ตัวอย่างเหล่านี้ง่ายและชัดเจนเพียงพอ:

• ค้นหาตามแท็ก หากคุณมีแฮชแท็กและต้องการค้นหาโพสต์ด้วยแฮชแท็ก
• ค้นหาตามคู่คีย์-ค่า นอกจากนี้ยังมีคุณลักษณะบางอย่างที่มีค่า
• จัดเก็บรายการคีย์ที่คุณต้องการแปลเป็นอย่างอื่น

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

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

โครงสร้างที่ซ้อนกันอาจไม่ใช่ชื่อที่ดีที่สุด นี่คือสองอาร์เรย์ที่มีส่วนร่วมกันในชื่อและลักษณะที่เกี่ยวข้องกัน

และง่ายต่อการค้นหาด้วยแท็ก มีฟังก์ชั่น hasซึ่งตรวจสอบว่าอาร์เรย์มีองค์ประกอบ ทุกคน พบรายการทั้งหมดที่เกี่ยวข้องกับการประชุมของเรา

การค้นหาโดย subid นั้นซับซ้อนกว่าเล็กน้อย ก่อนอื่นเราต้องค้นหาดัชนีของคีย์จากนั้นใช้องค์ประกอบที่มีดัชนีนี้และตรวจสอบว่าค่านี้เป็นสิ่งที่เราต้องการ อย่างไรก็ตาม มันเรียบง่ายและกะทัดรัดมาก

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

ตัวอย่างอื่น. คุณมีอาร์เรย์ที่คุณเก็บ ID และคุณสามารถแปลเป็นชื่อได้ การทำงาน arrayMap. นี่เป็นฟังก์ชันแลมบ์ดาทั่วไป คุณส่งการแสดงออกของแลมบ์ดาที่นั่น และเธอก็ดึงค่าของชื่อสำหรับแต่ละรหัสออกจากพจนานุกรม

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

สิ่งเหล่านี้ทำให้วงจรง่ายขึ้นอย่างมากและแก้ปัญหาได้มากมาย

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

• ClickHouse ไม่มีเครื่องมือวางแผนการค้นหา ไม่ได้อย่างแน่นอน.
• อย่างไรก็ตาม การค้นหาที่ซับซ้อนยังคงต้องมีการวางแผน ในกรณีใดบ้าง?
• ถ้ามีการรวมหลายรายการในแบบสอบถาม คุณรวมไว้ในการเลือกย่อย และลำดับที่ดำเนินการก็มีความสำคัญ
• และประการที่สอง - หากมีการแจกจ่ายคำขอ เนื่องจากในแบบสอบถามแบบกระจาย เฉพาะส่วนย่อยด้านในสุดเท่านั้นที่จะดำเนินการแบบกระจาย และส่วนอื่นๆ ทั้งหมดจะถูกส่งผ่านไปยังเซิร์ฟเวอร์เดียวที่คุณเชื่อมต่อและดำเนินการที่นั่น ดังนั้น หากคุณได้กระจายการค้นหาด้วยการรวม (เข้าร่วม) จำนวนมาก คุณต้องเลือกลำดับ

และแม้แต่ในกรณีที่ง่ายกว่า บางครั้งก็จำเป็นต้องทำงานของตัวกำหนดตารางเวลาและเขียนคำขอใหม่เล็กน้อย

นี่คือตัวอย่าง ทางด้านซ้ายคือข้อความค้นหาที่แสดงประเทศ 5 อันดับแรก และใช้เวลา 2,5 วินาทีในความคิดของฉัน และทางด้านขวา ข้อความค้นหาเดียวกัน แต่เขียนใหม่เล็กน้อย แทนที่จะจัดกลุ่มตามสตริง เราเริ่มจัดกลุ่มตามคีย์ (int) และเร็วกว่า จากนั้นเราก็เชื่อมต่อพจนานุกรมกับผลลัพธ์ แทนที่จะใช้เวลา 2,5 วินาที คำขอใช้เวลา 1,5 วินาที ดีจัง.

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

มีเทคนิคมากมาย และช่วยให้คุณเร่งความเร็วการสืบค้นที่คุณคิดว่าทำงานเร็วอยู่แล้ว หรือในทางกลับกัน ทำงานช้าได้อย่างมาก สามารถทำได้เร็วยิ่งขึ้น

• การทำงานสูงสุดในโหมดกระจาย
• จัดเรียงตามประเภทขั้นต่ำ เช่นเดียวกับที่ฉันทำโดย ints
• หากมีการรวม (เข้าร่วม) พจนานุกรม จะเป็นการดีกว่าถ้าทำเป็นทางเลือกสุดท้าย เมื่อคุณมีข้อมูลอย่างน้อยจัดกลุ่มบางส่วนแล้ว การเข้าร่วมหรือการเรียกพจนานุกรมจะถูกเรียกใช้น้อยลงและจะเร็วขึ้น .
• การเปลี่ยนตัวกรอง

มีเทคนิคอื่น ๆ ไม่ใช่แค่เทคนิคที่ฉันได้แสดงให้เห็น และทั้งหมดนี้สามารถเพิ่มความเร็วในการดำเนินการค้นหาได้อย่างมากในบางครั้ง

มาดูตัวอย่างต่อไปกัน บริษัท X จากสหรัฐอเมริกา เธอกำลังทำอะไรอยู่?

มีงาน:

• การเชื่อมโยงธุรกรรมการโฆษณาแบบออฟไลน์
• การสร้างแบบจำลองการผูกแบบต่างๆ

สถานการณ์คืออะไร?

ผู้เข้าชมทั่วไปมาที่ไซต์ เช่น 20 ครั้งต่อเดือนจากโฆษณาต่างๆ หรือบางครั้งมาโดยไม่มีโฆษณาใดๆ เพราะเขาจำไซต์นี้ได้ ดูสินค้าบางอย่าง ใส่ตะกร้า หยิบออกจากตะกร้า และในที่สุดสิ่งที่ซื้อ

คำถามที่สมเหตุสมผล: "ใครควรจ่ายค่าโฆษณา หากจำเป็น" และ "โฆษณาใดที่มีอิทธิพลต่อเขา ถ้ามี" คือเขาซื้อทำไมและทำอย่างไรให้คนแบบนี้ซื้อด้วย

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

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

มีรูปแบบการผูกหลายแบบ

ความนิยมมากที่สุดคือ:

• การโต้ตอบสุดท้าย ซึ่งการโต้ตอบคือการคลิกหรือการแสดงผล
• การโต้ตอบครั้งแรก เช่น สิ่งแรกที่นำบุคคลมาที่ไซต์
• ชุดค่าผสมเชิงเส้น - ทั้งหมดเท่ากัน
• การลดทอน
• และอื่น ๆ

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

และหากโชคดีที่คำขอมี ID ธุรกรรม ก็เป็นเรื่องง่าย แต่มักจะไม่มีโชค ดังนั้นจึงจำเป็นต้องค้นหาธุรกรรมล่าสุดหรือธุรกรรมด้วยการคลิกสุดท้าย เป็นต้น

และทุกอย่างก็ทำงานได้ดีตราบเท่าที่การเชื่อมโยงไปถึงคลิกสุดท้าย เนื่องจากมีการคลิก 10 ล้านครั้งต่อวัน 300 ล้านต่อเดือนถ้าเรากำหนดกรอบเวลาหนึ่งเดือน และเนื่องจากใน Cassandra จะต้องมีหน่วยความจำทั้งหมดเพื่อให้ทำงานได้อย่างรวดเร็ว เนื่องจากรันไทม์ต้องตอบสนองอย่างรวดเร็ว จึงต้องใช้เซิร์ฟเวอร์ประมาณ 10-15 เครื่อง

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

และเราก็ไปที่ ClickHouse แล้วจะทำบน ClickHouse ได้อย่างไร? เมื่อมองแวบแรกดูเหมือนว่านี่เป็นชุดของรูปแบบการต่อต้าน

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

นั่นคือชุดของ antipatterns

แต่ถึงกระนั้นมันก็กลายเป็นระบบที่ทำงานได้ดีมาก

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

ในรูปแบบนี้มันทำงานได้ไม่ดีนัก และเพื่อให้ ClickHouse ง่ายขึ้น เมื่อมีคำขอตาม visit id พวกเขาจัดกลุ่มคำขอเหล่านี้เป็นบล็อกๆ ละ 1-000 visit id และดึงธุรกรรมทั้งหมดออกมาสำหรับ 2-000 คน แล้วทุกอย่างก็ใช้ได้

หากคุณดูภายใน ClickHouse จะมีเพียง 3 ตารางหลักที่ให้บริการทั้งหมดนี้

ตารางแรกที่อัปโหลดบันทึก และบันทึกถูกอัปโหลดโดยแทบไม่มีการประมวลผล

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

นี่คือข้อความที่เขียนใน SQL ฉันต้องการแสดงความคิดเห็นเกี่ยวกับสิ่งสำคัญบางประการในนั้น

สิ่งสำคัญอย่างแรกคือความสามารถในการดึงคอลัมน์และฟิลด์จาก json ใน ClickHouse นั่นคือ ClickHouse มีวิธีการบางอย่างสำหรับการทำงานกับ json พวกมันดั้งเดิมมาก

visitParamExtractInt ช่วยให้คุณแยกแอตทริบิวต์จาก json เช่น hit แรกใช้งานได้ และวิธีนี้ทำให้คุณสามารถดึง ID ธุรกรรมหรือ Visit ID ออกมาได้ เวลานี้.

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

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

สิ่งสำคัญประการที่สองคือ index_granularity หากคุณเคยเห็น MergeTree โดยปกติจะเป็น 8 ตามค่าเริ่มต้น index_granularity มันคืออะไร? นี่คือพารามิเตอร์ความกระจัดกระจายของดัชนี ใน ClickHouse ดัชนีนั้นเบาบาง มันไม่เคยสร้างดัชนีทุกรายการ มันทำสิ่งนี้ทุกๆ 192 และนี่เป็นสิ่งที่ดีเมื่อต้องคำนวณข้อมูลจำนวนมาก แต่ไม่ดีเมื่อเล็ก ๆ น้อย ๆ เนื่องจากมีค่าใช้จ่ายมาก และถ้าเราลดความละเอียดของดัชนี เราก็ลดค่าโสหุ้ย ไม่สามารถลดลงเหลือหนึ่งเพราะอาจมีหน่วยความจำไม่เพียงพอ ดัชนีจะถูกเก็บไว้ในหน่วยความจำเสมอ

Snapshot ยังใช้คุณสมบัติ ClickHouse ที่น่าสนใจอื่นๆ อีกด้วย

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

• การรวมเป็น "การแยก" จากรันไทม์
• มีการจัดเก็บและประมวลผลธุรกรรมมากถึง 3 พันล้านรายการต่อเดือน นี่เป็นลำดับความสำคัญมากกว่าใน Cassandra นั่นคือ ในระบบธุรกรรมทั่วไป
• คลัสเตอร์ของเซิร์ฟเวอร์ ClickHouse 2x5 5 เซิร์ฟเวอร์และแต่ละเซิร์ฟเวอร์มีแบบจำลอง นี่ยังน้อยกว่าใน Cassandra เพื่อที่จะทำการระบุแหล่งที่มาตามการคลิก และที่นี่เรามีการแสดงผล นั่นคือแทนที่จะเพิ่มจำนวนเซิร์ฟเวอร์ 30 เท่ากลับจัดการลดจำนวนเซิร์ฟเวอร์ลงได้

และตัวอย่างสุดท้ายคือบริษัทการเงิน Y ซึ่งวิเคราะห์ความสัมพันธ์ของการเปลี่ยนแปลงของราคาหุ้น

และงานคือ:

• มีประมาณ 5 หุ้น
• ทราบราคาทุกๆ 100 มิลลิวินาที
• ข้อมูลสะสมมากว่า 10 ปี เห็นได้ชัดว่าสำหรับบางบริษัทมากกว่าสำหรับบางบริษัทน้อยกว่า
• มีทั้งหมดประมาณ 100 พันล้านแถว

และจำเป็นต้องคำนวณความสัมพันธ์ของการเปลี่ยนแปลง

นี่คือหุ้นสองตัวและราคาของพวกเขา ถ้าตัวหนึ่งขึ้นและอีกตัวหนึ่งขึ้น แสดงว่ามีความสัมพันธ์เชิงบวก นั่นคือ ตัวหนึ่งขึ้นและอีกตัวหนึ่งขึ้น ถ้ากราฟหนึ่งพุ่งขึ้นเหมือนที่ปลายกราฟ และอีกอันพุ่งลง แสดงว่ามีความสัมพันธ์เชิงลบ กล่าวคือ เมื่อตัวหนึ่งพุ่งขึ้น อีกตัวหนึ่งร่วงลง

การวิเคราะห์การเปลี่ยนแปลงร่วมกันเหล่านี้ เราสามารถคาดการณ์ในตลาดการเงินได้

แต่งานนั้นยาก กำลังทำสิ่งนี้เพื่ออะไร เรามีบันทึก 100 พันล้านรายการที่มีเวลา หุ้น และราคา เราต้องคำนวณ 100 พันล้านเท่าของ rundifference จากอัลกอริทึมราคาก่อน RunningDifference เป็นฟังก์ชันใน ClickHouse ที่คำนวณความแตกต่างระหว่างสองสตริงตามลำดับ

และหลังจากนั้น คุณต้องคำนวณความสัมพันธ์ และต้องคำนวณความสัมพันธ์สำหรับแต่ละคู่ สำหรับ 5 หุ้น คู่คือ 000 ล้าน และนี่คือจำนวนมากเช่น 12,5 เท่าจำเป็นต้องคำนวณฟังก์ชันสหสัมพันธ์ดังกล่าว

และถ้ามีคนลืม ͞x และ ͞y ก็คือรุกฆาต ความคาดหวังในการสุ่มตัวอย่าง นั่นคือไม่เพียง แต่จำเป็นต้องคำนวณรากและผลรวมเท่านั้น แต่ยังต้องคำนวณผลรวมเพิ่มเติมอีกหนึ่งผลรวมภายในผลรวมเหล่านี้ด้วย การคำนวณจำนวนมากจำเป็นต้องทำ 12,5 ล้านครั้งและจัดกลุ่มเป็นชั่วโมง เรายังมีชั่วโมงอีกมาก และคุณต้องทำภายใน 60 วินาที มันเป็นเรื่องตลก

อย่างน้อยก็จำเป็นต้องมีเวลา เพราะทั้งหมดนี้ทำงานช้ามากก่อนที่ ClickHouse จะมาถึง

พวกเขาพยายามคำนวณบน Hadoop บน Spark บน Greenplum และทั้งหมดนี้ช้าหรือแพงมาก นั่นคือมันเป็นไปได้ที่จะคำนวณอย่างใด แต่ก็มีราคาแพง

จากนั้น ClickHouse ก็เข้ามาและทุกอย่างก็ดีขึ้นมาก

ฉันเตือนคุณว่าเรามีปัญหากับ data localized เนื่องจากไม่สามารถแปลความสัมพันธ์ได้ เราไม่สามารถใส่ข้อมูลบางส่วนในเซิร์ฟเวอร์หนึ่ง บางส่วนในเซิร์ฟเวอร์อื่น และคำนวณ เราต้องมีข้อมูลทั้งหมดทุกที่

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

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

หลังจากนั้นสามารถทำซ้ำได้ ตัวอักษร "r" หมายถึงเราได้จำลองข้อมูลนี้ นั่นคือเรามีข้อมูลเดียวกันในเซิร์ฟเวอร์ทั้งสาม - นี่คืออาร์เรย์

จากนั้นด้วยสคริปต์พิเศษจากชุดความสัมพันธ์ 12,5 ล้านชุดที่ต้องคำนวณ คุณสามารถสร้างแพ็คเกจได้ นั่นคือ 2 งานที่มีความสัมพันธ์ 500 คู่ และงานนี้จะต้องคำนวณบนเซิร์ฟเวอร์ ClickHouse เฉพาะ เขามีข้อมูลทั้งหมดเพราะข้อมูลนั้นเหมือนกันและเขาสามารถคำนวณตามลำดับได้

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

ในการพิสูจน์แนวคิด งานเป็นงานย่อย กล่าวคือ ใช้ข้อมูลน้อยลง และมีเพียงสามเซิร์ฟเวอร์เท่านั้น

สองขั้นตอนแรกนี้: การคำนวณ Log_return และการรวมอาร์เรย์ใช้เวลาประมาณหนึ่งชั่วโมง

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

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

• โครงการที่ถูกต้องมีชัยไปกว่าครึ่ง และรูปแบบที่เหมาะสมคือการใช้เทคโนโลยี ClickHouse ที่จำเป็นทั้งหมด
• Summing/AggregatingMergeTrees เป็นเทคโนโลยีที่อนุญาตให้คุณรวมหรือพิจารณาสแน็ปช็อตสถานะเป็นกรณีพิเศษ และทำให้หลายๆ อย่างง่ายขึ้นมาก
• Materialized Views ช่วยให้คุณข้ามขีดจำกัดหนึ่งดัชนีได้ บางทีฉันอาจพูดไม่ชัดเจน แต่เมื่อเราโหลดบันทึก บันทึกดิบอยู่ในตารางที่มีดัชนีเดียว และบันทึกแอตทริบิวต์อยู่ในตาราง เช่น ข้อมูลเดียวกัน กรองเท่านั้น แต่ดัชนีสมบูรณ์ คนอื่น. ดูเหมือนว่าจะเป็นข้อมูลเดียวกัน แต่การเรียงลำดับต่างกัน และ Materialized Views ช่วยให้คุณสามารถข้ามข้อจำกัดของ ClickHouse ดังกล่าวได้ หากคุณต้องการ
• ลดความละเอียดของดัชนีสำหรับการค้นหาจุด
• และกระจายข้อมูลอย่างชาญฉลาด พยายามแปลข้อมูลภายในเซิร์ฟเวอร์ให้มากที่สุด และพยายามตรวจสอบให้แน่ใจว่าคำขอใช้การแปลเป็นภาษาท้องถิ่นให้มากที่สุดเท่าที่จะทำได้

และเมื่อสรุปสุนทรพจน์สั้น ๆ นี้ เราสามารถพูดได้ว่า ClickHouse ได้ครอบครองอาณาเขตของทั้งฐานข้อมูลเชิงพาณิชย์และฐานข้อมูลโอเพ่นซอร์สอย่างแน่นหนา กล่าวคือ สำหรับการวิเคราะห์โดยเฉพาะ เขาเข้ากันได้ดีกับภูมิทัศน์นี้ และยิ่งไปกว่านั้น มันจะค่อยๆ เบียดคนอื่นๆ เพราะเมื่อคุณมี ClickHouse คุณไม่จำเป็นต้องใช้ InfiniDB อาจไม่ต้องการ Vertika ในเร็วๆ นี้หากพวกเขารองรับ SQL ปกติ สนุก!

-ขอบคุณสำหรับรายงาน! น่าสนใจมาก! มีการเปรียบเทียบกับ Apache Phoenix หรือไม่

ไม่ ฉันไม่เคยได้ยินใครเปรียบเทียบ เราและยานเดกซ์พยายามติดตามการเปรียบเทียบ ClickHouse ทั้งหมดกับฐานข้อมูลต่างๆ เพราะหากจู่ๆ มีบางสิ่งที่เร็วกว่า ClickHouse ดังนั้น Lesha Milovidov ก็จะนอนไม่หลับในตอนกลางคืนและเริ่มเร่งความเร็วอย่างรวดเร็ว ฉันไม่เคยได้ยินเรื่องการเปรียบเทียบดังกล่าว

• (Aleksey Milovidov) Apache Phoenix เป็นเครื่องมือ SQL ที่ขับเคลื่อนโดย Hbase Hbase เป็นส่วนใหญ่สำหรับสถานการณ์การทำงานคีย์-ค่า ในแต่ละบรรทัดอาจมีจำนวนคอลัมน์ที่มีชื่อตามอำเภอใจ อาจกล่าวได้เกี่ยวกับระบบเช่น Hbase, Cassandra และเป็นคำถามเชิงวิเคราะห์ที่หนักหน่วงซึ่งใช้งานไม่ได้ตามปกติสำหรับคำถามเหล่านี้ หรือคุณอาจคิดว่าใช้งานได้ดีหากคุณไม่มีประสบการณ์ใดๆ กับ ClickHouse

• ขอบคุณ

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

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

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

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

ก็เป็นที่ชัดเจน. คุณบอกว่ามีการประมวลผล 50 ชั่วโมง เป็นตั้งแต่เริ่มต้นโหลดข้อมูลหรือได้รับผลลัพธ์ตั้งแต่เมื่อไหร่?

ใช่ ๆ.

โอเคขอบคุณมาก.

นี่คือคลัสเตอร์ 3 เซิร์ฟเวอร์

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

แน่นอนว่าไม่มีระบบใดในอุดมคติ และ ClickHouse ก็มีปัญหาของตัวเองเช่นกัน แต่คุณเคยได้ยินเกี่ยวกับ Yandex.Metrica ที่ไม่ทำงานเป็นเวลานานหรือไม่? อาจจะไม่. มันทำงานได้อย่างน่าเชื่อถือตั้งแต่ปี 2012-2013 บน ClickHouse ฉันสามารถพูดแบบเดียวกันเกี่ยวกับประสบการณ์ของฉัน เราไม่เคยล้มเหลวโดยสิ้นเชิง บางอย่างอาจเกิดขึ้นได้ แต่ไม่เคยสำคัญพอที่จะส่งผลกระทบต่อธุรกิจอย่างจริงจัง มันไม่เคยเกิดขึ้น ClickHouse ค่อนข้างเชื่อถือได้และไม่ผิดพลาดแบบสุ่ม คุณไม่ต้องกังวลเกี่ยวกับมัน มันไม่ใช่ของดิบ สิ่งนี้ได้รับการพิสูจน์แล้วจากหลายบริษัท

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

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

ขอบคุณ

ที่มา: will.com