เนื่องจาก ClickHouse เป็นระบบพิเศษ เมื่อใช้งานจึงจำเป็นต้องคำนึงถึงคุณสมบัติของสถาปัตยกรรมด้วย ในรายงานนี้ Alexey จะพูดถึงตัวอย่างข้อผิดพลาดทั่วไปเมื่อใช้ ClickHouse ซึ่งอาจนำไปสู่การทำงานที่ไม่มีประสิทธิภาพ ตัวอย่างที่เป็นประโยชน์จะแสดงให้เห็นว่าการเลือกรูปแบบการประมวลผลข้อมูลอย่างใดอย่างหนึ่งสามารถเปลี่ยนประสิทธิภาพตามลำดับความสำคัญได้อย่างไร
สวัสดีทุกคน! ฉันชื่อ Alexey ฉันสร้าง ClickHouse
ก่อนอื่นผมรีบเอาใจคุณทันที วันนี้ผมจะไม่บอกคุณว่า ClickHouse คืออะไร พูดตามตรงฉันเหนื่อยกับมันแล้ว ทุกครั้งที่ผมบอกคุณว่ามันคืออะไร และทุกคนคงรู้อยู่แล้ว
แต่ฉันจะบอกคุณถึงข้อผิดพลาดที่อาจเกิดขึ้นได้ นั่นคือ คุณจะใช้ ClickHouse ไม่ถูกต้องได้อย่างไร ความจริงแล้วไม่จำเป็นต้องกลัว เพราะเรากำลังพัฒนา ClickHouse ให้เป็นระบบที่เรียบง่าย สะดวก และทำงานนอกกรอบ ฉันติดตั้งแล้ว ไม่มีปัญหา
แต่คุณยังต้องคำนึงว่าระบบนี้มีความเชี่ยวชาญและคุณสามารถเจอกรณีการใช้งานที่ผิดปกติซึ่งจะทำให้ระบบนี้ออกจากเขตความสะดวกสบายได้อย่างง่ายดาย
แล้วมีคราดแบบไหนล่ะ? ส่วนใหญ่ฉันจะพูดถึงสิ่งที่ชัดเจน ทุกคนชัดเจน ทุกคนเข้าใจทุกอย่างและสามารถดีใจที่พวกเขาฉลาดมาก และคนที่ไม่เข้าใจจะได้เรียนรู้สิ่งใหม่
ตัวอย่างแรกและง่ายที่สุด ซึ่งน่าเสียดายที่มักเกิดขึ้นคือ เม็ดมีดจำนวนมากที่มีจำนวนน้อย เช่น เม็ดมีดขนาดเล็กจำนวนมาก
หากเราพิจารณาว่า ClickHouse ดำเนินการแทรกอย่างไร คุณสามารถส่งข้อมูลได้อย่างน้อยหนึ่งเทราไบต์ในคำขอเดียว มันไม่ใช่ปัญหา
และมาดูกันว่าประสิทธิภาพโดยทั่วไปจะเป็นอย่างไร ตัวอย่างเช่น เรามีตารางจากข้อมูล Yandex.Metrica ฮิต 105 บางคอลัมน์ 700 ไบต์ไม่มีการบีบอัด และเราจะแทรกในทางที่ดีเป็นชุดหนึ่งล้านแถว
เราแทรก MergeTree ลงในตารางปรากฎว่าครึ่งล้านแถวต่อวินาที ยอดเยี่ยม. ในตารางที่จำลองข้อมูลจะมีขนาดเล็กกว่าเล็กน้อย ประมาณ 400 แถวต่อวินาที
และถ้าคุณเปิดใช้งานการแทรกองค์ประชุม คุณจะได้รับประสิทธิภาพน้อยลงเล็กน้อย แต่ยังคงประสิทธิภาพที่ดี 250 เทอมต่อวินาที การแทรกองค์ประชุมเป็นคุณลักษณะที่ไม่มีเอกสารใน ClickHouse*
* ณ ปี 2020 .
จะเกิดอะไรขึ้นถ้าคุณทำสิ่งที่ไม่ดี? เราแทรกหนึ่งแถวลงในตาราง MergeTree และรับ 59 แถวต่อวินาที มันช้ากว่า 10 เท่า ใน ReplicatedMergeTree – 000 แถวต่อวินาที และถ้าเปิดองค์ประชุมก็จะกลายเป็น 6 บรรทัดต่อวินาที ในความคิดของฉัน นี่เป็นเรื่องไร้สาระอย่างแน่นอน คุณจะชะลอตัวลงเช่นนั้นได้อย่างไร? ฉันยังเขียนไว้บนเสื้อยืดว่า ClickHouse ไม่ควรช้าลง แต่ถึงกระนั้นมันก็เกิดขึ้นบางครั้ง
อันที่จริงนี่คือข้อบกพร่องของเรา เราสามารถทำให้ทุกอย่างทำงานได้ดีได้อย่างง่ายดาย แต่เราไม่ได้ทำ และเราไม่ได้ทำเพราะสคริปต์ของเราไม่ต้องการมัน เรามีเนื้อแล้ว เราเพิ่งได้รับแบทช์ที่ทางเข้าของเรา และไม่มีปัญหาใดๆ เราใส่มันและทุกอย่างทำงานได้ดี แต่แน่นอนว่าสถานการณ์ทุกประเภทก็เป็นไปได้ ตัวอย่างเช่น เมื่อคุณมีเซิร์ฟเวอร์จำนวนมากที่ใช้สร้างข้อมูล และไม่ได้แทรกข้อมูลบ่อยนัก แต่ก็ยังลงเอยด้วยการแทรกบ่อยครั้ง และเราต้องหลีกเลี่ยงสิ่งนี้
จากมุมมองทางเทคนิค ประเด็นก็คือเมื่อคุณทำการแทรกใน ClickHouse ข้อมูลจะไม่จบลงที่ Memtable ใดๆ เราไม่มีโครงสร้างบันทึกจริง MergeTree แต่เป็นเพียง MergeTree เนื่องจากไม่มีทั้งบันทึกหรือ memTable เราเพียงแค่เขียนข้อมูลลงในระบบไฟล์ทันทีโดยจัดเรียงเป็นคอลัมน์แล้ว และถ้าคุณมี 100 คอลัมน์ จะต้องเขียนไฟล์มากกว่า 200 ไฟล์ลงในไดเร็กทอรีแยกต่างหาก ทั้งหมดนี้ยุ่งยากมาก
และคำถามก็เกิดขึ้น:“ จะทำอย่างไรให้ถูกต้อง” หากสถานการณ์เป็นเช่นนั้นคุณยังคงต้องบันทึกข้อมูลใน ClickHouse
วิธีที่ 1 นี่เป็นวิธีที่ง่ายที่สุด ใช้คิวแบบกระจายบางประเภท ตัวอย่างเช่น คาฟคา คุณเพียงแค่ดึงข้อมูลจาก Kafka และแบทช์ข้อมูลนั้นวินาทีละครั้ง และทุกอย่างจะเรียบร้อย คุณบันทึก ทุกอย่างทำงานได้ดี
ข้อเสียคือ Kafka เป็นระบบกระจายข้อมูลขนาดใหญ่อีกระบบหนึ่ง ฉันเข้าใจด้วยว่าคุณมี Kafka ในบริษัทอยู่แล้ว ก็ดีมันสะดวก แต่ถ้าไม่มีอยู่ คุณควรคิดสามครั้งก่อนที่จะลากระบบแบบกระจายอื่นเข้ามาในโปรเจ็กต์ของคุณ ดังนั้นจึงควรพิจารณาทางเลือกอื่น
วิธีที่ 2 นี่เป็นทางเลือกแบบเก่าและในขณะเดียวกันก็ง่ายมาก คุณมีเซิร์ฟเวอร์บางประเภทที่สร้างบันทึกของคุณหรือไม่ และมันแค่เขียนบันทึกของคุณลงในไฟล์ และวินาทีละครั้งเช่นเราเปลี่ยนชื่อไฟล์นี้และฉีกไฟล์ใหม่ และสคริปต์แยก ไม่ว่าจะผ่านทาง cron หรือ daemon บางตัว จะนำไฟล์ที่เก่าที่สุดมาเขียนลงใน ClickHouse หากคุณบันทึกบันทึกต่อวินาที ทุกอย่างจะเรียบร้อยดี
แต่ข้อเสียของวิธีนี้คือหากเซิร์ฟเวอร์ของคุณที่สร้างบันทึกหายไปที่ไหนสักแห่ง ข้อมูลก็จะหายไปเช่นกัน
วิธีที่ 3 มีอีกวิธีที่น่าสนใจซึ่งไม่ต้องใช้ไฟล์ชั่วคราวเลย ตัวอย่างเช่น คุณมีตัวหมุนโฆษณาหรือดีมอนที่น่าสนใจอื่นๆ ที่สร้างข้อมูล และคุณสามารถสะสมข้อมูลจำนวนมากได้โดยตรงใน RAM ในบัฟเฟอร์ และเมื่อเวลาผ่านไปมากพอ ให้คุณวางบัฟเฟอร์นี้ไว้ข้างๆ สร้างบัฟเฟอร์ใหม่ และแทรกสิ่งที่สะสมไว้แล้วลงใน ClickHouse ในเธรดที่แยกจากกัน
ในทางกลับกัน ข้อมูลก็หายไปพร้อมกับ kill -9 หากเซิร์ฟเวอร์ของคุณล่ม คุณจะสูญเสียข้อมูลนี้ และปัญหาอีกประการหนึ่งคือหากคุณไม่สามารถเขียนลงฐานข้อมูลได้ ข้อมูลของคุณจะสะสมอยู่ใน RAM และ RAM จะหมดหรือคุณก็จะสูญเสียข้อมูล
วิธีที่ 4. อีกวิธีที่น่าสนใจ คุณมีกระบวนการเซิร์ฟเวอร์บางประเภทหรือไม่ และสามารถส่งข้อมูลไปที่ ClickHouse ได้ทันที แต่ทำได้ในการเชื่อมต่อเดียว ตัวอย่างเช่น ฉันส่งคำขอ http พร้อมการเข้ารหัสการถ่ายโอน: chunked พร้อมส่วนแทรก และจะสร้างชิ้นส่วนได้ไม่บ่อยนัก คุณสามารถส่งแต่ละบรรทัดได้ แม้ว่าจะมีค่าใช้จ่ายในการจัดเฟรมข้อมูลนี้ก็ตาม
อย่างไรก็ตามในกรณีนี้ข้อมูลจะถูกส่งไปยัง ClickHouse ทันที และ ClickHouse จะบัฟเฟอร์พวกมันเอง
แต่ปัญหาก็เกิดขึ้นเช่นกัน ตอนนี้คุณจะสูญเสียข้อมูล รวมถึงเวลาที่กระบวนการของคุณถูกหยุดทำงาน และหากกระบวนการ ClickHouse ถูกฆ่า เนื่องจากจะเป็นการแทรกที่ไม่สมบูรณ์ และในส่วนแทรกของ ClickHouse จะเป็นแบบอะตอมมิกจนถึงเกณฑ์ที่กำหนดในขนาดของแถว โดยหลักการแล้วนี่เป็นวิธีที่น่าสนใจ ยังสามารถใช้ได้.
วิธีที่ 5 นี่เป็นอีกวิธีที่น่าสนใจ นี่คือเซิร์ฟเวอร์บางประเภทที่พัฒนาโดยชุมชนสำหรับการแบทช์ข้อมูล ฉันไม่ได้ดูด้วยตัวเองดังนั้นฉันจึงไม่สามารถรับประกันอะไรได้ อย่างไรก็ตาม ไม่มีการรับประกันสำหรับ ClickHouse เอง นี่เป็นโอเพ่นซอร์สเช่นกัน แต่ในทางกลับกัน คุณอาจคุ้นเคยกับมาตรฐานคุณภาพบางอย่างที่เราพยายามให้ได้ แต่สำหรับสิ่งนี้ - ฉันไม่รู้ ไปที่ GitHub ดูโค้ด บางทีพวกเขาอาจจะเขียนอะไรบางอย่างตามปกติ
* ณ ปี 2020 ควรเพิ่มการพิจารณาด้วย .
วิธีที่ 6 อีกวิธีหนึ่งคือการใช้ตารางบัฟเฟอร์ ข้อดีของวิธีนี้คือเริ่มใช้งานได้ง่ายมาก สร้างตารางบัฟเฟอร์แล้วแทรกลงในตาราง
ข้อเสียคือปัญหายังไม่ได้รับการแก้ไขอย่างสมบูรณ์ หากในอัตราเช่น MergeTree คุณต้องจัดกลุ่มข้อมูลตามหนึ่งชุดต่อวินาที จากนั้นในอัตราในตารางบัฟเฟอร์ คุณจะต้องจัดกลุ่มอย่างน้อยหลายพันต่อวินาที ถ้าเกิน 10 ต่อวินาทีก็ยังแย่อยู่ และถ้าคุณใส่มันเป็นกลุ่ม ๆ คุณจะเห็นว่ามันเป็นหนึ่งแสนบรรทัดต่อวินาที และนี่เป็นข้อมูลที่ค่อนข้างหนักอยู่แล้ว
และตารางบัฟเฟอร์ก็ไม่มีบันทึก และหากมีสิ่งผิดปกติเกิดขึ้นกับเซิร์ฟเวอร์ของคุณ ข้อมูลก็จะหายไป
และเพื่อเป็นโบนัส เมื่อเร็วๆ นี้เราได้รับโอกาสที่ ClickHouse เพื่อดึงข้อมูลจาก Kafka มีเครื่องตั้งโต๊ะ-คาฟคา คุณเพียงแค่สร้าง และคุณสามารถแขวนการนำเสนอที่เป็นรูปธรรมไว้บนนั้นได้ ในกรณีนี้มันจะดึงข้อมูลจาก Kafka เองแล้วแทรกลงในตารางที่คุณต้องการ
และสิ่งที่น่ายินดีเป็นพิเศษเกี่ยวกับโอกาสนี้คือไม่ใช่เราที่เป็นคนทำ นี่คือคุณลักษณะของชุมชน และเมื่อฉันพูดว่า "คุณลักษณะของชุมชน" ฉันหมายถึงมันโดยไม่มีการดูถูกใดๆ เราอ่านโค้ด ตรวจทาน มันควรจะทำงานได้ดี
* ในปี 2020 มีการสนับสนุนที่คล้ายกันเกิดขึ้น .
มีอะไรอีกที่อาจไม่สะดวกหรือไม่คาดคิดเมื่อแทรกข้อมูล? หากคุณทำการร้องขอค่าแทรกและเขียนนิพจน์ที่คำนวณได้บางส่วนเป็นค่า ตัวอย่างเช่น now() ก็เป็นนิพจน์จากการคำนวณเช่นกัน และในกรณีนี้ ClickHouse ถูกบังคับให้เปิดล่ามสำนวนเหล่านี้ในแต่ละบรรทัด และประสิทธิภาพจะลดลงตามลำดับความสำคัญ หลีกเลี่ยงสิ่งนี้จะดีกว่า
* ในขณะนี้ ปัญหาได้รับการแก้ไขอย่างสมบูรณ์แล้ว ไม่มีการถดถอยของประสิทธิภาพอีกต่อไปเมื่อใช้นิพจน์ใน VALUES
อีกตัวอย่างหนึ่งคือ เมื่ออาจเกิดปัญหาเมื่อคุณมีข้อมูลในชุดเดียวที่เป็นของพาร์ติชันจำนวนมาก ตามค่าเริ่มต้น พาร์ติชัน ClickHouse จะเป็นตามเดือน และถ้าคุณแทรกชุดหนึ่งล้านแถวและมีข้อมูลเป็นเวลาหลายปี คุณจะมีพาร์ติชันหลายโหลอยู่ที่นั่น และนี่เทียบเท่ากับความจริงที่ว่าจะมีแบทช์ที่มีขนาดเล็กกว่าหลายสิบเท่าเพราะภายในจะถูกแบ่งออกเป็นพาร์ติชั่นก่อนเสมอ
* เมื่อเร็ว ๆ นี้ ในโหมดทดลอง ClickHouse ได้เพิ่มการรองรับรูปแบบขนาดกะทัดรัดของชิ้นส่วนและชิ้นส่วนใน RAM พร้อมบันทึกการเขียนล่วงหน้า ซึ่งแก้ปัญหาได้เกือบทั้งหมด
ตอนนี้เรามาดูปัญหาประเภทที่สอง - การพิมพ์ข้อมูล
การพิมพ์ข้อมูลอาจเป็นแบบเข้มงวดหรือแบบสตริงก็ได้ สตริงคือเมื่อคุณเพิ่งรับมันและประกาศว่าฟิลด์ทั้งหมดของคุณเป็นประเภทสตริง นี่มันแย่มาก ไม่จำเป็นต้องทำเช่นนี้
เรามาดูวิธีการทำอย่างถูกต้องในกรณีเหล่านั้นเมื่อคุณต้องการบอกว่าเรามีฟิลด์ สตริง และปล่อยให้ ClickHouse คิดออกเอง และฉันจะไม่รบกวน แต่ก็ยังคุ้มค่าที่จะพยายาม
ตัวอย่างเช่น เรามีที่อยู่ IP ในกรณีหนึ่ง เราได้บันทึกเป็นสตริง เช่น 192.168.1.1 และในอีกกรณีหนึ่ง มันจะเป็นตัวเลขประเภท UInt32* 32 บิตก็เพียงพอแล้วสำหรับที่อยู่ IPv4
ประการแรก น่าแปลกที่ข้อมูลจะถูกบีบอัดเท่าๆ กันโดยประมาณ แน่นอนว่าจะมีความแตกต่าง แต่ก็ไม่มากขนาดนั้น ดังนั้นจึงไม่มีปัญหาพิเศษกับดิสก์ I/O
แต่มีความแตกต่างอย่างมากในเวลาประมวลผลและเวลาดำเนินการแบบสอบถาม
มานับจำนวนที่อยู่ IP ที่ไม่ซ้ำกันหากจัดเก็บเป็นตัวเลข ซึ่งทำงานได้ถึง 137 ล้านบรรทัดต่อวินาที หากสิ่งเดียวกันอยู่ในรูปแบบของสตริง ก็เท่ากับ 37 ล้านบรรทัดต่อวินาที ฉันไม่รู้ว่าทำไมเรื่องบังเอิญนี้จึงเกิดขึ้น ฉันดำเนินการตามคำขอเหล่านี้ด้วยตัวเอง แต่ยังช้ากว่าประมาณ 4 เท่า
และถ้าคุณคำนวณความแตกต่างในพื้นที่ดิสก์ก็มีความแตกต่างเช่นกัน และความแตกต่างคือประมาณหนึ่งในสี่ เนื่องจากมีที่อยู่ IP ที่ไม่ซ้ำกันค่อนข้างมาก และถ้ามีบรรทัดที่มีความหมายต่างกันเพียงเล็กน้อยก็จะถูกบีบอัดตามพจนานุกรมให้เหลือปริมาตรเท่ากันได้อย่างง่ายดาย
และความแตกต่างของเวลาสี่เท่าไม่ได้อยู่บนท้องถนน บางทีคุณอาจไม่ใส่ใจ แต่เมื่อฉันเห็นความแตกต่างเช่นนั้น มันทำให้ฉันเศร้า
ลองดูกรณีต่างๆ
1. กรณีหนึ่งเมื่อคุณมีค่าเฉพาะที่แตกต่างกันเล็กน้อย ในกรณีนี้ เราใช้แนวทางปฏิบัติง่ายๆ ที่คุณอาจรู้จักและสามารถใช้กับ DBMS ใดๆ ได้ ทั้งหมดนี้สมเหตุสมผลไม่เพียงแต่สำหรับ ClickHouse เท่านั้น เพียงเขียนตัวระบุตัวเลขลงในฐานข้อมูล และคุณสามารถแปลงเป็นสตริงและย้อนกลับที่ด้านข้างของแอปพลิเคชันของคุณได้
ตัวอย่างเช่น คุณมีภูมิภาค และคุณกำลังพยายามบันทึกเป็นสตริง และจะเขียนไว้ที่นั่น: ภูมิภาคมอสโกและมอสโก และเมื่อฉันเห็นว่ามันเขียนว่า "มอสโก" ก็ไม่มีอะไร แต่เมื่อเป็นมอสโก มันกลับกลายเป็นเรื่องเศร้าอย่างยิ่ง นี่คือจำนวนไบต์
แต่เราเพียงจดหมายเลข Ulnt32 และ 250 แทน เรามี 250 ในยานเดกซ์ แต่ของคุณอาจแตกต่างกัน ในกรณีนี้ ฉันจะบอกว่า ClickHouse มีความสามารถในตัวในการทำงานกับฐานภูมิศาสตร์ คุณเพียงแค่เขียนไดเร็กทอรีพร้อมภูมิภาครวมถึงไดเร็กทอรีแบบลำดับชั้นเช่น จะมีมอสโก ภูมิภาคมอสโก และทุกสิ่งที่คุณต้องการ และคุณสามารถแปลงในระดับคำขอได้
ตัวเลือกที่สองจะใกล้เคียงกัน แต่รองรับภายใน ClickHouse นี่คือชนิดข้อมูล Enum คุณเพียงแค่เขียนค่าทั้งหมดที่คุณต้องการภายใน Enum ตัวอย่างเช่น ประเภทของอุปกรณ์และเขียนไว้ที่นั่น: เดสก์ท็อป มือถือ แท็บเล็ต ทีวี มีทั้งหมด 4 ตัวเลือก
ข้อเสียคือต้องเปลี่ยนเป็นระยะๆ มีเพียงตัวเลือกเดียวเท่านั้นที่เพิ่มเข้ามา มาปรับเปลี่ยนตารางกันเถอะ ที่จริงแล้ว การแก้ไขตารางใน ClickHouse นั้นฟรี ฟรีเป็นพิเศษสำหรับ Enum เนื่องจากข้อมูลบนดิสก์ไม่เปลี่ยนแปลง แต่อย่างไรก็ตาม การเปลี่ยนแปลงจะได้รับการล็อค* บนโต๊ะ และต้องรอจนกว่าการเลือกทั้งหมดจะถูกดำเนินการ และหลังจากการเปลี่ยนแปลงนี้จะดำเนินการเท่านั้น กล่าวคือ ยังมีความไม่สะดวกอยู่บ้าง
* ใน ClickHouse เวอร์ชันล่าสุด ALTER นั้นไม่มีการปิดกั้นโดยสมบูรณ์
อีกทางเลือกหนึ่งที่ค่อนข้างพิเศษสำหรับ ClickHouse คือการเชื่อมต่อพจนานุกรมภายนอก คุณสามารถเขียนตัวเลขใน ClickHouse และเก็บไดเร็กทอรีของคุณไว้ในระบบใดก็ได้ที่สะดวกสำหรับคุณ ตัวอย่างเช่น คุณสามารถใช้: MySQL, Mongo, Postgres คุณสามารถสร้างไมโครเซอร์วิสของคุณเองซึ่งจะส่งข้อมูลนี้ผ่าน http และที่ระดับ ClickHouse คุณจะเขียนฟังก์ชันที่จะแปลงข้อมูลนี้จากตัวเลขเป็นสตริง
นี่เป็นวิธีพิเศษแต่มีประสิทธิภาพมากในการดำเนินการรวมบนโต๊ะภายนอก และมีสองทางเลือก ในรูปลักษณ์หนึ่ง ข้อมูลนี้จะถูกแคชโดยสมบูรณ์ มีอยู่ใน RAM อย่างสมบูรณ์ และอัปเดตด้วยความถี่บางอย่าง และในอีกทางเลือกหนึ่งหากข้อมูลนี้ไม่พอดีกับ RAM คุณสามารถแคชได้บางส่วน
นี่คือตัวอย่าง มี Yandex.Direct และมีบริษัทโฆษณาและแบนเนอร์ อาจมีบริษัทโฆษณาประมาณหลายสิบล้านบริษัท และพวกมันก็พอดีกับ RAM โดยประมาณ และมีแบนเนอร์นับพันล้านแบนเนอร์ที่ไม่พอดี และเราใช้พจนานุกรมที่แคชไว้จาก MySQL
ปัญหาเดียวคือพจนานุกรมที่แคชไว้จะทำงานได้ดีหากอัตราการเข้าชมใกล้กับ 100% หากมีขนาดเล็กกว่า เมื่อประมวลผลคำค้นหาสำหรับข้อมูลแต่ละชุด คุณจะต้องนำคีย์ที่หายไปไปรับข้อมูลจาก MySQL เกี่ยวกับ ClickHouse ฉันยังคงรับประกันได้ว่า ใช่ มันไม่ช้าลง ฉันจะไม่พูดถึงระบบอื่น
นอกจากนี้ พจนานุกรมยังเป็นวิธีที่ง่ายมากในการอัปเดตข้อมูลย้อนหลังใน ClickHouse นั่นคือคุณมีรายงานเกี่ยวกับบริษัทโฆษณา ผู้ใช้เพียงแค่เปลี่ยนบริษัทโฆษณา และในข้อมูลเก่าทั้งหมด ข้อมูลนี้ก็เปลี่ยนไปในรายงานทั้งหมดด้วย หากคุณเขียนแถวลงในตารางโดยตรง คุณจะไม่สามารถอัปเดตได้
อีกวิธีหนึ่งเมื่อคุณไม่รู้ว่าจะรับตัวระบุสำหรับสตริงของคุณได้ที่ไหน คุณสามารถแฮชมันได้ นอกจากนี้ ตัวเลือกที่ง่ายที่สุดคือใช้แฮชแบบ 64 บิต
ปัญหาเดียวคือถ้าแฮชเป็น 64 บิต คุณเกือบจะเกิดการชนกันอย่างแน่นอน เพราะถ้ามีเส้นเป็นพันล้านเส้น ความน่าจะเป็นก็ชัดเจนขึ้นแล้ว
และคงจะไม่ดีนักหากจะแฮชชื่อบริษัทโฆษณาในลักษณะนี้ หากแคมเปญโฆษณาของบริษัทต่างๆ ปะปนกัน ก็จะมีบางอย่างที่เข้าใจไม่ได้
และมีเคล็ดลับง่ายๆ จริงอยู่ที่ข้อมูลร้ายแรงไม่เหมาะนัก แต่ถ้ามีบางสิ่งที่ไม่ร้ายแรงมาก เพียงเพิ่มตัวระบุไคลเอ็นต์ลงในคีย์พจนานุกรม แล้วคุณจะเกิดการชนกัน แต่จะเกิดขึ้นภายในไคลเอนต์เดียวเท่านั้น และเราใช้วิธีนี้สำหรับลิงก์แมปใน Yandex.Metrica เรามี URL ที่นั่น เราเก็บแฮช และเรารู้ว่ามีการชนกันแน่นอน แต่เมื่อเพจนั้นแสดงขึ้น ความน่าจะเป็นที่ URL บางส่วนจะติดกันและจะสังเกตได้ในหน้าหนึ่งของผู้ใช้รายหนึ่งนั้นสามารถถูกละเลยได้
เป็นโบนัส สำหรับแฮชการดำเนินการหลายอย่างเพียงอย่างเดียวก็เพียงพอแล้ว และไม่จำเป็นต้องจัดเก็บสตริงไว้ที่ใดก็ได้
อีกตัวอย่างหนึ่งคือหากสตริงสั้น เช่น โดเมนเว็บไซต์ สามารถจัดเก็บได้เหมือนเดิม หรือตัวอย่างเช่น ภาษาของเบราว์เซอร์ ru – 2 ไบต์ แน่นอนว่าฉันรู้สึกเสียใจกับไบต์จริงๆ แต่ไม่ต้องกังวล 2 ไบต์ก็ไม่น่าเสียดาย ขอให้เหมือนเดิม อย่ากังวล
อีกกรณีหนึ่งคือ ในทางกลับกัน มีบรรทัดจำนวนมากและมีบรรทัดที่ไม่ซ้ำใครอยู่ในนั้น และแม้แต่ฉากนั้นก็อาจมีไม่จำกัด ตัวอย่างทั่วไปคือวลีค้นหาหรือ URL วลีค้นหา รวมถึงการพิมพ์ผิด มาดูกันว่ามีวลีค้นหาที่ไม่ซ้ำกี่คำต่อวัน และปรากฎว่าพวกเขามีเกือบครึ่งหนึ่งของงานทั้งหมด และในกรณีนี้ คุณอาจคิดว่าคุณจำเป็นต้องทำให้ข้อมูลเป็นมาตรฐาน นับตัวระบุ และวางไว้ในตารางแยกต่างหาก แต่คุณไม่จำเป็นต้องทำอย่างนั้น เพียงเก็บบรรทัดเหล่านี้ไว้เหมือนเดิม
จะดีกว่าที่จะไม่ประดิษฐ์อะไรขึ้นมา เพราะถ้าคุณเก็บมันแยกกัน คุณจะต้องทำการเชื่อม และการรวมนี้คือการเข้าถึงหน่วยความจำแบบสุ่ม หากยังพอดีกับหน่วยความจำ ถ้าไม่พอดีก็จะเกิดปัญหา
และหากข้อมูลถูกเก็บไว้ก็จะอ่านตามลำดับที่ต้องการจากระบบไฟล์และทุกอย่างเรียบร้อยดี
หากคุณมี URL หรือสตริงยาวที่ซับซ้อนอื่นๆ ก็ควรพิจารณาว่าคุณสามารถคำนวณการแยกข้อมูลบางประเภทล่วงหน้าและเขียนลงในคอลัมน์แยกต่างหากได้
ตัวอย่างเช่น สำหรับ URL คุณสามารถจัดเก็บโดเมนแยกกันได้ และหากคุณต้องการโดเมนจริงๆ เพียงใช้คอลัมน์นี้ URL จะอยู่ตรงนั้นและคุณจะไม่แตะต้องเลยด้วยซ้ำ
มาดูกันว่าความแตกต่างคืออะไร ClickHouse มีฟังก์ชันพิเศษในการคำนวณโดเมน มันเร็วมาก เราได้เพิ่มประสิทธิภาพแล้ว และบอกตามตรงว่ามันไม่สอดคล้องกับ RFC ด้วยซ้ำ แต่ถึงกระนั้นก็ถือว่าทุกสิ่งที่เราต้องการ
และในกรณีหนึ่ง เราจะเพียงแค่รับ URL และคำนวณโดเมน นั่นคิดเป็น 166 มิลลิวินาที และถ้าคุณใช้โดเมนสำเร็จรูป จะใช้เวลาเพียง 67 มิลลิวินาที ซึ่งก็คือ เร็วกว่าเกือบสามเท่า และเร็วกว่าไม่ใช่เพราะเราต้องคำนวณบางอย่าง แต่เป็นเพราะเราอ่านข้อมูลน้อยลง
นั่นเป็นเหตุผลว่าทำไมหนึ่งคำขอซึ่งช้ากว่าจึงมีความเร็วที่สูงกว่ากิกะไบต์ต่อวินาที เพราะมันอ่านกิกะไบต์ได้มากกว่า นี่เป็นข้อมูลที่ไม่จำเป็นอย่างยิ่ง ดูเหมือนว่าคำขอจะทำงานเร็วขึ้น แต่ใช้เวลานานกว่าจึงจะเสร็จสมบูรณ์
และถ้าคุณดูจำนวนข้อมูลบนดิสก์ ปรากฎว่า URL มีขนาด 126 เมกะไบต์ และโดเมนมีขนาดเพียง 5 เมกะไบต์ ปรากฎน้อยกว่า 25 เท่า แต่อย่างไรก็ตาม คำขอจะดำเนินการเร็วขึ้นเพียง 4 เท่าเท่านั้น แต่นั่นเป็นเพราะข้อมูลมีความร้อนสูง และถ้ามันเย็น มันอาจจะเร็วขึ้น 25 เท่าเนื่องจากดิสก์ I/O
อย่างไรก็ตาม หากคุณประมาณว่าโดเมนมีขนาดเล็กกว่า URL เท่าใด โดเมนนั้นก็จะเล็กกว่าประมาณ 4 เท่า แต่ด้วยเหตุผลบางประการ ข้อมูลจึงใช้บนดิสก์น้อยกว่า 25 เท่า ทำไม เนื่องจากมีการบีบอัด และ URL ถูกบีบอัด และโดเมนถูกบีบอัด แต่บ่อยครั้งที่ URL มีขยะจำนวนมาก
และแน่นอนว่าต้องใช้ประเภทข้อมูลที่ถูกต้องซึ่งออกแบบมาโดยเฉพาะสำหรับค่าที่ต้องการหรือที่เหมาะสม หากคุณอยู่ใน IPv4 ให้จัดเก็บ UInt32* ถ้าเป็น IPv6 ให้ใช้ FixString(16) เนื่องจากที่อยู่ IPv6 มีขนาด 128 บิต กล่าวคือ จัดเก็บโดยตรงในรูปแบบไบนารี่
แต่จะเกิดอะไรขึ้นหากคุณมีที่อยู่ IPv4 และบางครั้งก็เป็น IPv6? ใช่ คุณสามารถจัดเก็บทั้งสองอย่างได้ หนึ่งคอลัมน์สำหรับ IPv4 และอีกคอลัมน์สำหรับ IPv6 แน่นอนว่ามีตัวเลือกให้แสดง IPv4 ใน IPv6 วิธีนี้จะได้ผลเช่นกัน แต่หากคุณต้องการที่อยู่ IPv4 ในคำขอบ่อยครั้ง ก็ควรใส่ไว้ในคอลัมน์แยกต่างหาก
* ขณะนี้ ClickHouse มีประเภทข้อมูล IPv4, IPv6 แยกกัน ซึ่งจัดเก็บข้อมูลได้อย่างมีประสิทธิภาพเท่ากับตัวเลข แต่แสดงข้อมูลได้สะดวกเหมือนกับสตริง
สิ่งสำคัญคือต้องทราบด้วยว่าการประมวลผลข้อมูลล่วงหน้านั้นคุ้มค่า ตัวอย่างเช่น คุณได้รับบันทึกข้อมูลดิบบางส่วน และบางทีคุณไม่ควรใส่พวกมันไว้ใน ClickHouse ทันที แม้ว่ามันจะไม่อยากทำอะไรเลยและทุกอย่างจะได้ผลก็ตาม แต่ก็ยังคุ้มค่าที่จะทำการคำนวณที่เป็นไปได้
เช่น เวอร์ชันของเบราว์เซอร์ ในแผนกใกล้เคียงบางแห่งซึ่งฉันไม่ต้องการชี้นิ้วไป เวอร์ชันของเบราว์เซอร์จะถูกจัดเก็บในลักษณะนี้ นั่นคือเป็นสตริง: 12.3 จากนั้น ในการทำรายงาน พวกเขานำสตริงนี้มาแบ่งเป็นอาร์เรย์ จากนั้นจึงแบ่งเป็นองค์ประกอบแรกของอาร์เรย์ โดยธรรมชาติแล้วทุกอย่างจะช้าลง ฉันถามว่าทำไมพวกเขาถึงทำเช่นนี้ พวกเขาบอกฉันว่าพวกเขาไม่ชอบการเพิ่มประสิทธิภาพก่อนเวลาอันควร และฉันไม่ชอบการมองโลกในแง่ร้ายก่อนวัยอันควร
ดังนั้นในกรณีนี้ แบ่งเป็น 4 คอลัมน์จะถูกต้องกว่า ไม่ต้องกลัวที่นี่เพราะนี่คือ ClickHouse ClickHouse เป็นฐานข้อมูลเรียงเป็นแนว และยิ่งคอลัมน์เล็ก ๆ เรียบร้อยมากเท่าไรก็ยิ่งดีเท่านั้น จะมี 5 BrowserVersions สร้าง 5 คอลัมน์ นี่เป็นเรื่องปกติ
ตอนนี้เรามาดูกันว่าจะทำอย่างไรถ้าคุณมีสตริงที่ยาวมากและอาร์เรย์ที่ยาวมาก ไม่จำเป็นต้องจัดเก็บไว้ใน ClickHouse เลย คุณสามารถจัดเก็บตัวระบุไว้ใน ClickHouse แทนได้ และใส่บรรทัดยาว ๆ เหล่านี้เข้าไปในระบบอื่น
ตัวอย่างเช่น หนึ่งในบริการวิเคราะห์ของเรามีพารามิเตอร์เหตุการณ์บางอย่าง และหากมีพารามิเตอร์มากมายสำหรับเหตุการณ์ เราก็จะบันทึก 512 ตัวแรกที่เจอ เพราะ 512 ไม่ใช่เรื่องน่าเสียดาย
และหากคุณไม่สามารถตัดสินใจเกี่ยวกับประเภทข้อมูลของคุณได้ คุณยังสามารถบันทึกข้อมูลใน ClickHouse ได้ แต่ในตารางชั่วคราวประเภท Log ซึ่งพิเศษสำหรับข้อมูลชั่วคราว หลังจากนี้ คุณสามารถวิเคราะห์ว่าคุณมีการกระจายค่าแบบใด โดยทั่วไปมีอะไรบ้าง และสร้างประเภทที่ถูกต้อง
*ตอนนี้ ClickHouse มีประเภทข้อมูลแล้ว ซึ่งช่วยให้คุณจัดเก็บสายได้อย่างมีประสิทธิภาพโดยใช้ความพยายามน้อยลง
ทีนี้เรามาดูอีกกรณีที่น่าสนใจกัน บางครั้งสิ่งต่าง ๆ ก็ดูแปลกสำหรับคน ฉันเข้ามาดูสิ่งนี้ และดูเหมือนว่าผู้ดูแลระบบที่ชาญฉลาดและมีประสบการณ์ซึ่งมีประสบการณ์มากมายในการตั้งค่า MySQL เวอร์ชัน 3.23 จะทำสิ่งนี้ได้ในทันที
ตรงนี้เราเห็นตารางนับพันตาราง แต่ละตารางจะบันทึกส่วนที่เหลือของการหารใครจะรู้ด้วยหลักพัน
โดยหลักการแล้ว ฉันเคารพประสบการณ์ของผู้อื่น รวมถึงความเข้าใจในความทุกข์ที่จะได้รับจากประสบการณ์นี้ด้วย
และเหตุผลก็ชัดเจนไม่มากก็น้อย สิ่งเหล่านี้เป็นแบบแผนเก่าๆ ที่อาจสะสมในขณะที่ทำงานกับระบบอื่นๆ ตัวอย่างเช่น ตาราง MyISAM ไม่มีคีย์หลักแบบคลัสเตอร์ และวิธีการแบ่งข้อมูลแบบนี้อาจเป็นความพยายามอย่างยิ่งยวดที่จะได้รับฟังก์ชันการทำงานแบบเดียวกัน
อีกเหตุผลหนึ่งก็คือ เป็นการยากที่จะดำเนินการแก้ไขใดๆ บนโต๊ะขนาดใหญ่ ทุกอย่างจะถูกปิดกั้น แม้ว่าใน MySQL เวอร์ชันใหม่ปัญหานี้จะไม่ร้ายแรงอีกต่อไป
หรือตัวอย่างเช่น microsharding แต่จะเพิ่มเติมในภายหลัง
ไม่จำเป็นต้องทำเช่นนี้ใน ClickHouse เนื่องจากประการแรก คีย์หลักจะถูกจัดกลุ่ม ข้อมูลจะถูกเรียงลำดับตามคีย์หลัก
และบางครั้งมีคนถามฉันว่า: “ประสิทธิภาพของการสืบค้นแบบช่วงใน ClickHouse แตกต่างกันอย่างไรโดยขึ้นอยู่กับขนาดของตาราง” ผมว่ามันไม่เปลี่ยนเลย ตัวอย่างเช่น คุณมีตารางที่มีหนึ่งพันล้านแถว และคุณอ่านช่วงหนึ่งล้านแถว ทุกอย่างปกติดี. หากมีหนึ่งล้านล้านแถวในตารางและคุณอ่านได้หนึ่งล้านแถว ก็จะเกือบจะเหมือนกัน
และประการที่สอง ไม่จำเป็นต้องใช้พาร์ติชั่นทุกประเภท เช่น พาร์ติชั่นแบบแมนนวล ถ้าคุณเข้าไปดูว่ามีอะไรอยู่ในระบบไฟล์ คุณจะเห็นว่าตารางเป็นเรื่องใหญ่ทีเดียว และมีบางอย่างเช่นพาร์ติชั่นอยู่ข้างใน นั่นคือ ClickHouse ทำทุกอย่างเพื่อคุณและคุณไม่จำเป็นต้องทนทุกข์ทรมาน
แก้ไขใน ClickHouse ได้ฟรี หากแก้ไขคอลัมน์เพิ่ม/ลด
และคุณไม่ควรสร้างตารางเล็กๆ เพราะถ้าคุณมี 10 แถวหรือ 10 แถวในตาราง ก็ไม่สำคัญเลย ClickHouse เป็นระบบที่ปรับปริมาณงานให้เหมาะสม ไม่ใช่เวลาแฝง ดังนั้นจึงไม่มีเหตุผลที่จะประมวลผล 000 ไลน์
ถูกต้องแล้วที่จะใช้โต๊ะใหญ่ตัวเดียว กำจัดแบบเหมารวมเก่า ๆ ทุกอย่างจะเรียบร้อยดี
และเพื่อเป็นโบนัส ในเวอร์ชันล่าสุด ตอนนี้เราสามารถสร้างคีย์การแบ่งพาร์ติชันได้ตามใจชอบ เพื่อดำเนินการบำรุงรักษาทุกประเภทในแต่ละพาร์ติชัน
ตัวอย่างเช่น คุณต้องมีตารางเล็กๆ จำนวนมาก ตัวอย่างเช่น เมื่อจำเป็นต้องประมวลผลข้อมูลระดับกลาง คุณจะได้รับชิ้นส่วนและคุณจำเป็นต้องทำการเปลี่ยนแปลงตารางเหล่านั้นก่อนที่จะเขียนลงในตารางสุดท้าย ในกรณีนี้มีเอ็นจิ้นตารางที่ยอดเยี่ยม - StripeLog มันเหมือนกับ TinyLog ดีกว่าเท่านั้น
*ตอนนี้ ClickHouse ก็มี .
การต่อต้านรูปแบบอื่นคือไมโครชาร์ด ตัวอย่างเช่น คุณต้องแบ่งข้อมูลและคุณมีเซิร์ฟเวอร์ 5 เครื่อง และพรุ่งนี้จะมีเซิร์ฟเวอร์ 6 เครื่อง และคุณคิดว่าจะปรับสมดุลข้อมูลนี้อย่างไร และแทนที่จะแตกออกเป็น 5 ส่วน แต่เป็น 1 ส่วน จากนั้นคุณแมปไมโครชาร์ดแต่ละอันเหล่านี้กับเซิร์ฟเวอร์ที่แยกจากกัน และคุณจะได้รับ 000 ClickHouses บนเซิร์ฟเวอร์เดียว เป็นต้น แยกอินสแตนซ์บนพอร์ตแยกหรือฐานข้อมูลแยกกัน
แต่นี่ไม่ค่อยดีนักใน ClickHouse เพราะแม้แต่ ClickHouse ตัวเดียวก็พยายามใช้ทรัพยากรเซิร์ฟเวอร์ที่มีอยู่ทั้งหมดเพื่อประมวลผลคำขอเดียว นั่นคือคุณมีเซิร์ฟเวอร์บางประเภทและมีแกนประมวลผล 56 ตัว คุณกำลังเรียกใช้แบบสอบถามที่ใช้เวลาหนึ่งวินาทีและจะใช้ 56 คอร์ และถ้าคุณวาง 200 ClickHouses ไว้บนเซิร์ฟเวอร์เดียว ปรากฎว่า 10 เธรดจะเริ่มขึ้น โดยทั่วไปทุกอย่างจะแย่มาก
อีกเหตุผลหนึ่งก็คือการกระจายงานระหว่างอินสแตนซ์เหล่านี้จะไม่สม่ำเสมอ บางอย่างจะเสร็จเร็วกว่านี้ บางอย่างจะเสร็จทีหลัง หากทั้งหมดนี้เกิดขึ้นในอินสแตนซ์เดียว ClickHouse เองก็จะหาวิธีกระจายข้อมูลระหว่างเธรดได้อย่างถูกต้อง
และอีกเหตุผลหนึ่งก็คือ คุณจะมีการสื่อสารระหว่างโปรเซสเซอร์ผ่าน TCP ข้อมูลจะต้องมีซีเรียลไลซ์ ดีซีเรียลไลซ์ และนี่คือไมโครชาร์ดจำนวนมาก มันจะไม่ทำงานอย่างมีประสิทธิภาพ
การต่อต้านรูปแบบอื่น แม้ว่าจะแทบจะเรียกได้ว่าเป็นการต่อต้านรูปแบบก็ตาม นี่เป็นการรวมตัวล่วงหน้าจำนวนมาก
โดยทั่วไปแล้ว การรวมกลุ่มล่วงหน้าเป็นสิ่งที่ดี คุณมีหนึ่งพันล้านแถว คุณรวมมันเข้าด้วยกันจนกลายเป็น 1 แถว และตอนนี้แบบสอบถามก็ดำเนินการทันที ทุกอย่างดีมาก คุณสามารถทำเช่นนี้ได้ และสำหรับสิ่งนี้ แม้แต่ ClickHouse ก็มีประเภทตารางพิเศษ AggregatingMergeTree ซึ่งดำเนินการรวมส่วนเพิ่มเมื่อมีการแทรกข้อมูล
แต่มีหลายครั้งที่คุณคิดว่าเราจะรวบรวมข้อมูลเช่นนี้และรวบรวมข้อมูลเช่นนี้ และในแผนกใกล้เคียงบางแห่ง ฉันก็ไม่อยากบอกว่าแผนกไหน พวกเขาใช้ตาราง SummingMergeTree เพื่อสรุปด้วยคีย์หลัก และประมาณ 20 คอลัมน์ถูกใช้เป็นคีย์หลัก ในกรณีที่ฉันเปลี่ยนชื่อของบางคอลัมน์เพื่อเก็บไว้เป็นความลับ แต่ก็ค่อนข้างจะเป็นเช่นนั้น
และปัญหาดังกล่าวก็เกิดขึ้น ประการแรก ปริมาณข้อมูลของคุณไม่ลดลงมากเกินไป เช่น ลดลง XNUMX เท่า สามครั้งถือเป็นราคาที่ดีที่จะจ่ายความสามารถในการวิเคราะห์แบบไม่จำกัดที่เกิดขึ้นหากข้อมูลของคุณไม่ได้ถูกรวมเข้าด้วยกัน หากข้อมูลถูกรวมเข้าด้วยกัน แทนที่จะเป็นการวิเคราะห์ คุณจะได้รับเพียงสถิติที่น่าสมเพช
และมีอะไรพิเศษเกี่ยวกับเรื่องนี้? ความจริงก็คือบางครั้งคนเหล่านี้จากแผนกใกล้เคียงไปขอเพิ่มคอลัมน์อื่นในคีย์หลัก นั่นคือเรารวบรวมข้อมูลเช่นนี้ แต่ตอนนี้เราต้องการเพิ่มอีกนิด แต่ ClickHouse ไม่มีคีย์หลักที่เปลี่ยนแปลง ดังนั้นเราจึงต้องเขียนสคริปต์บางส่วนในภาษา C++ และฉันไม่ชอบสคริปต์ถึงแม้ว่ามันจะเป็นภาษา C++ ก็ตาม
และถ้าคุณดูว่า ClickHouse ถูกสร้างขึ้นมาเพื่ออะไร ข้อมูลที่ไม่ได้รวบรวมไว้ก็จะเป็นสถานการณ์ที่เกิดขึ้นอย่างแน่นอน หากคุณใช้ ClickHouse สำหรับข้อมูลที่ไม่ได้รวบรวม แสดงว่าคุณทำถูกต้องแล้ว หากคุณรวมกันบางครั้งอาจให้อภัยได้
อีกกรณีที่น่าสนใจคือการสืบค้นแบบวนไม่สิ้นสุด บางครั้งฉันไปที่เซิร์ฟเวอร์ที่ใช้งานจริงและดูรายการกระบวนการที่นั่น และทุกครั้งที่ฉันพบว่ามีเรื่องเลวร้ายเกิดขึ้น
ตัวอย่างเช่นเช่นนี้ เป็นที่ชัดเจนในทันทีว่าทุกสิ่งสามารถทำได้ในคำขอเดียว เพียงเขียน url และรายการที่นั่น
เหตุใดข้อความค้นหาดังกล่าวจำนวนมากในวงวนไม่สิ้นสุดจึงไม่ดี หากไม่ได้ใช้ดัชนี คุณจะมีการส่งผ่านข้อมูลเดียวกันหลายครั้ง แต่หากใช้ดัชนี คุณจะมีคีย์หลักสำหรับ ru และคุณเขียน url = บางอย่างที่นั่น และคุณคิดว่าหากมีการอ่าน URL เพียงรายการเดียวจากตาราง ทุกอย่างจะเรียบร้อยดี แต่จริงๆแล้วไม่มี เพราะ ClickHouse ทำทุกอย่างเป็นชุด
เมื่อเขาต้องการอ่านข้อมูลบางช่วง เขาจะอ่านเพิ่มขึ้นอีกเล็กน้อย เนื่องจากดัชนีใน ClickHouse มีไม่มากนัก ดัชนีนี้ไม่อนุญาตให้คุณค้นหาแถวใดแถวหนึ่งในตาราง มีเพียงช่วงบางประเภทเท่านั้น และข้อมูลจะถูกบีบอัดเป็นบล็อก หากต้องการอ่านหนึ่งบรรทัด คุณต้องถอดบล็อกทั้งหมดแล้วคลายออก และถ้าคุณทำแบบสอบถามจำนวนมาก คุณจะมีการทับซ้อนกันมากมาย และคุณจะมีงานมากมายที่ต้องทำซ้ำแล้วซ้ำอีก
และเพื่อเป็นโบนัส โปรดทราบว่าใน ClickHouse คุณไม่ควรกลัวที่จะถ่ายโอนแม้แต่เมกะไบต์หรือหลายร้อยเมกะไบต์ไปยังส่วน IN ฉันจำได้จากการปฏิบัติของเราว่าหากใน MySQL เราถ่ายโอนค่าจำนวนมากไปยังส่วน IN เช่นเราถ่ายโอนตัวเลขจำนวนหนึ่งที่นั่น 100 เมกะไบต์ MySQL จะกินหน่วยความจำมากถึง 10 กิกะไบต์และไม่มีอะไรเกิดขึ้นกับมันอีก ทุกอย่าง ทำงานได้ไม่ดี
และอย่างที่สองก็คือใน ClickHouse หากการสืบค้นของคุณใช้ดัชนี มันก็จะไม่ช้าไปกว่าการสแกนแบบเต็มเสมอไป เช่น หากคุณต้องการอ่านเกือบทั้งตาราง มันจะไปตามลำดับและอ่านทั้งตาราง โดยทั่วไปเขาจะคิดออกเอง
แต่ถึงกระนั้นก็ยังมีปัญหาอยู่บ้าง ตัวอย่างเช่น ข้อเท็จจริงที่ว่า IN กับแบบสอบถามย่อยไม่ได้ใช้ดัชนี แต่นี่คือปัญหาของเรา และเราจำเป็นต้องแก้ไขมัน ไม่มีอะไรพื้นฐานที่นี่ เราจะแก้ไขให้*.
และสิ่งที่น่าสนใจอีกอย่างคือ หากคุณมีคำขอที่ยาวมากและกำลังประมวลผลคำขอแบบกระจาย คำขอที่ยาวมากนี้จะถูกส่งไปยังแต่ละเซิร์ฟเวอร์โดยไม่มีการบีบอัด ตัวอย่างเช่น 100 เมกะไบต์และ 500 เซิร์ฟเวอร์ และด้วยเหตุนี้ คุณจะมีการถ่ายโอนข้อมูล 50 กิกะไบต์ผ่านเครือข่าย มันจะถูกส่งและจากนั้นทุกอย่างจะเสร็จสิ้นสำเร็จ
* ใช้อยู่แล้ว; ทุกอย่างได้รับการแก้ไขตามที่สัญญาไว้
และกรณีที่พบบ่อยคือเมื่อคำขอมาจาก API ตัวอย่างเช่น คุณสร้างบริการบางอย่างของคุณเอง และหากมีใครต้องการบริการของคุณ คุณจะต้องเปิด API และอีกสองวันต่อมาคุณจะเห็นว่ามีบางสิ่งที่ไม่อาจเข้าใจได้เกิดขึ้น ทุกอย่างล้นหลามและมีคำขอแย่ๆ เข้ามาซึ่งไม่ควรเกิดขึ้น
และมีทางออกเดียวเท่านั้น หากคุณเปิด API แล้วคุณจะต้องตัดมัน ตัวอย่างเช่น แนะนำโควต้าบางประเภท ไม่มีตัวเลือกปกติอื่น ๆ มิฉะนั้นจะเขียนสคริปต์ทันทีและจะเกิดปัญหา
และ ClickHouse มีคุณสมบัติพิเศษ - การคำนวณโควต้า นอกจากนี้ คุณยังสามารถโอนโควต้าคีย์ของคุณได้ ตัวอย่างเช่น นี่คือ ID ผู้ใช้ภายใน และโควต้าจะถูกคำนวณแยกกันสำหรับแต่ละรายการ
ตอนนี้อีกสิ่งที่น่าสนใจ นี่คือการจำลองแบบด้วยตนเอง
ฉันทราบในหลายกรณีที่แม้ว่า ClickHouse จะรองรับการจำลองแบบในตัว แต่ผู้คนก็จำลอง ClickHouse ด้วยตนเอง
หลักการคืออะไร? คุณมีไปป์ไลน์การประมวลผลข้อมูล และทำงานแยกกัน เช่น ในศูนย์ข้อมูลต่างๆ คุณเขียนข้อมูลเดียวกันในลักษณะเดียวกันใน ClickHouse จริงอยู่ การปฏิบัติแสดงให้เห็นว่าข้อมูลจะยังคงแตกต่างกันเนื่องจากคุณลักษณะบางอย่างในโค้ดของคุณ ฉันหวังว่ามันจะอยู่ในของคุณ
และในบางครั้งคุณยังคงต้องซิงค์ด้วยตนเอง ตัวอย่างเช่น ผู้ดูแลระบบจะทำการซิงค์ rsync เดือนละครั้ง
ในความเป็นจริง การใช้การจำลองแบบที่สร้างไว้ใน ClickHouse นั้นง่ายกว่ามาก แต่อาจมีข้อห้ามบางประการเนื่องจากคุณต้องใช้ ZooKeeper ฉันจะไม่พูดอะไรที่ไม่ดีเกี่ยวกับ ZooKeeper โดยหลักการแล้ว ระบบใช้งานได้ แต่มันเกิดขึ้นที่ผู้คนไม่ได้ใช้มันเพราะว่าเป็นโรคกลัวจาวา เพราะ ClickHouse เป็นระบบที่ดี เขียนด้วยภาษา C++ ซึ่งคุณสามารถใช้และ ทุกอย่างจะเรียบร้อยดี และ ZooKeeper อยู่ในจาวา และอย่างใดคุณไม่ต้องการดูด้วยซ้ำ แต่คุณสามารถใช้การจำลองแบบด้วยตนเองได้
ClickHouse เป็นระบบที่ใช้งานได้จริง เธอคำนึงถึงความต้องการของคุณ หากคุณมีการจำลองแบบด้วยตนเอง คุณสามารถสร้างตารางแบบกระจายที่จะดูแบบจำลองด้วยตนเองของคุณและทำการเฟลโอเวอร์ระหว่างแบบจำลองเหล่านั้น และยังมีตัวเลือกพิเศษที่ช่วยให้คุณหลีกเลี่ยงการล้มเหลว แม้ว่าไลน์ของคุณจะแยกออกจากกันอย่างเป็นระบบก็ตาม
ปัญหาเพิ่มเติมอาจเกิดขึ้นหากคุณใช้กลไกจัดการตารางดั้งเดิม ClickHouse เป็นตัวสร้างที่มีเอ็นจิ้นตารางที่แตกต่างกันมากมาย สำหรับกรณีที่ร้ายแรงทั้งหมด ตามที่เขียนไว้ในเอกสารประกอบ ให้ใช้ตารางจากตระกูล MergeTree และที่เหลือทั้งหมดก็เป็นเช่นนั้น สำหรับแต่ละกรณีหรือสำหรับการทดสอบ
ในตาราง MergeTree คุณไม่จำเป็นต้องมีวันที่และเวลา คุณยังสามารถใช้งานได้ หากไม่มีวันที่และเวลา ให้เขียนค่าเริ่มต้นคือ 2000 สิ่งนี้จะได้ผลและไม่ต้องใช้ทรัพยากร
และในเซิร์ฟเวอร์เวอร์ชันใหม่ คุณยังสามารถระบุได้ว่าคุณมีการแบ่งพาร์ติชันแบบกำหนดเองโดยไม่มีคีย์พาร์ติชันอีกด้วย มันจะเหมือนกัน
ในทางกลับกัน คุณสามารถใช้เอ็นจิ้นตารางดั้งเดิมได้ เช่น กรอกข้อมูลครั้งเดียวแล้วดู บิด และลบ คุณสามารถใช้บันทึก
หรือการจัดเก็บปริมาณน้อยเพื่อการประมวลผลระดับกลางคือ StripeLog หรือ TinyLog
สามารถใช้หน่วยความจำได้หากข้อมูลมีน้อย และคุณสามารถซ้อนบางอย่างใน RAM ได้
ClickHouse ไม่ชอบข้อมูลที่ปรับให้เป็นมาตรฐานใหม่
นี่เป็นตัวอย่างทั่วไป นี่เป็น URL จำนวนมาก คุณวางไว้ในตารางถัดไป จากนั้นพวกเขาก็ตัดสินใจเข้าร่วมกับพวกเขา แต่ตามกฎแล้วจะไม่ได้ผลเพราะ ClickHouse รองรับเฉพาะ Hash JOIN เท่านั้น หากมี RAM ไม่เพียงพอสำหรับข้อมูลจำนวนมากที่ต้องเชื่อมต่อ JOIN จะไม่ทำงาน*
หากข้อมูลมีคาร์ดินัลลิตี้สูง ไม่ต้องกังวล เพราะจัดเก็บไว้ในรูปแบบที่ไม่ปกติ URL จะอยู่ในตารางหลักโดยตรง
* และตอนนี้ ClickHouse มีการผสานรวมด้วย และทำงานได้ในสภาวะที่ข้อมูลระดับกลางไม่พอดีกับ RAM แต่สิ่งนี้ไม่ได้ผลและข้อเสนอแนะยังคงมีผลใช้บังคับ
อีกสองสามตัวอย่าง แต่ฉันสงสัยแล้วว่าพวกมันต่อต้านรูปแบบหรือไม่
ClickHouse มีข้อบกพร่องหนึ่งประการที่ทราบ มันไม่รู้วิธีอัปเดต* ในบางแง่นี่เป็นสิ่งที่ดีด้วยซ้ำ หากคุณมีข้อมูลสำคัญบางอย่าง เช่น การบัญชี ก็จะไม่มีใครสามารถส่งข้อมูลดังกล่าวได้ เนื่องจากไม่มีการอัพเดต
* เพิ่มการสนับสนุนการอัปเดตและการลบในโหมดแบทช์มานานแล้ว
แต่มีวิธีพิเศษบางอย่างที่อนุญาตให้อัปเดตราวกับอยู่ในเบื้องหลัง ตัวอย่างเช่น ตารางเช่น CompareMergeTree พวกเขาทำการอัปเดตระหว่างการรวมในเบื้องหลัง คุณสามารถบังคับสิ่งนี้ได้โดยใช้ตารางเพิ่มประสิทธิภาพ แต่อย่าทำบ่อยเกินไป เพราะมันจะเขียนทับพาร์ติชั่นทั้งหมด
JOIN แบบกระจายใน ClickHouse ยังได้รับการจัดการที่ไม่ดีโดยผู้วางแผนแบบสอบถาม
แย่แต่บางครั้งก็โอเค
ใช้ ClickHouse เพื่ออ่านข้อมูลกลับโดยใช้ select* เท่านั้น
ฉันไม่แนะนำให้ใช้ ClickHouse สำหรับการคำนวณที่ยุ่งยาก แต่สิ่งนี้ไม่เป็นความจริงทั้งหมด เนื่องจากเรากำลังละทิ้งคำแนะนำนี้ไปแล้ว และเมื่อเร็ว ๆ นี้เราได้เพิ่มความสามารถในการใช้โมเดลการเรียนรู้ของเครื่องใน ClickHouse - Catboost และมันก็กวนใจฉันเพราะฉันคิดว่า "ช่างน่ากลัวจริงๆ นี่คือจำนวนรอบต่อไบต์! ฉันเกลียดการสิ้นเปลืองนาฬิกาเป็นไบต์จริงๆ
แต่อย่ากลัว ติดตั้ง ClickHouse แล้วทุกอย่างจะเรียบร้อย ถ้ามีอะไรเราก็มีชุมชน อย่างไรก็ตาม ชุมชนก็คือคุณ และหากคุณมีปัญหาใดๆ อย่างน้อยคุณก็สามารถเข้าไปที่แชทของเราได้ และหวังว่าพวกเขาจะช่วยคุณได้
คำถาม
ขอบคุณสำหรับรายงาน! ฉันจะร้องเรียนเกี่ยวกับ ClickHouse ขัดข้องได้ที่ไหน?
คุณสามารถร้องเรียนฉันได้เป็นการส่วนตัวตอนนี้
ฉันเพิ่งเริ่มใช้ ClickHouse ฉันทิ้งอินเทอร์เฟซ cli ทันที
คะแนนอะไรขนาดนั้น
หลังจากนั้นไม่นานฉันก็ทำให้เซิร์ฟเวอร์เสียหายด้วยการเลือกเล็กน้อย
คุณมีความสามารถ
ฉันเปิดข้อบกพร่องของ GitHub แต่กลับถูกเพิกเฉย
เราจะได้เห็น
Alexey หลอกให้ฉันเข้าร่วมรายงาน โดยสัญญาว่าจะบอกฉันว่าคุณเข้าถึงข้อมูลภายในได้อย่างไร
ง่ายมาก
ฉันตระหนักเรื่องนี้เมื่อวานนี้ เฉพาะเจาะจงมากขึ้น
ไม่มีกลอุบายที่น่ากลัวที่นั่น มีเพียงการบีบอัดแบบบล็อกต่อบล็อก ค่าเริ่มต้นคือ LZ4 คุณสามารถเปิดใช้งาน ZSTD* ได้ บล็อกจาก 64 กิโลไบต์ถึง 1 เมกะไบต์
* นอกจากนี้ยังรองรับตัวแปลงสัญญาณการบีบอัดแบบพิเศษที่สามารถใช้ในลูกโซ่กับอัลกอริธึมอื่น ๆ
บล็อกเป็นเพียงข้อมูลดิบหรือไม่
ไม่ดิบสมบูรณ์ มีอาร์เรย์ หากคุณมีคอลัมน์ตัวเลข ตัวเลขในแถวจะถูกวางไว้ในอาร์เรย์
ก็เป็นที่ชัดเจน.
Alexey ซึ่งเป็นตัวอย่างที่ใช้ uniqExact บน IP เช่น ความจริงที่ว่า uniqExact ใช้เวลาในการคำนวณเป็นบรรทัดนานกว่าตัวเลข และอื่นๆ จะเป็นอย่างไรถ้าเราใช้หูปลอมและร่ายในขณะที่ตรวจทาน? นั่นคือดูเหมือนคุณจะบอกว่ามันไม่แตกต่างกันมากในดิสก์ของเรา ถ้าเราอ่านบรรทัดจากดิสก์และแคสต์ การรวมตัวของเราจะเร็วขึ้นหรือไม่? หรือเราจะยังคงเพิ่มขึ้นเล็กน้อยที่นี่? สำหรับฉันดูเหมือนว่าคุณได้ทดสอบสิ่งนี้แล้ว แต่ด้วยเหตุผลบางอย่างไม่ได้ระบุไว้ในเกณฑ์มาตรฐาน
ฉันคิดว่ามันจะช้ากว่าไม่มีแคส ในกรณีนี้ ต้องแยกวิเคราะห์ที่อยู่ IP จากสตริง แน่นอนว่าที่ ClickHouse การแยกวิเคราะห์ที่อยู่ IP ของเราก็ได้รับการปรับให้เหมาะสมเช่นกัน เราพยายามอย่างหนัก แต่คุณมีตัวเลขเขียนอยู่ในรูปหลักหมื่น ไม่สบายตัวมาก ในทางกลับกัน ฟังก์ชัน uniqExact จะทำงานช้าลงบนสตริง ไม่ใช่เพียงเพราะเป็นสตริงเท่านั้น แต่ยังเป็นเพราะเลือกความเชี่ยวชาญพิเศษที่แตกต่างกันของอัลกอริทึมด้วย สตริงได้รับการประมวลผลแตกต่างกัน
จะเกิดอะไรขึ้นถ้าเราใช้ประเภทข้อมูลดั้งเดิมกว่านี้? เช่นเราจด user id ที่เรามี จดเป็นบรรทัดแล้วกวนจะสนุกกว่าหรือเปล่า?
ฉันสงสัย. ฉันคิดว่ามันคงจะเศร้ากว่านี้อีก เพราะท้ายที่สุดแล้ว การแยกวิเคราะห์ตัวเลขถือเป็นปัญหาร้ายแรง สำหรับฉันดูเหมือนว่าเพื่อนร่วมงานคนนี้ยังรายงานว่าการแยกวิเคราะห์ตัวเลขในรูปแบบหมื่นนั้นยากแค่ไหน แต่อาจจะไม่
Alexey ขอบคุณมากสำหรับรายงาน! และขอบคุณมากสำหรับ ClickHouse! ฉันมีคำถามเกี่ยวกับแผน มีแผนสำหรับฟีเจอร์ที่จะอัปเดตพจนานุกรมที่ไม่สมบูรณ์หรือไม่?
นั่นคือการรีบูตบางส่วน?
ใช่ ๆ. เช่นเดียวกับความสามารถในการตั้งค่าฟิลด์ MySQL ที่นั่น เช่น อัปเดตหลังจากนั้นเพื่อให้โหลดเฉพาะข้อมูลนี้หากพจนานุกรมมีขนาดใหญ่มาก
คุณสมบัติที่น่าสนใจมาก และฉันคิดว่ามีคนแนะนำมันในการแชทของเรา บางทีอาจเป็นคุณด้วยซ้ำ
ฉันไม่คิดอย่างนั้น
เยี่ยมมาก ตอนนี้ปรากฎว่ามีสองคำขอ และคุณสามารถเริ่มทำมันได้ช้าๆ แต่ฉันต้องการเตือนคุณทันทีว่าคุณลักษณะนี้ใช้งานได้ค่อนข้างง่าย ตามทฤษฎีแล้วคุณเพียงแค่ต้องเขียนหมายเลขเวอร์ชันลงในตารางแล้วเขียน: เวอร์ชันน้อยกว่าเช่นนั้น ซึ่งหมายความว่าเป็นไปได้มากว่าเราจะเสนอสิ่งนี้ให้กับผู้ที่ชื่นชอบ คุณเป็นคนกระตือรือร้นหรือไม่?
ใช่ แต่น่าเสียดายที่ไม่ใช่ใน C++
เพื่อนร่วมงานของคุณรู้วิธีเขียนด้วยภาษา C++ หรือไม่?
ฉันจะหาใครสักคน
ยอดเยี่ยม*.
* คุณลักษณะนี้ถูกเพิ่มเข้ามาสองเดือนหลังจากรายงาน - ผู้เขียนคำถามได้พัฒนาและส่งของเขา .
ขอบคุณ!
สวัสดี! ขอบคุณสำหรับรายงาน! คุณบอกว่า ClickHouse ใช้ทรัพยากรทั้งหมดที่มีอยู่ได้ดีมาก และวิทยากรที่อยู่ถัดจาก Luxoft ได้พูดคุยเกี่ยวกับโซลูชันของเขาสำหรับ Russian Post เขาบอกว่าพวกเขาชอบ ClickHouse มาก แต่พวกเขาไม่ได้ใช้มันแทนคู่แข่งหลักเลยเพราะมันกิน CPU ไปหมด และพวกเขาไม่สามารถเสียบมันเข้ากับสถาปัตยกรรมของพวกเขา เข้ากับ ZooKeeper พร้อมนักเทียบท่าได้ เป็นไปได้ไหมที่จะจำกัด ClickHouse เพื่อไม่ให้กินทุกสิ่งที่มีอยู่?
ใช่ มันเป็นไปได้และง่ายมาก หากคุณต้องการใช้คอร์น้อยลงก็แค่เขียน set max_threads = 1. เพียงเท่านี้ก็จะดำเนินการตามคำขอในคอร์เดียว นอกจากนี้ คุณยังสามารถระบุการตั้งค่าที่แตกต่างกันสำหรับผู้ใช้ที่แตกต่างกันได้ เลยไม่มีปัญหา และบอกเพื่อนร่วมงานของคุณจาก Luxoft ว่าการไม่พบการตั้งค่านี้ในเอกสารประกอบนั้นไม่ดี
อเล็กซ์สวัสดี! ฉันอยากจะถามคำถามนี้ นี่ไม่ใช่ครั้งแรกที่ฉันได้ยินว่าผู้คนจำนวนมากเริ่มใช้ ClickHouse เป็นที่จัดเก็บบันทึก ในรายงานคุณบอกว่าอย่าทำเช่นนี้ กล่าวคือ คุณไม่จำเป็นต้องเก็บสตริงที่ยาว คุณคิดอย่างไรเกี่ยวกับเรื่องนี้?
ประการแรก บันทึกมักจะไม่ใช่สตริงที่ยาว แน่นอนว่ามีข้อยกเว้นอยู่ ตัวอย่างเช่น บริการบางอย่างที่เขียนด้วย Java มีข้อยกเว้นเกิดขึ้น และจะถูกบันทึกไว้ วนซ้ำไม่รู้จบและพื้นที่บนฮาร์ดไดรฟ์ก็หมด วิธีแก้ปัญหานั้นง่ายมาก ถ้าเส้นยาวมากก็ตัดทิ้ง ยาวหมายถึงอะไร? หลายสิบกิโลไบต์นั้นแย่*
* ใน ClickHouse เวอร์ชันล่าสุด มีการเปิดใช้งาน "รายละเอียดดัชนีแบบปรับได้" ซึ่งช่วยขจัดปัญหาในการจัดเก็บแถวยาวเป็นส่วนใหญ่
กิโลไบต์เป็นเรื่องปกติหรือไม่?
ปกติ
สวัสดี! ขอบคุณสำหรับรายงาน! ฉันถามเกี่ยวกับเรื่องนี้แล้วในการแชท แต่ฉันจำไม่ได้ว่าได้รับคำตอบหรือไม่ มีแผนที่จะขยายส่วน WITH ในลักษณะ CTE หรือไม่?
ยัง. ส่วน WITH ของเราค่อนข้างไม่สำคัญ มันเหมือนเป็นคุณสมบัติเล็กๆ น้อยๆ สำหรับเรา
ฉันเข้าใจ. ขอบคุณ!
ขอบคุณสำหรับรายงาน! น่าสนใจมาก! คำถามระดับโลก มีแผนจะแก้ไขการลบข้อมูลหรือไม่ ซึ่งอาจอยู่ในรูปแบบ stubs บางประเภทหรือไม่?
อย่างจำเป็น. นี่เป็นงานแรกของเราในคิวของเรา ตอนนี้เรากำลังคิดอย่างจริงจังว่าจะทำทุกอย่างอย่างถูกต้องได้อย่างไร และคุณควรเริ่มกดแป้นพิมพ์*
* กดปุ่มบนคีย์บอร์ดแล้วทำทุกอย่าง
สิ่งนี้จะส่งผลต่อประสิทธิภาพของระบบหรือไม่? การแทรกจะเร็วเหมือนตอนนี้หรือไม่?
บางทีการลบตัวเองและการอัพเดตอาจจะหนักมาก แต่สิ่งนี้จะไม่ส่งผลกระทบต่อประสิทธิภาพของการเลือกหรือประสิทธิภาพของส่วนแทรก
และอีกหนึ่งคำถามเล็กๆ น้อยๆ ในการนำเสนอคุณได้พูดคุยเกี่ยวกับคีย์หลัก ดังนั้นเราจึงมีการแบ่งพาร์ติชันซึ่งเป็นรายเดือนตามค่าเริ่มต้นใช่ไหม? และเมื่อเรากำหนดช่วงวันที่ให้พอดีกับเดือนก็จะอ่านเฉพาะพาร์ติชันนี้ใช่ไหม?
ใช่
คำถาม. หากเราไม่สามารถเลือกคีย์หลักใดๆ ได้ จะต้องดำเนินการตามช่อง "วันที่" โดยเฉพาะ เพื่อที่เบื้องหลังจะมีการจัดเรียงข้อมูลนี้ใหม่น้อยลงเพื่อให้เข้ากันอย่างเป็นระเบียบมากขึ้น หากคุณไม่มีการสืบค้นช่วงและคุณไม่สามารถเลือกคีย์หลักได้ ควรใส่วันที่ในคีย์หลักหรือไม่
ใช่
บางทีอาจเป็นการเหมาะสมที่จะใส่ฟิลด์ในคีย์หลักที่จะบีบอัดข้อมูลได้ดีขึ้นหากเรียงลำดับตามฟิลด์นี้ ตัวอย่างเช่น รหัสผู้ใช้ ตัวอย่างเช่น ผู้ใช้ไปที่ไซต์เดียวกัน ในกรณีนี้ให้ใส่รหัสผู้ใช้และเวลา จากนั้นข้อมูลของคุณจะถูกบีบอัดได้ดีขึ้น สำหรับวันที่ หากคุณไม่มีจริงๆ และไม่เคยมีการสืบค้นช่วงวันที่ คุณไม่จำเป็นต้องใส่วันที่ในคีย์หลัก
โอเคขอบคุณมาก!
ที่มา: will.com