ในเดือนเมษายน วิศวกรของ Avito ได้รวมตัวกันเพื่อการประชุมออนไลน์กับนักพัฒนา ClickHouse หลัก Alexey Milovidov และ Kirill Shvakov นักพัฒนา Golang จาก Integros เราได้พูดคุยถึงวิธีที่เราใช้ระบบการจัดการฐานข้อมูล และปัญหาที่เราพบ
จากการประชุม เราได้รวบรวมบทความพร้อมคำตอบของผู้เชี่ยวชาญสำหรับคำถามของเราและผู้ชมเกี่ยวกับการสำรองข้อมูล การแบ่งข้อมูลใหม่ พจนานุกรมภายนอก ไดรเวอร์ Golang และการอัปเดตเวอร์ชัน ClickHouse อาจเป็นประโยชน์สำหรับนักพัฒนาที่ทำงานกับ Yandex DBMS อยู่แล้วและมีความสนใจในปัจจุบันและอนาคต ตามค่าเริ่มต้น คำตอบจะเป็นของ Alexey Milovidov เว้นแต่จะเขียนเป็นอย่างอื่น
ระวังมีข้อความอยู่ใต้การตัดเยอะมาก เราหวังว่าเนื้อหาที่มีคำถามจะช่วยคุณนำทางได้
Содержание
หากคุณไม่ต้องการอ่านข้อความ คุณสามารถดูบันทึกการชุมนุมได้ . รหัสเวลาอยู่ในความคิดเห็นแรกใต้วิดีโอ
ClickHouse มีการอัปเดตอยู่ตลอดเวลา แต่ข้อมูลของเราไม่ได้อัปเดต จะทำอย่างไรกับมัน?
ClickHouse ได้รับการอัปเดตอย่างต่อเนื่อง และข้อมูลของเราซึ่งได้รับการปรับให้เหมาะสมในการประมวลผลขั้นสุดท้าย จะไม่อัปเดตและอยู่ในสำเนาสำรอง
สมมติว่าเรามีปัญหาและข้อมูลสูญหาย เราตัดสินใจที่จะกู้คืนและปรากฎว่าพาร์ติชันเก่าซึ่งจัดเก็บไว้ในเซิร์ฟเวอร์สำรองนั้นแตกต่างจาก ClickHouse เวอร์ชันที่ใช้อยู่ในปัจจุบันมาก จะทำอย่างไรในสถานการณ์เช่นนี้และเป็นไปได้หรือไม่?
สถานการณ์ที่คุณกู้คืนข้อมูลจากข้อมูลสำรองในรูปแบบเก่า แต่ไม่ได้เชื่อมต่อกับเวอร์ชันใหม่นั้นเป็นไปไม่ได้ เราตรวจสอบให้แน่ใจว่ารูปแบบข้อมูลใน ClickHouse ยังคงเข้ากันได้แบบย้อนหลังเสมอ สิ่งนี้มีความสำคัญมากกว่าความเข้ากันได้แบบย้อนหลังในฟังก์ชันการทำงาน หากพฤติกรรมของฟังก์ชันบางฟังก์ชันที่ไม่ค่อยได้ใช้มีการเปลี่ยนแปลง ClickHouse เวอร์ชันใหม่ควรจะสามารถอ่านข้อมูลที่จัดเก็บไว้ในดิสก์ได้เสมอ นี่คือกฎหมาย
แนวทางปฏิบัติที่ดีที่สุดในการสำรองข้อมูลจาก ClickHouse คืออะไร?
จะสำรองข้อมูลได้อย่างไร โดยคำนึงถึงว่าเราเพิ่มประสิทธิภาพการดำเนินการขั้นสุดท้าย ฐานข้อมูลขนาดใหญ่เทราไบต์ และข้อมูลที่ได้รับการอัปเดตในช่วงสามวันที่ผ่านมา และไม่มีขั้นตอนใดเกิดขึ้น
เราสามารถสร้างโซลูชันของเราเองและเขียนลงใน bash: รวบรวมสำเนาสำรองเหล่านี้ในลักษณะดังกล่าว อาจจะไม่ต้องค้ำอะไรแล้วจักรยานก็ถูกประดิษฐ์ขึ้นมานานแล้วเหรอ?
เริ่มต้นด้วยแนวทางปฏิบัติที่ดีที่สุด เพื่อนร่วมงานของฉันให้คำแนะนำเสมอในการตอบคำถามเกี่ยวกับการสำรองข้อมูลเพื่อเตือนพวกเขาเกี่ยวกับบริการ Yandex.Cloud ซึ่งปัญหานี้ได้รับการแก้ไขแล้ว ดังนั้นใช้มันถ้าเป็นไปได้
ไม่มีโซลูชันที่สมบูรณ์สำหรับการสำรองข้อมูล เนื่องจากมี ClickHouse อยู่แล้วร้อยเปอร์เซ็นต์ มีช่องว่างบางส่วนที่สามารถใช้ได้ เพื่อให้ได้โซลูชันที่สมบูรณ์ คุณจะต้องปรับแต่งด้วยตนเองเล็กน้อย หรือสร้าง Wrapper ในรูปแบบของสคริปต์
ฉันจะเริ่มต้นด้วยโซลูชันที่ง่ายที่สุดและปิดท้ายด้วยโซลูชันที่ซับซ้อนที่สุด ขึ้นอยู่กับปริมาณข้อมูลและขนาดของคลัสเตอร์ ยิ่งคลัสเตอร์มีขนาดใหญ่เท่าใด โซลูชันก็จะยิ่งซับซ้อนมากขึ้นเท่านั้น
หากตารางที่มีข้อมูลใช้พื้นที่เพียงไม่กี่กิกะไบต์ การสำรองข้อมูลสามารถทำได้ดังนี้:
- บันทึกคำจำกัดความของตารางเช่นข้อมูลเมตา - แสดงการสร้างตาราง.
- สร้างการถ่ายโอนข้อมูลโดยใช้ไคลเอนต์ ClickHouse - เลือก * จากโต๊ะ เพื่อยื่น ตามค่าเริ่มต้น คุณจะได้รับไฟล์ในรูปแบบ TabSeparated หากคุณต้องการมีประสิทธิภาพมากขึ้น คุณสามารถทำได้ในรูปแบบเนทิฟ
หากปริมาณข้อมูลมากขึ้น การสำรองข้อมูลจะใช้เวลาและพื้นที่มากขึ้น สิ่งนี้เรียกว่าการสำรองข้อมูลแบบลอจิคัล ซึ่งไม่เชื่อมโยงกับรูปแบบข้อมูล ClickHouse หากเป็นเช่นนั้น เป็นวิธีสุดท้ายที่คุณสามารถสำรองข้อมูลและอัปโหลดไปยัง MySQL เพื่อการกู้คืนได้
สำหรับกรณีขั้นสูง ClickHouse มีความสามารถในตัวในการสร้างสแน็ปช็อตของพาร์ติชันในระบบไฟล์ในเครื่อง คุณลักษณะนี้มีให้ตามคำขอ แก้ไขพาร์ทิชันการตรึงตาราง. หรือเพียงแค่ แก้ไขการแช่แข็งตาราง - นี่คือภาพรวมของทั้งตาราง
สแน็ปช็อตจะถูกสร้างขึ้นอย่างสม่ำเสมอสำหรับตารางเดียวในส่วนแบ่งข้อมูลเดียว กล่าวคือ เป็นไปไม่ได้ที่จะสร้างสแน็ปช็อตที่สอดคล้องกันของทั้งคลัสเตอร์ด้วยวิธีนี้ แต่สำหรับงานส่วนใหญ่ไม่จำเป็นต้องเป็นเช่นนั้น และการดำเนินการตามคำขอในแต่ละส่วนและรับสแนปช็อตที่สอดคล้องกันก็เพียงพอแล้ว มันถูกสร้างขึ้นในรูปแบบของฮาร์ดลิงก์ดังนั้นจึงไม่ใช้พื้นที่เพิ่มเติม จากนั้น คุณคัดลอกสแน็ปช็อตนี้ไปยังเซิร์ฟเวอร์สำรองข้อมูลหรือพื้นที่จัดเก็บข้อมูลที่คุณใช้สำหรับการสำรองข้อมูล
การกู้คืนข้อมูลสำรองนั้นค่อนข้างง่าย ขั้นแรก สร้างตารางโดยใช้คำจำกัดความของตารางที่มีอยู่ จากนั้น คัดลอกสแน็ปช็อตที่บันทึกไว้ของพาร์ติชันไปยัง Directory-Detached สำหรับตารางเหล่านี้ และเรียกใช้แบบสอบถาม แนบพาร์ติชัน. โซลูชันนี้ค่อนข้างเหมาะสำหรับปริมาณข้อมูลที่มีปริมาณร้ายแรงที่สุด
บางครั้งคุณต้องการบางสิ่งที่เจ๋งกว่านั้น ในกรณีที่คุณมีเซิร์ฟเวอร์หลายสิบหรือหลายร้อยเทราไบต์และเซิร์ฟเวอร์หลายร้อยเครื่อง มีวิธีแก้ไขปัญหาที่ฉันรับมาจากเพื่อนร่วมงานจาก Yandex.Metrica ฉันจะไม่แนะนำให้ทุกคนอ่านและตัดสินใจด้วยตัวเองว่าเหมาะสมหรือไม่
ขั้นแรกคุณต้องสร้างเซิร์ฟเวอร์หลายเครื่องที่มีชั้นวางดิสก์ขนาดใหญ่ ถัดไป บนเซิร์ฟเวอร์เหล่านี้ ให้เพิ่มเซิร์ฟเวอร์ ClickHouse หลายเซิร์ฟเวอร์และกำหนดค่าเพื่อให้ทำงานเป็นแบบจำลองอื่นสำหรับชาร์ดเดียวกัน จากนั้นใช้ระบบไฟล์หรือเครื่องมือบางอย่างบนเซิร์ฟเวอร์เหล่านี้ที่ช่วยให้คุณสามารถสร้างสแน็ปช็อตได้ มีสองตัวเลือกที่นี่ ตัวเลือกแรกคือสแน็ปช็อต LVM ตัวเลือกที่สองคือ ZFS บน Linux
หลังจากนั้นทุกวันคุณจะต้องสร้างสแน็ปช็อต มันจะโกหกและใช้พื้นที่บางส่วน โดยปกติแล้ว หากข้อมูลเปลี่ยนแปลง ปริมาณพื้นที่จะเพิ่มขึ้นเมื่อเวลาผ่านไป สแน็ปช็อตนี้สามารถนำออกมาได้ตลอดเวลาและกู้คืนข้อมูลได้ นับเป็นวิธีแก้ปัญหาที่แปลกมาก นอกจากนี้ เรายังจำเป็นต้องจำกัดการจำลองเหล่านี้ในการกำหนดค่าด้วย เพื่อจะได้ไม่พยายามเป็นผู้นำ
เป็นไปได้ไหมที่จะจัดการความล่าช้าของแบบจำลองในเพลาที่ควบคุมได้?
ปีนี้คุณกำลังวางแผนที่จะสร้างเพลาใน ClickHouse เป็นไปได้ไหมที่จะจัดการความล่าช้าของการจำลองในนั้น? เราต้องการใช้มันเพื่อปกป้องตัวเราเองจากสถานการณ์เชิงลบที่มีการเปลี่ยนแปลงและการเปลี่ยนแปลงอื่นๆ
เป็นไปได้ไหมที่จะทำการย้อนกลับเพื่อแก้ไข? ตัวอย่างเช่น ในเพลาที่มีอยู่ ให้รับและพูดว่าจนถึงขณะนี้คุณใช้การเปลี่ยนแปลง และนับจากนี้คุณจะหยุดใช้การเปลี่ยนแปลง?
หากมีคำสั่งมาที่คลัสเตอร์ของเราและพัง แสดงว่าเรามีการจำลองแบบมีเงื่อนไขที่มีการหน่วงเวลาหนึ่งชั่วโมง ซึ่งเราสามารถพูดได้ว่ามาใช้งานในขณะนี้ แต่เราจะไม่นำการเปลี่ยนแปลงไปใช้กับมันในช่วงสิบนาทีที่ผ่านมา
ประการแรก เกี่ยวกับความล่าช้าในการควบคุมของเรพลิกา มีคำขอดังกล่าวจากผู้ใช้ และเราได้สร้างปัญหาบน Github พร้อมคำขอ: “หากใครต้องการสิ่งนี้ ให้ใส่ใจ” ไม่มีใครมาส่ง และปัญหาก็ปิดลงแล้ว อย่างไรก็ตาม คุณสามารถรับโอกาสนี้ได้โดยการตั้งค่า ClickHouse จริง เริ่มตั้งแต่เวอร์ชัน 20.3 เท่านั้น
ClickHouse ดำเนินการรวมข้อมูลในพื้นหลังอย่างต่อเนื่อง เมื่อการผสานเสร็จสมบูรณ์ ชุดข้อมูลบางชุดจะถูกแทนที่ด้วยชิ้นส่วนที่ใหญ่กว่า ในเวลาเดียวกัน ชิ้นส่วนของข้อมูลที่มีอยู่ก่อนหน้านี้จะยังคงอยู่ในดิสก์ต่อไปอีกระยะหนึ่ง
ประการแรก จะยังคงจัดเก็บต่อไปตราบเท่าที่มีการสืบค้นแบบเลือกใช้งาน เพื่อมอบการดำเนินการที่ไม่มีการบล็อก แบบสอบถามแบบเลือกสามารถอ่านได้ง่ายจากข้อความเก่าๆ
ประการที่สองยังมีกำหนดเวลา - ข้อมูลเก่าจะอยู่บนดิสก์เป็นเวลาแปดนาที แปดนาทีนี้สามารถปรับแต่งได้และกลายเป็นหนึ่งวันได้ด้วย ซึ่งจะทำให้พื้นที่ดิสก์ต้องเสียค่าใช้จ่าย: ขึ้นอยู่กับกระแสข้อมูล ปรากฎว่าในวันสุดท้ายข้อมูลจะไม่เพียงเพิ่มเป็นสองเท่าเท่านั้น แต่ยังอาจเพิ่มขึ้นถึงห้าเท่าด้วย แต่หากเกิดปัญหาร้ายแรง คุณสามารถหยุดเซิร์ฟเวอร์ ClickHouse และจัดการทุกอย่างได้
บัดนี้เกิดคำถามว่าสิ่งนี้จะป้องกันการเปลี่ยนแปลงได้อย่างไร ควรพิจารณาให้ลึกกว่านี้ เนื่องจากใน ClickHouse เวอร์ชันเก่า การเปลี่ยนแปลงนี้ทำงานในลักษณะที่สามารถเปลี่ยนชิ้นส่วนได้โดยตรง มีข้อมูลส่วนหนึ่งพร้อมไฟล์บางไฟล์ และเราทำ เช่น แก้ไขคอลัมน์ดรอป. จากนั้นคอลัมน์นี้จะถูกลบออกจากส่วนทั้งหมด
แต่ตั้งแต่เวอร์ชัน 20.3 เป็นต้นไป กลไกการเปลี่ยนแปลงก็เปลี่ยนไปโดยสิ้นเชิง และตอนนี้ชิ้นส่วนของข้อมูลก็ไม่เปลี่ยนรูปอยู่เสมอ พวกมันไม่เปลี่ยนแปลงเลย - การแก้ไขตอนนี้ทำงานในลักษณะเดียวกับการผสาน แทนที่จะเปลี่ยนชิ้นส่วนทันที เราสร้างชิ้นใหม่ขึ้นมา ในส่วนใหม่ ไฟล์ที่ไม่มีการเปลี่ยนแปลงจะกลายเป็นฮาร์ดลิงก์ และหากเราลบคอลัมน์ ไฟล์นั้นก็จะหายไปในส่วนใหม่ ชิ้นส่วนเก่าจะถูกลบโดยค่าเริ่มต้นหลังจากผ่านไปแปดนาที และคุณสามารถปรับแต่งการตั้งค่าที่กล่าวถึงข้างต้นได้ที่นี่
เช่นเดียวกับการเปลี่ยนแปลง เช่น การกลายพันธุ์ เมื่อคุณทำ แก้ไขลบ หรือ แก้ไขการอัปเดตมันไม่ได้เปลี่ยนชิ้นส่วน แต่สร้างชิ้นใหม่ แล้วลบอันเก่าทิ้งไป
จะเกิดอะไรขึ้นถ้าโครงสร้างตารางมีการเปลี่ยนแปลง?
จะคืนค่าข้อมูลสำรองที่สร้างด้วยรูปแบบเก่าได้อย่างไร? และคำถามที่สองเกี่ยวกับกรณีของสแน็ปช็อตและเครื่องมือระบบไฟล์ Btrfs ดีที่นี่แทนที่จะเป็น ZFS บน Linux LVM หรือไม่
ถ้าคุณทำ แนบพาร์ติชัน พาร์ติชันที่มีโครงสร้างต่างกัน ClickHouse จะบอกคุณว่าเป็นไปไม่ได้ นี่คือวิธีแก้ปัญหา ประการแรกคือการสร้างตารางชั่วคราวของประเภท MergeTree ด้วยโครงสร้างเก่า แนบข้อมูลที่นั่นโดยใช้การแนบ และสร้างแบบสอบถามแก้ไข จากนั้นคุณสามารถคัดลอกหรือถ่ายโอนข้อมูลนี้แล้วแนบอีกครั้ง หรือใช้คำขอ แก้ไขพาร์ติชั่นการย้ายตาราง.
คำถามที่สองคือ สามารถใช้ Btrfs ได้หรือไม่ ประการแรก หากคุณมี LVM สแน็ปช็อต LVM ก็เพียงพอแล้ว และระบบไฟล์สามารถเป็น ext4 ได้ก็ไม่สำคัญ ด้วย Btrts ทุกอย่างขึ้นอยู่กับประสบการณ์ของคุณในการใช้งาน นี่เป็นระบบไฟล์ที่สมบูรณ์ แต่ยังมีข้อสงสัยบางประการเกี่ยวกับว่าทุกอย่างจะได้ผลในทางปฏิบัติในสถานการณ์เฉพาะอย่างไร ฉันจะไม่แนะนำให้ใช้สิ่งนี้เว้นแต่คุณจะมี Btrfs ในการผลิต
แนวทางปฏิบัติที่ดีที่สุดในการแบ่งข้อมูลใหม่ในปัจจุบันมีอะไรบ้าง
ปัญหาการแบ่งส่วนใหม่มีความซับซ้อนและมีหลายแง่มุม มีคำตอบที่เป็นไปได้หลายประการที่นี่ คุณสามารถไปจากด้านหนึ่งแล้วพูดแบบนี้ - ClickHouse ไม่มีคุณสมบัติการแบ่งย่อยในตัว แต่ฉันเกรงว่าคำตอบนี้จะไม่เหมาะกับใครเลย ดังนั้นคุณสามารถไปจากอีกด้านหนึ่งแล้วบอกว่า ClickHouse มีหลายวิธีในการแบ่งข้อมูลใหม่
หากคลัสเตอร์ไม่มีพื้นที่เหลือหรือไม่สามารถจัดการโหลดได้ คุณจะต้องเพิ่มเซิร์ฟเวอร์ใหม่ แต่เซิร์ฟเวอร์เหล่านี้จะว่างเปล่าตามค่าเริ่มต้น ไม่มีข้อมูล และไม่มีการโหลด คุณต้องจัดเรียงข้อมูลใหม่เพื่อให้กระจายทั่วทั้งคลัสเตอร์ใหม่ที่ใหญ่ขึ้นเท่าๆ กัน
วิธีแรกที่สามารถทำได้คือการคัดลอกส่วนหนึ่งของพาร์ติชันไปยังเซิร์ฟเวอร์ใหม่โดยใช้คำขอ แก้ไขพาร์ติชันการดึงข้อมูลตาราง. ตัวอย่างเช่น คุณมีพาร์ติชั่นตามเดือน และคุณใช้เวลาเดือนแรกของปี 2017 และคัดลอกไปยังเซิร์ฟเวอร์ใหม่ จากนั้นคัดลอกเดือนที่สามไปยังเซิร์ฟเวอร์ใหม่อื่น ๆ และคุณทำเช่นนี้จนกว่ามันจะมากหรือน้อยเท่ากัน
การถ่ายโอนสามารถทำได้เฉพาะกับพาร์ติชันที่ไม่เปลี่ยนแปลงระหว่างการบันทึก สำหรับพาร์ติชั่นใหม่ การบันทึกจะต้องถูกปิดใช้งาน เนื่องจากการถ่ายโอนไม่ใช่แบบอะตอมมิก มิฉะนั้นคุณจะพบข้อมูลซ้ำหรือช่องว่าง อย่างไรก็ตาม วิธีนี้ใช้ได้จริงและได้ผลค่อนข้างดี พาร์ติชั่นบีบอัดสำเร็จรูปจะถูกส่งผ่านเครือข่าย นั่นคือข้อมูลจะไม่ถูกบีบอัดหรือเข้ารหัสใหม่
วิธีนี้มีข้อเสียเปรียบอยู่ข้อหนึ่ง และขึ้นอยู่กับรูปแบบการแบ่งส่วนข้อมูล ไม่ว่าคุณจะให้คำมั่นสัญญากับโครงการการแบ่งส่วนข้อมูลนี้หรือไม่ หรือคุณมีคีย์การแบ่งส่วนข้อมูลใด ในตัวอย่างของคุณสำหรับกรณีที่มีเมตริก คีย์การแบ่งส่วนคือแฮชของเส้นทาง เมื่อคุณเลือกตารางแบบกระจาย ตารางนั้นจะไปที่ชาร์ดทั้งหมดในคลัสเตอร์พร้อมกันและรับข้อมูลจากที่นั่น
ซึ่งหมายความว่าจริงๆ แล้วไม่สำคัญสำหรับคุณว่าข้อมูลใดจะไปอยู่ที่ส่วนข้อมูลใด สิ่งสำคัญคือข้อมูลในเส้นทางหนึ่งจบลงที่ชิ้นส่วนเดียว แต่ข้อมูลใดไม่สำคัญ ในกรณีนี้ การถ่ายโอนพาร์ติชันสำเร็จรูปนั้นสมบูรณ์แบบ เนื่องจากด้วยการสืบค้นแบบเลือก คุณจะได้รับข้อมูลที่สมบูรณ์ด้วย ไม่ว่าจะก่อนที่จะแบ่งพาร์ติชันใหม่หรือหลังจากนั้น รูปแบบก็ไม่สำคัญ
แต่มีบางกรณีที่มีความซับซ้อนมากขึ้น หากในระดับตรรกะของแอปพลิเคชัน คุณต้องอาศัยรูปแบบการแบ่งส่วนพิเศษ ซึ่งไคลเอ็นต์นี้ตั้งอยู่บนส่วนแบ่งดังกล่าว และสามารถส่งคำขอได้โดยตรงที่นั่น ไม่ใช่ไปยังตารางแบบกระจาย หรือคุณกำลังใช้ ClickHouse เวอร์ชันล่าสุดและได้เปิดใช้งานการตั้งค่านี้แล้ว เพิ่มประสิทธิภาพการข้ามส่วนที่ไม่ได้ใช้. ในกรณีนี้ ในระหว่างการสืบค้นแบบใช้เลือกข้อมูล นิพจน์ในส่วนที่จะถูกวิเคราะห์ และจะมีการคำนวณว่าส่วนย่อยใดที่จำเป็นต้องใช้ตามโครงร่างการแบ่งส่วน วิธีนี้ใช้งานได้โดยมีเงื่อนไขว่าข้อมูลจะถูกแบ่งพาร์ติชันตามรูปแบบการแบ่งส่วนนี้ทุกประการ หากคุณจัดเรียงใหม่ด้วยตนเอง การโต้ตอบอาจเปลี่ยนแปลงได้
นี่คือวิธีที่หนึ่ง และฉันกำลังรอคำตอบของคุณอยู่ว่าวิธีนี้จะเหมาะสมหรือไปกันต่อ
Vladimir Kolobaev หัวหน้าผู้ดูแลระบบของ Avito: Alexey วิธีที่คุณพูดถึงใช้ไม่ได้ผลดีนักเมื่อคุณต้องการกระจายภาระรวมถึงการอ่านด้วย เราสามารถนำพาร์ติชันที่เป็นรายเดือนและสามารถนำเดือนก่อนหน้าไปยังโหนดอื่นได้ แต่เมื่อได้รับคำขอสำหรับข้อมูลนี้ เราจะโหลดพาร์ติชันนั้นเท่านั้น แต่เราต้องการโหลดทั้งคลัสเตอร์ เพราะไม่เช่นนั้น โหลดการอ่านทั้งหมดจะถูกประมวลผลด้วยส่วนแบ่งข้อมูลสองส่วนในบางครั้ง
อเล็กเซย์ มิโลวิดอฟ: คำตอบที่นี่แปลก ใช่ มันแย่ แต่ก็อาจจะได้ผล ฉันจะอธิบายอย่างชัดเจนว่าอย่างไร การดูสถานการณ์โหลดที่อยู่เบื้องหลังข้อมูลของคุณเป็นสิ่งที่คุ้มค่า หากนี่คือการตรวจสอบข้อมูล เราก็แทบจะพูดได้เลยว่าคำขอส่วนใหญ่นั้นเป็นข้อมูลใหม่
คุณติดตั้งเซิร์ฟเวอร์ใหม่ ย้ายพาร์ติชันเก่า แต่ยังเปลี่ยนวิธีการบันทึกข้อมูลใหม่ด้วย และข้อมูลใหม่จะถูกกระจายไปทั่วคลัสเตอร์ ดังนั้น หลังจากผ่านไปเพียงห้านาที คำขอในช่วงห้านาทีสุดท้ายจะโหลดคลัสเตอร์เท่าๆ กัน หลังจากผ่านไปหนึ่งวัน คำขอเป็นเวลา XNUMX ชั่วโมงจะโหลดคลัสเตอร์เท่าๆ กัน และน่าเสียดายที่คำขอของเดือนก่อนหน้าจะไปที่ส่วนหนึ่งของเซิร์ฟเวอร์คลัสเตอร์เท่านั้น
แต่บ่อยครั้งที่คุณจะไม่ได้รับคำขอเฉพาะสำหรับเดือนกุมภาพันธ์ 2019 เป็นไปได้มากว่าหากคำขอส่งถึงปี 2019 คำขอเหล่านั้นจะเป็นตลอดทั้งปี 2019 เป็นระยะเวลานาน ไม่ใช่สำหรับช่วงเล็กๆ บ้าง และคำขอดังกล่าวจะสามารถโหลดคลัสเตอร์ได้เท่าๆ กัน แต่โดยทั่วไปแล้ว คำพูดของคุณถูกต้องอย่างยิ่งว่านี่เป็นโซลูชันเฉพาะกิจที่ไม่กระจายข้อมูลอย่างเท่าเทียมกันอย่างสมบูรณ์
ฉันมีอีกสองสามประเด็นที่จะตอบคำถาม หนึ่งในนั้นคือการออกแบบโครงร่างการแบ่งส่วนในตอนแรก เพื่อให้การแบ่งส่วนใหม่ทำให้เกิดความเจ็บปวดน้อยลง สิ่งนี้ไม่สามารถทำได้เสมอไป
ตัวอย่างเช่น คุณมีข้อมูลการตรวจสอบ การตรวจสอบข้อมูลมีการเติบโตด้วยเหตุผลสามประการ ประการแรกคือการสะสมข้อมูลทางประวัติศาสตร์ ประการที่สองคือการเติบโตของการเข้าชม และประการที่สามคือการเพิ่มจำนวนสิ่งต่าง ๆ ที่ต้องติดตาม มีไมโครเซอร์วิสและเมตริกใหม่ๆ ที่ต้องบันทึก
เป็นไปได้ว่าการเพิ่มขึ้นที่ใหญ่ที่สุดนั้นสัมพันธ์กับเหตุผลที่สาม - การใช้การตรวจสอบเพิ่มขึ้น และในกรณีนี้ มันคุ้มค่าที่จะดูลักษณะของการโหลด อะไรคือแบบสอบถามแบบใช้เลือกข้อมูลหลัก คำค้นหาแบบเลือกข้อมูลพื้นฐานมักจะอิงตามชุดย่อยของเมตริก
เช่น การใช้งาน CPU บนเซิร์ฟเวอร์บางเครื่องโดยบริการบางอย่าง ปรากฎว่ามีคีย์ย่อยบางส่วนที่คุณได้รับข้อมูลนี้ และการร้องขอข้อมูลนี้มักจะค่อนข้างง่ายและเสร็จสิ้นภายในสิบมิลลิวินาที ใช้สำหรับตรวจสอบบริการและแดชบอร์ด ฉันหวังว่าฉันจะเข้าใจสิ่งนี้ถูกต้อง
วลาดิมีร์ โคโลบาเยฟ: ความจริงก็คือเรามักจะดึงดูดข้อมูลในอดีต เนื่องจากเราเปรียบเทียบสถานการณ์ปัจจุบันกับข้อมูลในอดีตแบบเรียลไทม์ และเป็นสิ่งสำคัญสำหรับเราในการเข้าถึงข้อมูลจำนวนมากอย่างรวดเร็ว และ ClickHouse ก็ทำหน้าที่นี้ได้อย่างดีเยี่ยม
คุณพูดถูก เราพบคำขออ่านส่วนใหญ่ในวันสุดท้าย เช่นเดียวกับระบบการตรวจสอบอื่นๆ แต่ในขณะเดียวกัน ภาระของข้อมูลในอดีตก็ค่อนข้างใหญ่เช่นกัน โดยพื้นฐานแล้วมันมาจากระบบแจ้งเตือนที่ทำงานทุกๆ XNUMX วินาทีและบอกกับ ClickHouse ว่า “ขอข้อมูลในช่วงหกสัปดาห์ที่ผ่านมาให้ฉันหน่อย ตอนนี้ให้สร้างค่าเฉลี่ยเคลื่อนที่จากพวกมันขึ้นมา แล้วมาเปรียบเทียบมูลค่าปัจจุบันกับมูลค่าในอดีตกัน”
ฉันอยากจะบอกว่าสำหรับคำขอล่าสุดดังกล่าว เรามีตารางเล็กๆ อีกตารางหนึ่งซึ่งเราจัดเก็บข้อมูลเพียงสองวัน และคำขอหลักจะลอยเข้าไปอยู่ในนั้น เราส่งคำค้นหาเชิงประวัติขนาดใหญ่ไปยังตารางที่แบ่งข้อมูลขนาดใหญ่เท่านั้น
อเล็กเซย์ มิโลวิดอฟ: น่าเสียดายที่มันใช้ไม่ได้กับสถานการณ์ของคุณ แต่ฉันจะบอกคำอธิบายเกี่ยวกับรูปแบบการแบ่งส่วนที่ไม่ดีและซับซ้อนสองแบบที่ไม่จำเป็นต้องใช้ แต่แบบที่ใช้ในบริการของเพื่อนฉัน
มีคลัสเตอร์หลักที่มีเหตุการณ์ Yandex.Metrica เหตุการณ์คือการดูหน้าเว็บ การคลิก และการแปลง คำขอส่วนใหญ่ไปที่เว็บไซต์ใดเว็บไซต์หนึ่ง คุณเปิดบริการ Yandex.Metrica คุณมีเว็บไซต์ - avito.ru ไปที่รายงานและมีการร้องขอสำหรับเว็บไซต์ของคุณ
แต่มีคำขออื่นๆ ทั้งเชิงวิเคราะห์และระดับโลก ที่ทำโดยนักวิเคราะห์ภายใน ในกรณีที่ฉันทราบว่านักวิเคราะห์ภายในส่งคำขอเฉพาะบริการ Yandex เท่านั้น แต่ถึงกระนั้นแม้แต่บริการ Yandex ก็ยังมีส่วนแบ่งที่สำคัญของข้อมูลทั้งหมด คำขอเหล่านี้ไม่ใช่คำขอสำหรับตัวนับเฉพาะ แต่เพื่อการกรองที่กว้างขึ้น
จะจัดระเบียบข้อมูลในลักษณะที่ทุกอย่างทำงานอย่างมีประสิทธิภาพสำหรับตัวนับตัวเดียวและแบบสอบถามทั่วโลกได้อย่างไร ปัญหาอีกประการหนึ่งคือจำนวนคำขอใน ClickHouse สำหรับคลัสเตอร์ Metrics มีจำนวนหลายพันคำขอต่อวินาที ในเวลาเดียวกัน เซิร์ฟเวอร์ ClickHouse หนึ่งเครื่องไม่สามารถจัดการคำขอที่ไม่สำคัญได้ เช่น หลายพันคำขอต่อวินาที
ขนาดคลัสเตอร์คือเซิร์ฟเวอร์หกร้อยเครื่อง หากคุณเพียงดึงตารางแบบกระจายมาบนคลัสเตอร์นี้และส่งคำขอหลายพันคำขอไปที่นั่น จะยิ่งแย่ไปกว่าการส่งคำขอเหล่านั้นไปยังเซิร์ฟเวอร์เดียว ในทางกลับกัน ตัวเลือกในการกระจายข้อมูลเท่าๆ กันและเราดำเนินการร้องขอจากเซิร์ฟเวอร์ทั้งหมดจะถูกยกเลิกทันที
มีตัวเลือกที่มีเส้นทแยงมุมตรงกันข้าม ลองนึกภาพถ้าเราแบ่งข้อมูลข้ามไซต์ และคำขอสำหรับไซต์หนึ่งไปที่ส่วนแบ่งเดียว ขณะนี้คลัสเตอร์จะสามารถรองรับคำขอได้นับหมื่นคำขอต่อวินาที แต่คำขอใด ๆ ในส่วนแบ่งข้อมูลเดียวจะทำงานช้าเกินไป จะไม่ปรับขนาดในแง่ของปริมาณงานอีกต่อไป โดยเฉพาะอย่างยิ่งถ้านี่คือไซต์ avito.ru ฉันจะไม่เปิดเผยความลับถ้าฉันบอกว่า Avito เป็นหนึ่งในไซต์ที่มีผู้เข้าชมมากที่สุดใน RuNet และการแปรรูปมันให้เป็นชิ้นเดียวคงเป็นความบ้าคลั่ง
ดังนั้นรูปแบบการแบ่งส่วนจึงได้รับการออกแบบให้มีไหวพริบมากขึ้น คลัสเตอร์ทั้งหมดแบ่งออกเป็นคลัสเตอร์จำนวนหนึ่ง ซึ่งเราเรียกว่าเลเยอร์ แต่ละคลัสเตอร์ประกอบด้วยชิ้นส่วนตั้งแต่โหลถึงหลายโหล มีกลุ่มดังกล่าวทั้งหมดสามสิบเก้ากลุ่ม
ทั้งหมดนี้ปรับขนาดได้อย่างไร? จำนวนกระจุกไม่เปลี่ยนแปลง - เมื่อสองสามปีก่อนก็ยังคงเป็นเช่นนั้น แต่ภายในแต่ละส่วน เราจะค่อยๆ เพิ่มจำนวนชิ้นส่วนเมื่อเรารวบรวมข้อมูล และรูปแบบการแบ่งส่วนโดยรวมเป็นดังนี้: คลัสเตอร์เหล่านี้แบ่งออกเป็นเว็บไซต์ และเพื่อให้เข้าใจว่าเว็บไซต์ใดอยู่ในคลัสเตอร์ใด จึงมีการใช้ metabase ที่แยกต่างหากใน MySQL หนึ่งไซต์ - บนหนึ่งคลัสเตอร์ และภายในนั้น การแบ่งส่วนจะเกิดขึ้นตามรหัสผู้เยี่ยมชม
เมื่อบันทึก เราจะหารด้วยส่วนที่เหลือของการแบ่งรหัสผู้เยี่ยมชม แต่เมื่อเพิ่มส่วนใหม่ รูปแบบการแบ่งส่วนจะเปลี่ยนไป เราแบ่งต่อไป แต่ด้วยเศษที่เหลือของการหารด้วยหมายเลขอื่น ซึ่งหมายความว่ามีผู้เยี่ยมชมรายหนึ่งอยู่ในเซิร์ฟเวอร์หลายเครื่องแล้ว และคุณไม่สามารถพึ่งพาสิ่งนี้ได้ การดำเนินการนี้ทำเพื่อให้แน่ใจว่าข้อมูลได้รับการบีบอัดได้ดีขึ้นเท่านั้น และเมื่อส่งคำขอ เราจะไปที่ตารางแบบกระจาย ซึ่งจะดูคลัสเตอร์และเข้าถึงเซิร์ฟเวอร์หลายสิบเครื่อง นี่เป็นแผนการที่โง่เขลา
แต่เรื่องราวของฉันจะไม่สมบูรณ์ถ้าฉันไม่บอกว่าเราละทิ้งโครงการนี้ ในรูปแบบใหม่ เราได้เปลี่ยนแปลงทุกอย่างและคัดลอกข้อมูลทั้งหมดโดยใช้ Clickhouse-Copier
ในรูปแบบใหม่ ไซต์ทั้งหมดจะแบ่งออกเป็นสองประเภท - ใหญ่และเล็ก ฉันไม่รู้ว่าเกณฑ์ถูกเลือกอย่างไร แต่ผลลัพธ์ก็คือไซต์ขนาดใหญ่ถูกบันทึกไว้ในคลัสเตอร์เดียว โดยมีส่วนแบ่งข้อมูล 120 ส่วน โดยแต่ละแบบจำลองสามรายการ นั่นคือ เซิร์ฟเวอร์ 360 เครื่อง และรูปแบบการแบ่งส่วนนั้นทำให้คำขอใดๆ ถูกส่งไปยังส่วนย่อยทั้งหมดในคราวเดียว หากคุณเปิดหน้ารายงานใดๆ สำหรับ avito.ru ใน Yandex.Metrica คำขอจะไปที่เซิร์ฟเวอร์ 120 แห่ง มีไซต์ขนาดใหญ่เพียงไม่กี่แห่งใน RuNet และคำขอไม่ใช่หนึ่งพันต่อวินาที แต่ยังไม่ถึงร้อยอีกด้วย ทั้งหมดนี้ถูกเคี้ยวอย่างเงียบ ๆ ด้วยตารางแบบกระจาย ซึ่งแต่ละตารางจะประมวลผลด้วยเซิร์ฟเวอร์ 120 เครื่อง
และคลัสเตอร์ที่สองสำหรับไซต์ขนาดเล็ก ต่อไปนี้เป็นโครงร่างการแบ่งส่วนตามรหัสไซต์ และคำขอแต่ละรายการจะส่งไปยังส่วนย่อยเดียวเท่านั้น
ClickHouse มียูทิลิตี้เครื่องถ่ายเอกสาร clickhouse คุณช่วยบอกเราเกี่ยวกับเธอได้ไหม?
ฉันจะบอกทันทีว่าโซลูชันนี้ยุ่งยากกว่าและมีประสิทธิผลน้อยกว่า ข้อดีคือทำให้ข้อมูลเลอะเทอะตามรูปแบบที่คุณระบุ แต่ข้อเสียเปรียบของยูทิลิตี้นี้ก็คือ มันไม่ได้ทำการเปลี่ยนใหม่เลย โดยจะคัดลอกข้อมูลจากสคีมาคลัสเตอร์หนึ่งไปยังสคีมาคลัสเตอร์อื่น
ซึ่งหมายความว่าเพื่อให้ทำงานได้คุณต้องมีสองคลัสเตอร์ สามารถอยู่บนเซิร์ฟเวอร์เดียวกันได้ แต่ข้อมูลจะไม่ถูกย้ายทีละน้อย แต่จะถูกคัดลอก
ตัวอย่างเช่น มีเซิร์ฟเวอร์สี่เครื่อง ตอนนี้มีแปดเซิร์ฟเวอร์ คุณสร้างตารางแบบกระจายใหม่บนเซิร์ฟเวอร์ทั้งหมด ตารางท้องถิ่นใหม่และเรียกใช้เครื่องถ่ายเอกสารคลิกเฮาส์ โดยระบุรูปแบบการทำงานที่ควรอ่านจากที่นั่น ยอมรับรูปแบบการแบ่งส่วนใหม่และถ่ายโอนข้อมูลไปที่นั่น และบนเซิร์ฟเวอร์เก่า คุณจะต้องใช้พื้นที่เพิ่มขึ้นหนึ่งเท่าครึ่งจากที่มีอยู่ในปัจจุบัน เนื่องจากข้อมูลเก่าจะต้องคงอยู่บนเซิร์ฟเวอร์เหล่านั้น และข้อมูลเก่าครึ่งหนึ่งจะมาทับเซิร์ฟเวอร์เหล่านั้น หากคุณคิดล่วงหน้าว่าจำเป็นต้องแบ่งข้อมูลใหม่และมีพื้นที่ว่าง วิธีนี้ก็เหมาะสม
Clickhouse-copier ทำงานอย่างไรภายใน? โดยแบ่งงานทั้งหมดออกเป็นชุดงานสำหรับการประมวลผลพาร์ติชั่นหนึ่งของตารางหนึ่งบนชาร์ดเดียว งานทั้งหมดเหล่านี้สามารถดำเนินการแบบคู่ขนานได้ และเครื่องถ่ายเอกสารคลิกเฮาส์สามารถรันบนเครื่องที่แตกต่างกันได้ในหลาย ๆ อินสแตนซ์ แต่สิ่งที่ทำกับพาร์ติชันเดียวนั้นไม่มีอะไรมากไปกว่าการเลือกส่วนแทรก ข้อมูลจะถูกอ่าน คลายการบีบอัด แบ่งพาร์ติชันใหม่ จากนั้นบีบอัดอีกครั้ง เขียนที่ไหนสักแห่ง และจัดเรียงใหม่ นี่เป็นการตัดสินใจที่ยากขึ้น
คุณมีโครงการนำร่องที่เรียกว่าการแบ่งส่วนใหม่ อะไรกับเธอ?
ย้อนกลับไปในปี 2017 คุณมีโครงการนำร่องที่เรียกว่าการแบ่งส่วนใหม่ มีตัวเลือกใน ClickHouse ด้วย ตามที่ผมเข้าใจ มันก็ไม่ได้ถอดออก คุณบอกฉันได้ไหมว่าทำไมสิ่งนี้ถึงเกิดขึ้น? ดูเหมือนว่าจะมีความเกี่ยวข้องมาก
ปัญหาทั้งหมดก็คือหากจำเป็นต้องแบ่งข้อมูลใหม่ จำเป็นต้องมีการซิงโครไนซ์ที่ซับซ้อนมากเพื่อทำสิ่งนี้แบบอะตอมมิก เมื่อเราเริ่มดูว่าการซิงโครไนซ์ทำงานอย่างไร เห็นได้ชัดว่ามีปัญหาพื้นฐานเกิดขึ้น และปัญหาพื้นฐานเหล่านี้ไม่ได้เป็นเพียงทฤษฎีเท่านั้น แต่ยังเริ่มแสดงให้เห็นในทางปฏิบัติทันทีในรูปแบบของสิ่งที่สามารถอธิบายได้ง่าย ๆ - ไม่มีอะไรทำงาน
เป็นไปได้หรือไม่ที่จะรวมข้อมูลทั้งหมดเข้าด้วยกันก่อนที่จะย้ายไปยังดิสก์ที่ช้า?
คำถามเกี่ยวกับ TTL พร้อมตัวเลือกการย้ายไปยังดิสก์ที่ช้าในบริบทของการผสาน มีวิธีอื่นนอกเหนือจากผ่าน cron ที่จะรวมทุกส่วนเข้าด้วยกันก่อนที่จะย้ายไปยังดิสก์ที่ช้าลงหรือไม่?
คำตอบสำหรับคำถามคือ เป็นไปได้ที่จะติดชิ้นส่วนทั้งหมดเป็นชิ้นเดียวโดยอัตโนมัติก่อนที่จะถ่ายโอน - ไม่ ฉันไม่คิดว่านี่เป็นสิ่งที่จำเป็น คุณไม่จำเป็นต้องรวมทุกส่วนเข้าด้วยกัน แต่เพียงวางใจว่าส่วนเหล่านั้นจะถูกถ่ายโอนไปยังดิสก์ที่ช้าโดยอัตโนมัติ
เรามีเกณฑ์สองประการสำหรับกฎการโอน อันแรกคือแบบว่าเติมแล้ว หากระดับพื้นที่จัดเก็บปัจจุบันมีพื้นที่ว่างน้อยกว่าเปอร์เซ็นต์ที่กำหนด เราจะเลือกหนึ่งส่วนและย้ายไปยังพื้นที่จัดเก็บที่ช้ากว่า หรือค่อนข้างไม่ช้ากว่า แต่เป็นอันถัดไป - ตามที่คุณกำหนดค่า
เกณฑ์ที่สองคือขนาด เป็นเรื่องของการเคลื่อนย้ายชิ้นใหญ่ คุณสามารถปรับเกณฑ์ตามพื้นที่ว่างบนดิสก์แบบเร็วได้ และข้อมูลจะถูกถ่ายโอนโดยอัตโนมัติ
จะโยกย้ายไปยัง ClickHouse เวอร์ชันใหม่ได้อย่างไรหากไม่มีวิธีตรวจสอบความเข้ากันได้ล่วงหน้า
หัวข้อนี้มีการอภิปรายเป็นประจำ โดยคำนึงถึงเวอร์ชันต่างๆ และยังคง จะปลอดภัยแค่ไหนหากอัปเกรดจากเวอร์ชัน 19.11 เป็น 19.16 และเช่น จาก 19.16 เป็น 20.3 วิธีที่ดีที่สุดในการโยกย้ายไปยังเวอร์ชันใหม่โดยไม่สามารถตรวจสอบความเข้ากันได้ในแซนด์บ็อกซ์ล่วงหน้าคืออะไร
มีกฎ "ทอง" หลายประการที่นี่ อันดับแรก - . มีขนาดใหญ่ แต่มีย่อหน้าแยกต่างหากเกี่ยวกับการเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลัง อย่าถือว่าจุดเหล่านี้เป็นธงสีแดง โดยทั่วไปสิ่งเหล่านี้จะเข้ากันไม่ได้เล็กน้อยซึ่งเกี่ยวข้องกับฟังก์ชัน Edge บางอย่างที่คุณมีแนวโน้มว่าจะไม่ได้ใช้
ประการที่สอง หากไม่มีวิธีตรวจสอบความเข้ากันได้ในแซนด์บ็อกซ์ และคุณต้องการอัปเดตทันทีในการใช้งานจริง คำแนะนำก็คือ คุณไม่จำเป็นต้องทำเช่นนี้ ขั้นแรกให้สร้างแซนด์บ็อกซ์และทดสอบ หากไม่มีสภาพแวดล้อมการทดสอบ เป็นไปได้ว่าคุณไม่มีบริษัทขนาดใหญ่มาก ซึ่งหมายความว่าคุณสามารถคัดลอกข้อมูลบางส่วนไปยังแล็ปท็อปของคุณ และตรวจสอบให้แน่ใจว่าทุกอย่างทำงานได้อย่างถูกต้อง คุณยังสามารถเพิ่มแบบจำลองหลายรายการในเครื่องของคุณได้ หรือคุณสามารถรับเวอร์ชันใหม่ได้จากที่ไหนสักแห่งในบริเวณใกล้เคียงและอัปโหลดข้อมูลบางส่วนที่นั่น นั่นคือ สร้างสภาพแวดล้อมการทดสอบแบบด้นสด
กฎอีกข้อหนึ่งคือไม่ต้องอัปเดตเป็นเวลาหนึ่งสัปดาห์หลังจากการเปิดตัวเวอร์ชัน เนื่องจากตรวจพบจุดบกพร่องในการใช้งานจริงและการแก้ไขด่วนที่ตามมา เรามาดูหมายเลขเวอร์ชันของ ClickHouse กันดีกว่าเพื่อไม่ให้สับสน
มีเวอร์ชัน 20.3.4 หมายเลข 20 หมายถึงปีที่ผลิต - 2020 จากมุมมองของสิ่งที่อยู่ข้างในสิ่งนี้ไม่สำคัญดังนั้นเราจะไม่ใส่ใจกับมัน ถัดไป - 20.3 เราเพิ่มตัวเลขตัวที่สอง - ในกรณีนี้คือ 3 - ทุกครั้งที่เราเปิดตัวรุ่นที่มีฟังก์ชันใหม่บางอย่าง หากเราต้องการเพิ่มฟีเจอร์บางอย่างให้กับ ClickHouse เราต้องเพิ่มจำนวนนี้ นั่นคือในเวอร์ชัน 20.4 ClickHouse จะทำงานได้ดียิ่งขึ้น หลักที่สามคือ 20.3.4 4 คือจำนวนการเผยแพร่แพตช์ที่เราไม่ได้เพิ่มคุณสมบัติใหม่ แต่ได้แก้ไขข้อบกพร่องบางอย่างแล้ว และ 4 หมายถึงเราทำได้สี่ครั้ง.
อย่าคิดว่านี่เป็นสิ่งที่น่ากลัว โดยปกติแล้วผู้ใช้จะสามารถติดตั้งเวอร์ชันล่าสุดได้และจะทำงานได้โดยไม่มีปัญหาเรื่องสถานะการออนไลน์ต่อปี แต่ลองจินตนาการว่าในฟังก์ชันบางอย่างสำหรับการประมวลผลบิตแมปซึ่งสหายชาวจีนของเราเพิ่มเข้ามา เซิร์ฟเวอร์จะขัดข้องเมื่อส่งอาร์กิวเมนต์ที่ไม่ถูกต้อง เรามีความรับผิดชอบในการแก้ไขปัญหานี้ เราจะปล่อยเวอร์ชันแพทช์ใหม่และ ClickHouse จะมีความเสถียรมากขึ้น
หากคุณมี ClickHouse ที่ใช้งานจริง และ ClickHouse เวอร์ชันใหม่มาพร้อมกับคุณสมบัติเพิ่มเติม เช่น 20.4.1 เป็นเวอร์ชันแรก อย่ารีบเร่งที่จะนำมันไปใช้จริงในวันแรก เหตุใดจึงจำเป็น? หากคุณยังไม่ได้ใช้ ClickHouse คุณสามารถติดตั้งได้ และมีแนวโน้มว่าทุกอย่างจะเรียบร้อยดี แต่หาก ClickHouse ทำงานได้อย่างเสถียรอยู่แล้ว ให้จับตาดูแพตช์และการอัปเดตเพื่อดูว่าเรากำลังแก้ไขปัญหาใดบ้าง
คิริลล์ ชวาคอฟ: ฉันต้องการเพิ่มเล็กน้อยเกี่ยวกับสภาพแวดล้อมการทดสอบ ทุกคนกลัวสภาพแวดล้อมการทดสอบมากและด้วยเหตุผลบางอย่างพวกเขาเชื่อว่าหากคุณมีคลัสเตอร์ ClickHouse ขนาดใหญ่มาก สภาพแวดล้อมการทดสอบก็ควรจะเล็กลงไม่น้อยหรืออย่างน้อยสิบเท่า มันไม่ใช่แบบนั้นเลย
ฉันสามารถบอกคุณได้จากตัวอย่างของฉันเอง ฉันมีโครงการและมี ClickHouse สภาพแวดล้อมการทดสอบของเรามีไว้สำหรับเขาโดยเฉพาะ นี่คือเครื่องเสมือนขนาดเล็กใน Hetzner ในราคา XNUMX ยูโร ซึ่งทุกอย่างจะถูกปรับใช้อย่างแน่นอน ในการทำเช่นนี้ เรามีระบบอัตโนมัติเต็มรูปแบบใน Ansible ดังนั้นตามหลักการแล้ว มันไม่ต่างอะไรกับที่จะไปที่เซิร์ฟเวอร์ฮาร์ดแวร์หรือเพียงแค่ปรับใช้ในเครื่องเสมือน
สิ่งที่สามารถทำได้? เป็นการดีที่จะยกตัวอย่างในเอกสาร ClickHouse เกี่ยวกับวิธีการปรับใช้คลัสเตอร์ขนาดเล็กในบ้านของคุณเอง - ใน Docker ใน LXC อาจสร้าง Playbook Ansible เนื่องจากแต่ละคนมีการปรับใช้ที่แตกต่างกัน สิ่งนี้จะง่ายขึ้นมาก เมื่อคุณดำเนินการและปรับใช้คลัสเตอร์ภายในห้านาที การพยายามค้นหาบางสิ่งจะง่ายกว่ามาก วิธีนี้จะสะดวกกว่ามาก เนื่องจากการเข้าสู่เวอร์ชันที่ใช้งานจริงที่คุณยังไม่ได้ทดสอบนั้นเป็นหนทางที่ไม่มีทางเป็นไปได้ บางครั้งก็ได้ผลและบางครั้งก็ไม่ได้ ดังนั้นการหวังความสำเร็จจึงไม่ดี
Maxim Kotyakov วิศวกรแบ็กเอนด์อาวุโส Avito: ฉันจะเพิ่มเติมเล็กน้อยเกี่ยวกับสภาพแวดล้อมการทดสอบจากปัญหาต่างๆ ที่บริษัทขนาดใหญ่ต้องเผชิญ เรามีคลัสเตอร์การยอมรับ ClickHouse เต็มรูปแบบ ในแง่ของรูปแบบข้อมูลและการตั้งค่า มันเป็นสำเนาที่ตรงกันของสิ่งที่อยู่ในการใช้งานจริง คลัสเตอร์นี้ใช้งานในคอนเทนเนอร์ที่ค่อนข้างสมบูรณ์และมีทรัพยากรขั้นต่ำ เราเขียนข้อมูลการผลิตไว้เป็นเปอร์เซ็นต์ โชคดีที่สามารถจำลองสตรีมใน Kafka ได้ ทุกสิ่งในนั้นมีการซิงโครไนซ์และปรับขนาด - ทั้งในแง่ของความจุและการไหล และตามทฤษฎีแล้ว สิ่งอื่นๆ ทั้งหมดเท่าเทียมกัน ควรประพฤติตนเหมือนการผลิตในแง่ของหน่วยเมตริก ขั้นแรกทุกอย่างที่อาจเกิดการระเบิดได้จะถูกกลิ้งไปไว้บนแท่นนี้และปล่อยทิ้งไว้หลายวันจนกว่าจะพร้อม แต่โดยธรรมชาติแล้ว โซลูชันนี้มีราคาแพง ยาก และมีค่าใช้จ่ายการสนับสนุนที่ไม่เป็นศูนย์
อเล็กเซย์ มิโลวิดอฟ: ฉันจะบอกคุณว่าสภาพแวดล้อมการทดสอบของเพื่อนของเราจาก Yandex.Metrica เป็นอย่างไร คลัสเตอร์หนึ่งมีเซิร์ฟเวอร์ 600 คี่ อีกคลัสเตอร์มี 360 เซิร์ฟเวอร์ และมีคลัสเตอร์ที่สามและหลายคลัสเตอร์ สภาพแวดล้อมการทดสอบสำหรับหนึ่งในนั้นเป็นเพียงส่วนย่อยสองส่วนซึ่งมีแบบจำลองสองชุดในแต่ละส่วน ทำไมต้องมีสองชิ้น? เพื่อที่คุณจะได้ไม่ได้อยู่คนเดียว และควรมีการจำลองด้วย เพียงจำนวนเงินขั้นต่ำที่คุณสามารถจ่ายได้
สภาพแวดล้อมการทดสอบนี้ช่วยให้คุณตรวจสอบว่าการสืบค้นของคุณใช้งานได้หรือไม่ และมีสิ่งใดที่สำคัญเสียหายหรือไม่ แต่บ่อยครั้งที่ปัญหาเกิดขึ้นในลักษณะที่แตกต่างไปจากเดิมอย่างสิ้นเชิงเมื่อทุกอย่างทำงานได้ แต่มีการเปลี่ยนแปลงเล็กน้อยในการโหลด
ผมขอยกตัวอย่างให้คุณฟัง เราตัดสินใจติดตั้ง ClickHouse เวอร์ชันใหม่ มีการโพสต์ในสภาพแวดล้อมการทดสอบ การทดสอบอัตโนมัติได้เสร็จสิ้นแล้วใน Yandex.Metrica ซึ่งเปรียบเทียบข้อมูลในเวอร์ชันเก่าและเวอร์ชันใหม่โดยใช้ไปป์ไลน์ทั้งหมด และแน่นอนว่าการทดสอบสีเขียวของ CI ของเรา ไม่เช่นนั้นเราคงไม่เสนอเวอร์ชันนี้ด้วยซ้ำ
ทุกอย่างปกติดี. เรากำลังเริ่มเข้าสู่การผลิต ฉันได้รับข้อความว่าโหลดบนกราฟเพิ่มขึ้นหลายครั้ง เรากำลังย้อนกลับเวอร์ชัน ฉันดูกราฟและพบว่า จริงๆ แล้วภาระงานเพิ่มขึ้นหลายครั้งระหว่างการเปิดตัว และลดลงอีกครั้งเมื่อเปิดตัว จากนั้นเราก็เริ่มย้อนกลับเวอร์ชัน และภาระก็เพิ่มขึ้นตามเดิมและลดลงตามเดิม ดังนั้นข้อสรุปก็คือ: โหลดเพิ่มขึ้นเนื่องจากเลย์เอาต์ ไม่มีอะไรน่าแปลกใจ
จากนั้นเป็นการยากที่จะโน้มน้าวเพื่อนร่วมงานให้ติดตั้งเวอร์ชันใหม่ ฉันพูดว่า: “ไม่เป็นไร ลุยเลย หมั่นไส้ทุกอย่างจะสำเร็จ ตอนนี้ภาระบนกราฟเพิ่มขึ้น แต่ทุกอย่างเรียบร้อยดี อดทนหน่อย." โดยทั่วไปแล้วเราทำสิ่งนี้และก็แค่นั้นแหละ - เวอร์ชันนี้เปิดตัวเพื่อการผลิตแล้ว แต่เกือบทุกรูปแบบปัญหาที่คล้ายกันเกิดขึ้น
Kill query ควรจะฆ่าคำสั่ง แต่ไม่ใช่ ทำไม
ผู้ใช้ซึ่งเป็นนักวิเคราะห์บางประเภทมาหาฉันและสร้างคำขอที่ใส่คลัสเตอร์ ClickHouse ของฉัน บางโหนดหรือคลัสเตอร์ทั้งหมด ขึ้นอยู่กับแบบจำลองหรือส่วนย่อยที่คำขอส่งไป ฉันเห็นว่าทรัพยากร CPU ทั้งหมดบนเซิร์ฟเวอร์นี้อยู่ในชั้นวาง ทุกอย่างเป็นสีแดง ในเวลาเดียวกัน ClickHouse เองก็ตอบสนองต่อคำขอ และฉันเขียนว่า: "โปรดแสดงรายการกระบวนการ คำขอใดที่ทำให้เกิดความบ้าคลั่งนี้"
ฉันพบคำขอนี้และเขียนคำว่า kill ลงไป และฉันเห็นว่าไม่มีอะไรเกิดขึ้น เซิร์ฟเวอร์ของฉันอยู่ในชั้นวาง จากนั้น ClickHouse ก็ให้คำสั่งบางอย่างแก่ฉัน แสดงว่าเซิร์ฟเวอร์นั้นยังมีชีวิตอยู่ และทุกอย่างก็ยอดเยี่ยมมาก แต่ฉันมีการลดลงในคำขอของผู้ใช้ทั้งหมด การลดลงเริ่มต้นด้วยบันทึกใน ClickHouse และคำสั่งฆ่าของฉันไม่ทำงาน ทำไม ฉันคิดว่า kill query ควรจะฆ่าการค้นหา แต่มันก็ไม่ได้เป็นเช่นนั้น
ตอนนี้คงได้คำตอบที่ค่อนข้างแปลก ประเด็นก็คือว่า kill query ไม่ได้ฆ่าการค้นหา
Kill query จะทำเครื่องหมายในช่องเล็กๆ ที่เรียกว่า “ฉันต้องการให้คำสั่งนี้ถูกฆ่า” และคำขอจะดูแฟล็กนี้เมื่อประมวลผลแต่ละบล็อก หากมีการตั้งค่าไว้ คำขอจะหยุดทำงาน ปรากฎว่าไม่มีใครฆ่าคำขอได้ เขาเองต้องตรวจสอบทุกอย่างและหยุด และควรใช้งานได้ในทุกกรณีที่คำขออยู่ในสถานะกำลังประมวลผลบล็อคข้อมูล มันจะประมวลผลบล็อกข้อมูลถัดไป ตรวจสอบแฟล็ก และหยุด
สิ่งนี้ใช้ไม่ได้ในกรณีที่คำขอถูกบล็อกในการดำเนินการบางอย่าง จริงอยู่ เป็นไปได้มากว่านี่ไม่ใช่กรณีของคุณ เพราะตามที่คุณบอก มันใช้ทรัพยากรเซิร์ฟเวอร์มากมาย อาจเป็นไปได้ว่าวิธีนี้ใช้ไม่ได้ผลในกรณีของการเรียงลำดับภายนอกและในรายละเอียดอื่นๆ แต่โดยทั่วไปสิ่งนี้ไม่ควรเกิดขึ้น มันเป็นข้อบกพร่อง และสิ่งเดียวที่ฉันแนะนำได้คืออัปเดต ClickHouse
จะคำนวณเวลาตอบสนองภายใต้โหลดการอ่านได้อย่างไร
มีตารางที่เก็บรวมรายการ-ตัวนับต่างๆ จำนวนบรรทัดประมาณหนึ่งร้อยล้าน เป็นไปได้ไหมที่จะนับเวลาตอบสนองที่คาดการณ์ได้หากคุณเท 1K RPS สำหรับรายการ 1K
เมื่อพิจารณาจากบริบทเรากำลังพูดถึงปริมาณการอ่านเนื่องจากไม่มีปัญหาในการเขียน - แม้แต่พันหรือแสนและบางครั้งก็สามารถแทรกหลายล้านแถวได้
คำขออ่านแตกต่างกันมาก ในตัวเลือกที่ 1 ClickHouse สามารถดำเนินการคำขอได้ประมาณหมื่นคำขอต่อวินาที ดังนั้นแม้แต่คำขอสำหรับคีย์เดียวก็ต้องใช้ทรัพยากรบางส่วนอยู่แล้ว และการสืบค้นประเด็นดังกล่าวจะยากกว่าในฐานข้อมูลคีย์-ค่าบางฐานข้อมูล เนื่องจากสำหรับการอ่านแต่ละครั้งจำเป็นต้องอ่านบล็อกข้อมูลตามดัชนี ดัชนีของเราไม่ได้ระบุถึงแต่ละระเบียน แต่อยู่ที่แต่ละช่วง นั่นคือคุณจะต้องอ่านช่วงทั้งหมด - โดยค่าเริ่มต้นคือ 8192 บรรทัด และคุณจะต้องขยายขนาดบล็อกข้อมูลที่บีบอัดจาก 64 KB เป็น 1 MB โดยทั่วไปแล้ว การสืบค้นแบบกำหนดเป้าหมายดังกล่าวจะใช้เวลาสองสามมิลลิวินาทีในการดำเนินการให้เสร็จสิ้น แต่นี่เป็นตัวเลือกที่ง่ายที่สุด
เรามาลองเลขคณิตง่ายๆ กันดีกว่า หากคุณคูณสองสามมิลลิวินาทีด้วยหนึ่งพัน คุณจะได้ไม่กี่วินาที ราวกับว่าเป็นไปไม่ได้เลยที่จะตามทันคำขอนับพันคำขอต่อวินาที แต่ในความเป็นจริงแล้ว เป็นไปได้ เพราะเรามีคอร์โปรเซสเซอร์หลายคอร์ ตามหลักการแล้ว บางครั้ง ClickHouse สามารถถือครอง 1000 RPS ได้ แต่สำหรับคำขอสั้น ๆ จะเป็นคำขอที่กำหนดเป้าหมายโดยเฉพาะ
หากคุณต้องการปรับขนาดคลัสเตอร์ ClickHouse ตามจำนวนคำขอแบบง่าย ฉันขอแนะนำสิ่งที่ง่ายที่สุด - เพิ่มจำนวนแบบจำลองและส่งคำขอไปยังแบบจำลองแบบสุ่ม หากแบบจำลองหนึ่งรายการรองรับคำขอได้ห้าร้อยคำขอต่อวินาที ซึ่งเป็นไปตามความเป็นจริงอย่างยิ่ง แบบจำลองสามรายการจะรองรับหนึ่งและครึ่งพันคำขอ
บางครั้งคุณสามารถกำหนดค่า ClickHouse ให้ได้จำนวนการอ่านจุดสูงสุดได้ สิ่งที่จำเป็นสำหรับสิ่งนี้? ประการแรกคือการลดรายละเอียดของดัชนี ในกรณีนี้ ไม่ควรลดเหลือเพียงหนึ่งรายการ แต่บนพื้นฐานที่ว่าจำนวนรายการในดัชนีจะอยู่ที่หลายล้านหรือหลายสิบล้านต่อเซิร์ฟเวอร์ หากตารางมีหนึ่งร้อยล้านแถว คุณสามารถตั้งค่ารายละเอียดเป็น 64 ได้
คุณสามารถลดขนาดของบล็อกที่ถูกบีบอัดได้ มีการตั้งค่าสำหรับสิ่งนี้ ขนาดบล็อกบีบอัดขั้นต่ำ, ขนาดบล็อกการบีบอัดสูงสุด. พวกเขาสามารถลดลง เติมข้อมูล จากนั้นการสืบค้นที่ตรงเป้าหมายจะเร็วขึ้น แต่ถึงกระนั้น ClickHouse ก็ไม่ใช่ฐานข้อมูลคีย์-ค่า คำขอเล็กๆ จำนวนมากถือเป็นการต่อต้านรูปแบบการโหลด
คิริลล์ ชวาคอฟ: ฉันจะให้คำแนะนำในกรณีที่มีบัญชีธรรมดาที่นั่น นี่เป็นสถานการณ์ที่ค่อนข้างมาตรฐานเมื่อ ClickHouse เก็บเคาน์เตอร์บางประเภท ฉันมีผู้ใช้ เขามาจากประเทศดังกล่าว และช่องที่สาม และฉันต้องเพิ่มบางอย่างทีละน้อย ใช้ MySQL สร้างคีย์เฉพาะ - ใน MySQL เป็นคีย์ที่ซ้ำกัน และใน PostgreSQL เป็นคีย์ที่ขัดแย้งกัน - และเพิ่มเครื่องหมายบวก สิ่งนี้จะทำงานได้ดีขึ้นมาก
เมื่อคุณมีข้อมูลไม่มาก การใช้ ClickHouse ก็ไม่มีประโยชน์อะไร มีฐานข้อมูลปกติและทำได้ดี
ฉันสามารถปรับแต่งอะไรใน ClickHouse เพื่อให้มีข้อมูลอยู่ในแคชได้มากขึ้น
ลองจินตนาการถึงสถานการณ์ - เซิร์ฟเวอร์มี RAM 256 GB ในกิจวัตรประจำวัน ClickHouse ใช้เวลาประมาณ 60-80 GB ที่จุดสูงสุด - สูงสุด 130 สิ่งที่สามารถเปิดใช้งานและปรับแต่งเพื่อให้มีข้อมูลมากขึ้นในแคชและตามนั้น มีการเดินทางไปยังดิสก์น้อยลงหรือไม่
โดยทั่วไปแล้ว แคชเพจของระบบปฏิบัติการจะทำงานได้ดี หากคุณเพิ่งเปิดด้านบน ให้ดูแคชหรือว่าง - นอกจากนี้ยังระบุด้วยว่าแคชมีจำนวนเท่าใด - จากนั้นคุณจะสังเกตได้ว่าหน่วยความจำว่างทั้งหมดถูกใช้สำหรับแคช และเมื่ออ่านข้อมูลนี้จะไม่ได้อ่านจากดิสก์ แต่อ่านจาก RAM ในขณะเดียวกันก็บอกได้เลยว่าแคชถูกใช้อย่างมีประสิทธิภาพเพราะเป็นข้อมูลที่บีบอัดที่ถูกแคช
อย่างไรก็ตาม หากคุณต้องการเพิ่มความเร็วให้กับการสืบค้นง่ายๆ มากขึ้น คุณสามารถเปิดใช้งานแคชในข้อมูลที่คลายการบีบอัดภายใน ClickHouse ได้ มันถูกเรียกว่า แคชที่ไม่บีบอัด. ในไฟล์การกำหนดค่า config.xml ให้ตั้งค่าขนาดแคชที่ไม่บีบอัดเป็นค่าที่คุณต้องการ - ฉันขอแนะนำ RAM ที่ว่างไม่เกินครึ่งหนึ่งเนื่องจากส่วนที่เหลือจะอยู่ภายใต้แคชของหน้า
นอกจากนี้ยังมีการตั้งค่าระดับคำขอสองรายการ การตั้งค่าครั้งแรก - ใช้แคชที่ไม่บีบอัด - รวมถึงการใช้งานด้วย ขอแนะนำให้เปิดใช้งานสำหรับคำขอทั้งหมด ยกเว้นคำขอที่มีปริมาณมาก ซึ่งสามารถอ่านข้อมูลทั้งหมดและล้างแคชได้ และการตั้งค่าที่สองคือจำนวนบรรทัดสูงสุดที่จะใช้แคช โดยจะจำกัดการสืบค้นขนาดใหญ่โดยอัตโนมัติเพื่อให้สามารถข้ามแคชได้
ฉันจะกำหนดค่า storage_configuration สำหรับที่เก็บข้อมูลใน RAM ได้อย่างไร
ในเอกสาร ClickHouse ใหม่ ฉันอ่านส่วนที่เกี่ยวข้อง . คำอธิบายมีตัวอย่างด้วย SSD ที่รวดเร็ว
ฉันสงสัยว่าสิ่งเดียวกันสามารถกำหนดค่าด้วยหน่วยความจำร้อนปริมาณได้อย่างไร และอีกหนึ่งคำถาม Select ทำงานอย่างไรกับองค์กรข้อมูลนี้ จะอ่านทั้งชุดหรือเฉพาะชุดที่อยู่ในดิสก์ และข้อมูลนี้ถูกบีบอัดในหน่วยความจำหรือไม่ และส่วน prewhere ทำงานร่วมกับองค์กรข้อมูลดังกล่าวอย่างไร
การตั้งค่านี้ส่งผลต่อการจัดเก็บข้อมูล และรูปแบบของข้อมูลจะไม่เปลี่ยนแปลงแต่อย่างใด
มาดูกันดีกว่า
คุณสามารถกำหนดค่าการจัดเก็บข้อมูลใน RAM สิ่งที่ได้รับการกำหนดค่าสำหรับดิสก์คือเส้นทางของมัน คุณสร้างพาร์ติชัน tmpfs ที่ถูกเมาท์กับบางพาธในระบบไฟล์ คุณระบุเส้นทางนี้เป็นเส้นทางสำหรับการจัดเก็บข้อมูลสำหรับพาร์ติชันที่ร้อนแรงที่สุด ชิ้นส่วนของข้อมูลเริ่มมาถึงและเขียนที่นั่น ทุกอย่างเรียบร้อยดี
แต่ฉันไม่แนะนำให้ทำเช่นนี้เนื่องจากมีความน่าเชื่อถือต่ำ แม้ว่าคุณจะมีแบบจำลองอย่างน้อยสามตัวในศูนย์ข้อมูลที่แตกต่างกัน ก็สามารถทำได้ หากเกิดอะไรขึ้นข้อมูลจะถูกกู้คืน สมมติว่าเซิร์ฟเวอร์ถูกปิดและเปิดใหม่กะทันหัน พาร์ติชันถูกเมาท์อีกครั้ง แต่ไม่มีอะไรอยู่ตรงนั้น เมื่อเซิร์ฟเวอร์ ClickHouse เริ่มทำงาน จะเห็นว่าไม่มีชิ้นส่วนเหล่านี้ แม้ว่าตามข้อมูลเมตาของ ZooKeeper ก็ควรจะอยู่ที่นั่นก็ตาม เขาดูว่ามีแบบจำลองใดบ้าง ขอและดาวน์โหลด วิธีนี้ข้อมูลจะถูกกู้คืน
ในแง่นี้ การจัดเก็บข้อมูลใน RAM ไม่ได้แตกต่างโดยพื้นฐานจากการเก็บไว้ในดิสก์ เพราะเมื่อข้อมูลถูกเขียนลงดิสก์ ข้อมูลนั้นจะไปจบลงที่แคชของหน้าก่อนและจะถูกเขียนทางกายภาพในภายหลัง ขึ้นอยู่กับตัวเลือกการติดตั้งระบบไฟล์ แต่ในกรณีนี้ ฉันจะบอกว่า ClickHouse ไม่ fsync เมื่อทำการแทรก
ในกรณีนี้ ข้อมูลใน RAM จะถูกจัดเก็บในรูปแบบเดียวกับบนดิสก์ทุกประการ แบบสอบถามแบบใช้เลือกข้อมูลในลักษณะเดียวกันจะเลือกส่วนที่ต้องการอ่าน เลือกช่วงข้อมูลที่จำเป็นในส่วนต่างๆ และอ่าน และ prewhere ทำงานเหมือนกันทุกประการ ไม่ว่าข้อมูลจะอยู่ใน RAM หรือบนดิสก์ก็ตาม
Low Cardinality มีผลกับค่าที่ไม่ซ้ำกันสูงสุดกี่ค่า?
Low Cardinality ได้รับการออกแบบอย่างชาญฉลาด มันรวบรวมพจนานุกรมข้อมูล แต่เป็นพจนานุกรมในเครื่อง ประการแรก แต่ละเล่มมีพจนานุกรมที่แตกต่างกัน และประการที่สอง แม้จะอยู่ในเล่มเดียว ก็สามารถแตกต่างกันไปในแต่ละช่วงได้ เมื่อจำนวนค่าที่ไม่ซ้ำถึงเกณฑ์ - หนึ่งล้านฉันคิดว่า - พจนานุกรมจะถูกเก็บเข้าลิ้นชักและมีการสร้างพจนานุกรมใหม่
คำตอบคือโดยทั่วไป: สำหรับแต่ละช่วงท้องถิ่น - พูดในแต่ละวัน - ค่าที่ไม่ซ้ำกันมากถึงล้านค่าคาร์ดินาลิตีต่ำนั้นมีประสิทธิภาพ หลังจากนั้นจะมีการใช้พจนานุกรมต่างๆ มากมาย ไม่ใช่แค่พจนานุกรมเดียว มันจะทำงานโดยประมาณเหมือนกับคอลัมน์สตริงปกติ ซึ่งอาจมีประสิทธิภาพน้อยกว่าเล็กน้อย แต่จะไม่ลดประสิทธิภาพลงอย่างรุนแรง
แนวทางปฏิบัติที่ดีที่สุดสำหรับการค้นหาข้อความแบบเต็มในตารางที่มีห้าพันล้านแถวคืออะไร
มีคำตอบที่แตกต่างกัน ประการแรกคือการบอกว่า ClickHouse ไม่ใช่เครื่องมือค้นหาข้อความแบบเต็ม มีระบบพิเศษสำหรับสิ่งนี้เช่น и . อย่างไรก็ตาม ฉันเห็นผู้คนจำนวนมากขึ้นที่บอกว่าพวกเขาเปลี่ยนจาก Elasticsearch เป็น ClickHouse
ทำไมสิ่งนี้ถึงเกิดขึ้น? พวกเขาอธิบายสิ่งนี้โดยข้อเท็จจริงที่ว่า Elasticsearch หยุดรับมือกับโหลดในบางวอลุ่ม โดยเริ่มจากการสร้างดัชนี ดัชนียุ่งยากเกินไปและหากคุณเพียงแค่ถ่ายโอนข้อมูลไปยัง ClickHouse ปรากฎว่าพวกมันจะถูกจัดเก็บอย่างมีประสิทธิภาพมากขึ้นหลายเท่าในแง่ของปริมาณ ในเวลาเดียวกันคำค้นหามักจะไม่จำเป็นที่จะต้องค้นหาวลีบางวลีในปริมาณข้อมูลทั้งหมดโดยคำนึงถึงสัณฐานวิทยาของบัญชี แต่เป็นคำที่ต่างกันโดยสิ้นเชิง เช่น ค้นหาลำดับไบต์ในบันทึกในช่วง XNUMX-XNUMX ชั่วโมงที่ผ่านมา
ในกรณีนี้ คุณสร้างดัชนีใน ClickHouse โดยฟิลด์แรกจะเป็นวันที่และเวลา และการตัดข้อมูลที่ใหญ่ที่สุดจะขึ้นอยู่กับช่วงวันที่ ภายในช่วงวันที่ที่เลือก ตามกฎแล้ว เป็นไปได้ที่จะดำเนินการค้นหาข้อความแบบเต็มอยู่แล้ว แม้ว่าจะใช้วิธีการแบบเดรัจฉานบังคับโดยใช้ like ก็ตาม ตัวดำเนินการที่คล้ายกันใน ClickHouse เป็นตัวดำเนินการที่มีประสิทธิภาพมากที่สุดที่คุณสามารถหาได้ หากคุณพบสิ่งที่ดีกว่าบอกฉัน
แต่ก็ยังเหมือนเป็นการสแกนแบบเต็ม และการสแกนแบบเต็มอาจช้าไม่เพียงแต่บน CPU เท่านั้น แต่ยังรวมถึงบนดิสก์ด้วย หากจู่ๆ คุณมีข้อมูลหนึ่งเทราไบต์ต่อวัน และคุณค้นหาคำในระหว่างวัน คุณจะต้องสแกนเทราไบต์ และอาจอยู่ในฮาร์ดไดรฟ์ทั่วไปและท้ายที่สุดแล้วพวกเขาจะถูกโหลดในลักษณะที่คุณไม่สามารถเข้าถึงเซิร์ฟเวอร์นี้ผ่าน SSH ได้
ในกรณีนี้ผมพร้อมเสนอเคล็ดลับเล็กๆ น้อยๆ อีกข้อหนึ่งแล้ว เป็นเพียงการทดลอง - อาจได้ผล แต่อาจไม่ได้ผล ClickHouse มีดัชนีข้อความแบบเต็มในรูปแบบของตัวกรอง trigram Bloom เพื่อนร่วมงานของเราที่ Arenadata ได้ลองใช้ดัชนีเหล่านี้แล้ว และมักจะทำงานได้ตรงตามที่ต้องการ
เพื่อที่จะใช้อย่างถูกต้อง คุณควรมีความเข้าใจเป็นอย่างดีเกี่ยวกับวิธีการทำงานของตัวกรอง: ตัวกรอง trigram Bloom คืออะไร และวิธีการเลือกขนาดของตัวกรอง ฉันสามารถพูดได้ว่าพวกเขาจะช่วยค้นหาวลีที่หายาก สตริงย่อยที่ไม่ค่อยพบในข้อมูล ในกรณีนี้ ช่วงย่อยจะถูกเลือกตามดัชนีและจะอ่านข้อมูลน้อยลง
ล่าสุด ClickHouse ได้เพิ่มฟังก์ชันขั้นสูงเพิ่มเติมสำหรับการค้นหาข้อความแบบเต็ม ประการแรกคือการค้นหาสตริงย่อยจำนวนมากพร้อมกันในการผ่านครั้งเดียว รวมถึงตัวเลือกที่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ โดยรองรับ UTF-8 หรือสำหรับ ASCII เท่านั้น เลือกอันที่มีประสิทธิภาพที่สุดที่คุณต้องการ
ค้นหานิพจน์ทั่วไปหลายรายการในการผ่านครั้งเดียวก็ปรากฏขึ้นเช่นกัน คุณไม่จำเป็นต้องเขียน X เหมือนสตริงย่อยหนึ่งหรือ X เหมือนสตริงย่อยอื่น คุณเขียนทันทีและทุกอย่างก็ทำได้อย่างมีประสิทธิภาพมากที่สุด
ประการที่สาม ขณะนี้มีการค้นหา regexps โดยประมาณและการค้นหาสตริงย่อยโดยประมาณ หากใครสะกดคำผิดจะถูกค้นหาให้ตรงกันสูงสุด
วิธีที่ดีที่สุดในการจัดการการเข้าถึง ClickHouse สำหรับผู้ใช้จำนวนมากคืออะไร?
บอกเราถึงวิธีที่ดีที่สุดในการจัดการการเข้าถึงสำหรับผู้บริโภคและนักวิเคราะห์จำนวนมาก วิธีสร้างคิว จัดลำดับความสำคัญของการสืบค้นพร้อมกันสูงสุด และด้วยเครื่องมืออะไร
หากคลัสเตอร์มีขนาดใหญ่เพียงพอ ทางออกที่ดีก็คือการเพิ่มเซิร์ฟเวอร์อีกสองเซิร์ฟเวอร์ ซึ่งจะกลายเป็นจุดเริ่มต้นสำหรับนักวิเคราะห์ นั่นคือไม่อนุญาตให้นักวิเคราะห์เข้าถึงส่วนเฉพาะในคลัสเตอร์ แต่เพียงสร้างเซิร์ฟเวอร์ว่างสองเซิร์ฟเวอร์โดยไม่มีข้อมูล และกำหนดค่าสิทธิ์การเข้าถึงบนเซิร์ฟเวอร์เหล่านั้น ในกรณีนี้ การตั้งค่าผู้ใช้สำหรับคำขอแบบกระจายจะถูกโอนไปยังเซิร์ฟเวอร์ระยะไกล นั่นคือคุณกำหนดค่าทุกอย่างบนเซิร์ฟเวอร์ทั้งสองนี้ และการตั้งค่าจะมีผลกับทั้งคลัสเตอร์
โดยหลักการแล้ว เซิร์ฟเวอร์เหล่านี้ไม่มีข้อมูล แต่จำนวน RAM ในเซิร์ฟเวอร์เหล่านี้มีความสำคัญมากในการดำเนินการตามคำขอ ดิสก์ยังสามารถใช้สำหรับข้อมูลชั่วคราวได้หากเปิดใช้งานการรวมภายนอกหรือการเรียงลำดับภายนอก
สิ่งสำคัญคือต้องดูการตั้งค่าที่เกี่ยวข้องกับขีดจำกัดที่เป็นไปได้ทั้งหมด หากตอนนี้ฉันไปที่คลัสเตอร์ Yandex.Metrica ในฐานะนักวิเคราะห์และถามคำขอ เลือกนับจากการเข้าชมจากนั้นฉันจะได้รับข้อยกเว้นทันทีว่าฉันไม่สามารถดำเนินการตามคำขอได้ จำนวนแถวสูงสุดที่ฉันได้รับอนุญาตให้สแกนคือหนึ่งแสนล้านแถว และทั้งหมดมีห้าสิบล้านล้านแถวในหนึ่งตารางบนคลัสเตอร์ นี่เป็นข้อจำกัดประการแรก
สมมติว่าฉันลบขีดจำกัดแถวแล้วเรียกใช้แบบสอบถามอีกครั้ง จากนั้นฉันจะเห็นข้อยกเว้นต่อไปนี้ - เปิดใช้งานการตั้งค่าแล้ว ดัชนีแรงตามวันที่. ฉันไม่สามารถตอบคำถามได้หากไม่ได้ระบุช่วงวันที่ คุณไม่จำเป็นต้องพึ่งพานักวิเคราะห์เพื่อระบุข้อมูลด้วยตนเอง กรณีทั่วไปคือเมื่อมีการเขียนช่วงวันที่โดยวันที่ของเหตุการณ์ระหว่างสัปดาห์ จากนั้นพวกเขาก็ระบุวงเล็บในตำแหน่งที่ไม่ถูกต้อง แต่กลับกลายเป็นว่าหรือ - หรือ URL ตรงกัน หากไม่มีขีดจำกัด ระบบจะรวบรวมข้อมูลคอลัมน์ URL และเปลืองทรัพยากรจำนวนมาก
นอกจากนี้ ClickHouse ยังมีการตั้งค่าลำดับความสำคัญสองประการ น่าเสียดายที่พวกมันยังดั้งเดิมมาก หนึ่งเรียกง่ายๆว่า ลำดับความสำคัญ. หากลำดับความสำคัญ ≠ 0 และคำขอที่มีลำดับความสำคัญบางอย่างกำลังถูกดำเนินการ แต่คำขอที่มีค่าลำดับความสำคัญน้อยกว่าซึ่งหมายถึงลำดับความสำคัญที่สูงกว่ากำลังถูกดำเนินการ ดังนั้นคำขอที่มีค่าลำดับความสำคัญมากกว่า ซึ่งหมายถึงลำดับความสำคัญที่ต่ำกว่า ถูกระงับชั่วคราวและจะไม่ทำงานเลยในช่วงเวลานี้
นี่เป็นการตั้งค่าที่หยาบมาก และไม่เหมาะสำหรับกรณีที่คลัสเตอร์มีภาระคงที่ แต่หากคุณมีคำขอที่ส่งต่อเนื่องสั้นๆ ซึ่งสำคัญ และคลัสเตอร์ส่วนใหญ่ไม่ได้ใช้งาน การตั้งค่านี้เหมาะสม
เรียกว่าการตั้งค่าลำดับความสำคัญถัดไป ลำดับความสำคัญของเธรด OS. เพียงตั้งค่า nice สำหรับเธรดการดำเนินการร้องขอทั้งหมดสำหรับตัวกำหนดตารางเวลา Linux มันใช้งานได้ดี แต่ก็ยังใช้งานได้ หากคุณตั้งค่า nice ขั้นต่ำ ซึ่งเป็นค่าที่ใหญ่ที่สุดและเป็นลำดับความสำคัญต่ำสุด และตั้งค่า -19 สำหรับคำขอที่มีลำดับความสำคัญสูง CPU จะใช้คำขอที่มีลำดับความสำคัญต่ำน้อยกว่าคำขอที่มีลำดับความสำคัญสูงประมาณสี่เท่า
คุณต้องกำหนดค่าเวลาดำเนินการคำขอสูงสุด เช่น ห้านาที ความเร็วขั้นต่ำของการดำเนินการค้นหาเป็นสิ่งที่ยอดเยี่ยมที่สุด การตั้งค่านี้มีมานานแล้ว และไม่เพียงแต่ต้องยืนยันว่า ClickHouse ไม่ได้ทำให้ช้าลงเท่านั้น แต่ยังต้องบังคับอีกด้วย
ลองนึกภาพ คุณกำหนดค่า: ถ้าบางแบบสอบถามประมวลผลน้อยกว่าหนึ่งล้านแถวต่อวินาที คุณจะไม่สามารถทำเช่นนั้นได้ สิ่งนี้ทำให้ชื่อเสียงที่ดีของเราเสื่อมเสีย ฐานข้อมูลที่ดีของเรา เรามาห้ามกันแค่นี้ จริงๆ แล้วมีการตั้งค่าสองแบบ หนึ่งเรียกว่า ความเร็วการดำเนินการขั้นต่ำ - เป็นบรรทัดต่อวินาที และวินาทีเรียกว่าหมดเวลาก่อนตรวจสอบความเร็วการดำเนินการขั้นต่ำ - โดยค่าเริ่มต้น XNUMX วินาที นั่นคือเป็นไปได้สิบห้าวินาที จากนั้นหากช้า ให้ส่งข้อยกเว้นและยกเลิกการร้องขอ
คุณต้องตั้งค่าโควต้าด้วย ClickHouse มีฟีเจอร์โควต้าในตัวที่นับการใช้ทรัพยากร แต่น่าเสียดายที่ไม่ใช่ทรัพยากรฮาร์ดแวร์เช่น CPU ดิสก์ แต่เป็นทรัพยากรเชิงตรรกะ - จำนวนคำขอที่ประมวลผล บรรทัดและไบต์ที่อ่าน และคุณสามารถกำหนดค่าได้ เช่น สูงสุดหนึ่งร้อยคำขอภายในห้านาที และหนึ่งพันคำขอต่อชั่วโมง
ทำไมมันถึงสำคัญ? เนื่องจากแบบสอบถามการวิเคราะห์บางอย่างจะดำเนินการด้วยตนเองโดยตรงจากไคลเอนต์ ClickHouse และทุกอย่างจะดี แต่หากคุณมีนักวิเคราะห์ขั้นสูงในบริษัทของคุณ พวกเขาจะเขียนสคริปต์และอาจมีข้อผิดพลาดในสคริปต์ และข้อผิดพลาดนี้จะทำให้คำขอถูกดำเนินการในวงวนไม่สิ้นสุด นี่คือสิ่งที่เราต้องป้องกันตัวเองจาก
เป็นไปได้ไหมที่จะให้ผลลัพธ์ของหนึ่งแบบสอบถามกับลูกค้าสิบราย?
เรามีผู้ใช้หลายรายที่ต้องการส่งคำขอจำนวนมากในเวลาเดียวกัน คำขอมีขนาดใหญ่และโดยหลักการแล้วดำเนินการอย่างรวดเร็ว แต่เนื่องจากมีคำขอดังกล่าวจำนวนมากในเวลาเดียวกัน จึงเป็นเรื่องที่เจ็บปวดมาก เป็นไปได้ไหมที่จะดำเนินการตามคำขอเดียวกันซึ่งมาถึงสิบครั้งติดต่อกันหนึ่งครั้งและให้ผลลัพธ์แก่ลูกค้าสิบราย?
ปัญหาคือเราไม่มีผลลัพธ์ของแคชหรือแคชของข้อมูลระดับกลาง มีแคชเพจของระบบปฏิบัติการซึ่งจะป้องกันไม่ให้คุณอ่านข้อมูลจากดิสก์อีกครั้ง แต่น่าเสียดายที่ข้อมูลจะยังคงถูกคลายการบีบอัด ดีซีเรียลไลซ์ และประมวลผลใหม่
ฉันต้องการหลีกเลี่ยงสิ่งนี้ ไม่ว่าจะโดยการแคชข้อมูลระดับกลาง หรือโดยการเรียงคิวรีที่คล้ายกันในคิวบางประเภทและเพิ่มแคชผลลัพธ์ ขณะนี้เรามีคำขอดึงหนึ่งรายการในการพัฒนาที่เพิ่มแคชคำขอ แต่สำหรับแบบสอบถามย่อยในส่วนเข้าและรวมเท่านั้น กล่าวคือ โซลูชันไม่สมบูรณ์
อย่างไรก็ตาม เราก็เผชิญกับสถานการณ์เช่นนี้เช่นกัน ตัวอย่างที่เป็นที่ยอมรับโดยเฉพาะคือการสืบค้นแบบแบ่งหน้า มีรายงานมีหลายหน้าและมีขอจำกัด 10 แล้วอันเดียวกันแต่จำกัด 10,10 แล้วหน้าต่อไปอีก และคำถามก็คือ ทำไมเราถึงนับทั้งหมดนี้ทุกครั้ง? แต่ตอนนี้ไม่มีวิธีแก้ไขและไม่มีทางหลีกเลี่ยงได้
มีทางเลือกอื่นที่วางไว้เป็นรถเทียมข้างรถจักรยานยนต์ข้าง ClickHouse - .
คิริลล์ ชวาคอฟ: ClickHouse Proxy มีตัวจำกัดอัตราในตัวและแคชผลลัพธ์ในตัว มีการตั้งค่าจำนวนมากที่นั่นเนื่องจากปัญหาที่คล้ายกันกำลังได้รับการแก้ไข พร็อกซีช่วยให้คุณสามารถจำกัดคำขอโดยการจัดคิวและกำหนดค่าระยะเวลาที่แคชคำขอใช้งานได้ หากคำขอเหมือนกันจริงๆ Proxy จะส่งหลายครั้ง แต่จะไปที่ ClickHouse เพียงครั้งเดียว
Nginx มีแคชในเวอร์ชันฟรีด้วย และสิ่งนี้จะใช้งานได้เช่นกัน Nginx ยังมีการตั้งค่าที่หากคำขอมาถึงในเวลาเดียวกัน คำขออื่นๆ จะทำให้คำขออื่นๆ ช้าลงจนกว่าจะเสร็จสิ้น แต่ใน ClickHouse Proxy การตั้งค่าทำได้ดีกว่ามาก จัดทำขึ้นเพื่อ ClickHouse โดยเฉพาะ เพื่อคำขอเหล่านี้โดยเฉพาะ ดังนั้นจึงเหมาะสมกว่า มันติดตั้งง่าย
แล้วการดำเนินการแบบอะซิงโครนัสและมุมมองที่เป็นรูปธรรมล่ะ?
มีปัญหาที่การดำเนินการกับเอ็นจิ้นการเล่นซ้ำเป็นแบบอะซิงโครนัส - อันดับแรกข้อมูลจะถูกเขียน จากนั้นจึงยุบลง หากแท็บเล็ตที่เป็นรูปธรรมซึ่งมีมวลรวมบางส่วนอยู่ใต้เครื่องหมาย จะมีการเขียนรายการที่ซ้ำกันลงไป และหากไม่มีตรรกะที่ซับซ้อน ข้อมูลก็จะถูกทำซ้ำ คุณสามารถทำอะไรเกี่ยวกับเรื่องนี้?
มีวิธีแก้ไขที่ชัดเจน - เพื่อใช้ทริกเกอร์กับคลาสของ matviews บางคลาสระหว่างการดำเนินการยุบแบบอะซิงโครนัส มีกระสุนเงินหรือแผนที่จะใช้ฟังก์ชันที่คล้ายกันหรือไม่?
การทำความเข้าใจวิธีการทำงานของการขจัดข้อมูลซ้ำซ้อนเป็นสิ่งที่คุ้มค่า สิ่งที่ฉันจะบอกตอนนี้ไม่เกี่ยวข้องกับคำถาม แต่ในกรณีที่ควรค่าแก่การจดจำ
เมื่อแทรกลงในตารางที่จำลองแบบ จะมีการขจัดความซ้ำซ้อนของบล็อกที่แทรกทั้งหมด หากคุณแทรกบล็อกเดียวกันซึ่งมีหมายเลขเดียวกันของแถวเดียวกันในลำดับเดียวกัน ข้อมูลจะถูกกรองข้อมูลซ้ำออก คุณจะได้รับข้อความว่า "ตกลง" เพื่อตอบกลับการแทรก แต่อันที่จริงข้อมูลหนึ่งแพ็คเก็ตจะถูกเขียน และจะไม่ถูกทำซ้ำ
นี่เป็นสิ่งจำเป็นเพื่อความแน่นอน หากคุณได้รับข้อความ "ตกลง" ระหว่างการแทรก แสดงว่าข้อมูลของคุณถูกแทรกแล้ว หากคุณได้รับข้อผิดพลาดจาก ClickHouse แสดงว่าไม่ได้แทรกไว้ และคุณจำเป็นต้องทำการแทรกซ้ำ แต่หากการเชื่อมต่อขาดระหว่างการแทรก คุณจะไม่รู้ว่าข้อมูลถูกแทรกหรือไม่ ทางเลือกเดียวคือการแทรกซ้ำอีกครั้ง หากข้อมูลถูกแทรกจริง ๆ และคุณแทรกกลับเข้าไปใหม่ จะมีการบล็อกการขจัดข้อมูลซ้ำซ้อน นี่เป็นสิ่งจำเป็นเพื่อหลีกเลี่ยงการซ้ำซ้อน
และสิ่งสำคัญคือวิธีการทำงานสำหรับมุมมองที่เป็นรูปธรรม หากข้อมูลถูกขจัดข้อมูลซ้ำซ้อนเมื่อแทรกลงในตารางหลัก ข้อมูลนั้นจะไม่เข้าสู่มุมมองที่เป็นรูปธรรมเช่นกัน
ตอนนี้เกี่ยวกับคำถาม สถานการณ์ของคุณซับซ้อนมากขึ้นเนื่องจากคุณกำลังบันทึกรายการซ้ำของแต่ละบรรทัด นั่นคือไม่ใช่การทำซ้ำทั้งแพ็ค แต่เป็นบรรทัดเฉพาะและจะยุบลงในพื้นหลัง อันที่จริง ข้อมูลจะยุบลงในตารางหลัก แต่ข้อมูลที่ไม่ถูกยุบจะไปที่มุมมองที่เป็นรูปธรรม และในระหว่างการรวมจะไม่มีอะไรเกิดขึ้นกับมุมมองที่เป็นรูปธรรม เนื่องจากมุมมองที่เป็นรูปธรรมนั้นไม่มีอะไรมากไปกว่าทริกเกอร์การแทรก ในระหว่างการดำเนินการอื่นๆ จะไม่มีอะไรเกิดขึ้นเพิ่มเติม
และฉันไม่สามารถทำให้คุณมีความสุขที่นี่ได้ คุณเพียงแค่ต้องค้นหาวิธีแก้ปัญหาเฉพาะสำหรับกรณีนี้ ตัวอย่างเช่น เป็นไปได้ไหมที่จะเล่นซ้ำในมุมมองที่เป็นรูปธรรม และวิธีการขจัดข้อมูลซ้ำซ้อนอาจทำงานในลักษณะเดียวกัน แต่น่าเสียดายที่ไม่เสมอไป ถ้ามันรวมตัวกันมันจะไม่ทำงาน
คิริลล์ ชวาคอฟ: เรายังมีการก่อสร้างไม้ค้ำยันในสมัยนั้นด้วย มีปัญหาเกี่ยวกับการแสดงผลโฆษณา และมีข้อมูลบางอย่างที่เราสามารถแสดงได้แบบเรียลไทม์ นี่เป็นเพียงการแสดงผลเท่านั้น ไม่ค่อยมีการทำซ้ำ แต่ถ้าเกิดเหตุการณ์นี้ขึ้น เราจะยุบทิ้งในภายหลัง และมีหลายสิ่งที่ไม่สามารถทำซ้ำได้ - การคลิกและเรื่องราวทั้งหมดนี้ แต่ฉันก็อยากจะแสดงให้พวกเขาเห็นเกือบจะในทันทีด้วย
มุมมองที่เป็นรูปธรรมเกิดขึ้นได้อย่างไร? มีมุมมองที่เขียนโดยตรง - เขียนลงในข้อมูลดิบและเขียนลงในมุมมอง ในบางจุดข้อมูลไม่ถูกต้อง มีการทำซ้ำ และอื่นๆ และมีส่วนที่สองของตารางซึ่งมีลักษณะเหมือนกับมุมมองที่ปรากฏทุกประการนั่นคือมีโครงสร้างที่เหมือนกันทุกประการ ในบางครั้งเราจะคำนวณข้อมูลใหม่ นับข้อมูลโดยไม่ซ้ำกัน เขียนลงในตารางเหล่านั้น
เราใช้ API แล้ว - สิ่งนี้จะไม่ทำงานใน ClickHouse ด้วยตนเอง และ API จะมีลักษณะ: เมื่อฉันมีวันที่เพิ่มลงในตารางครั้งล่าสุด ซึ่งรับประกันว่าข้อมูลที่ถูกต้องได้รับการคำนวณแล้ว และมันส่งคำขอไปยังตารางหนึ่งและอีกตารางหนึ่ง จากคำขอหนึ่งจะเลือกจนถึงระยะเวลาหนึ่ง และอีกคำขอหนึ่งจะได้รับสิ่งที่ยังไม่ได้คำนวณ และใช้งานได้ แต่ไม่ใช่ผ่าน ClickHouse เพียงอย่างเดียว
หากคุณมี API บางอย่าง - สำหรับนักวิเคราะห์สำหรับผู้ใช้ - โดยหลักการแล้วนี่คือตัวเลือก คุณนับเสมอและนับเสมอ ซึ่งสามารถทำได้วันละครั้งหรือเวลาอื่น คุณเลือกช่วงที่คุณไม่ต้องการและไม่สำคัญสำหรับตัวคุณเอง
ClickHouse มีบันทึกมากมาย ฉันจะดูทุกสิ่งที่เกิดขึ้นกับเซิร์ฟเวอร์ได้อย่างรวดเร็วได้อย่างไร?
ClickHouse มีบันทึกที่แตกต่างกันจำนวนมาก และจำนวนนี้ก็เพิ่มมากขึ้น ในเวอร์ชันใหม่ บางเวอร์ชันจะเปิดใช้งานตามค่าเริ่มต้นด้วยซ้ำ ในเวอร์ชันเก่าจะต้องเปิดใช้งานเมื่ออัปเดต อย่างไรก็ตามมีมากขึ้นเรื่อยๆ ท้ายที่สุดแล้ว ฉันอยากจะเห็นว่าเกิดอะไรขึ้นกับเซิร์ฟเวอร์ของฉันตอนนี้ อาจจะเป็นในแดชบอร์ดสรุปบางประเภท
คุณมีทีม ClickHouse หรือทีมของเพื่อนของคุณที่สนับสนุนฟังก์ชันบางอย่างของแดชบอร์ดสำเร็จรูปที่จะแสดงบันทึกเหล่านี้เป็นผลิตภัณฑ์สำเร็จรูปหรือไม่? ท้ายที่สุดแล้ว แค่ดูบันทึกใน ClickHouse ก็ยอดเยี่ยมแล้ว แต่คงจะเจ๋งมากหากได้เตรียมไว้ในรูปแบบของแดชบอร์ดแล้ว ฉันคงจะเตะมันออกไป
มีแดชบอร์ดแม้ว่าจะไม่ได้มาตรฐานก็ตาม ในบริษัทของเรา มีทีมประมาณ 60 ทีมที่ใช้ ClickHouse และสิ่งที่แปลกที่สุดคือหลายทีมมีแดชบอร์ดที่พวกเขาสร้างขึ้นสำหรับตนเอง และแดชบอร์ดที่แตกต่างกันเล็กน้อย บางทีมใช้การติดตั้ง Yandex.Cloud ภายใน มีรายงานสำเร็จรูปบางส่วน แม้ว่าจะไม่ใช่รายงานที่จำเป็นทั้งหมดก็ตาม คนอื่นก็มีของตัวเอง
เพื่อนร่วมงานของฉันจาก Metrica มีแดชบอร์ดของตัวเองใน Grafana และฉันก็มีแดชบอร์ดของตัวเองสำหรับคลัสเตอร์ของพวกเขา ฉันกำลังดูสิ่งต่าง ๆ เช่นการที่แคชเข้าถึงแคชเซอริฟ และที่ยากกว่านั้นคือเราใช้เครื่องมือที่แตกต่างกัน ฉันสร้างแดชบอร์ดโดยใช้เครื่องมือเก่ามากที่เรียกว่า Graphite-web เขาน่าเกลียดมาก และฉันก็ยังใช้วิธีนี้อยู่ แม้ว่า Grafana คงจะสะดวกและสวยงามกว่าก็ตาม
สิ่งพื้นฐานในแดชบอร์ดก็เหมือนกัน สิ่งเหล่านี้คือหน่วยวัดระบบสำหรับคลัสเตอร์: CPU, หน่วยความจำ, ดิสก์, เครือข่าย อื่นๆ - จำนวนคำขอพร้อมกัน, จำนวนการผสานพร้อมกัน, จำนวนคำขอต่อวินาที, จำนวนชิ้นสูงสุดสำหรับพาร์ติชันตาราง MergeTree, ความล่าช้าในการจำลอง, ขนาดคิวการจำลอง, จำนวนแถวที่แทรกต่อวินาที, จำนวนบล็อกที่แทรกต่อวินาที นี่คือทั้งหมดที่ไม่ได้มาจากบันทึก แต่มาจากการวัด
วลาดิมีร์ โคโลบาเยฟ: Alexey ฉันอยากจะแก้ไขมันสักหน่อย นั่นก็คือกราฟาน่า Grafana มีแหล่งข้อมูลซึ่งก็คือ ClickHouse นั่นคือฉันสามารถส่งคำขอจาก Grafana ไปยัง ClickHouse ได้โดยตรง ClickHouse มีตารางพร้อมบันทึก ซึ่งจะเหมือนกันสำหรับทุกคน ด้วยเหตุนี้ ฉันต้องการเข้าถึงตารางบันทึกนี้ใน Grafana และดูคำขอที่เซิร์ฟเวอร์ของฉันสร้างขึ้น ถ้ามีแดชบอร์ดแบบนี้คงจะดี
ฉันปั่นจักรยานเอง แต่ฉันมีคำถาม - หากทุกอย่างเป็นมาตรฐานและทุกคนใช้ Grafana ทำไม Yandex ถึงไม่มีแดชบอร์ดอย่างเป็นทางการเช่นนี้
คิริลล์ ชวาคอฟ: ที่จริงแล้ว แหล่งข้อมูลที่ไปที่ ClickHouse รองรับ Altinity แล้ว และฉันแค่อยากให้เวกเตอร์ว่าควรขุดที่ไหนและควรผลักใคร คุณสามารถถามพวกเขาได้ เพราะยานเดกซ์ยังคงสร้าง ClickHouse ไม่ใช่เรื่องราวรอบตัว Altinity เป็นบริษัทหลักที่ส่งเสริม ClickHouse ในปัจจุบัน พวกเขาจะไม่ทอดทิ้งเขา แต่จะสนับสนุนเขา เพราะโดยหลักการแล้ว หากต้องการอัปโหลดแดชบอร์ดไปยังเว็บไซต์ Grafana คุณเพียงแค่ต้องลงทะเบียนและอัปโหลดเท่านั้น - ไม่มีปัญหาพิเศษใดๆ
อเล็กเซย์ มิโลวิดอฟ: ในปีที่ผ่านมา ClickHouse ได้เพิ่มความสามารถในการจัดทำโปรไฟล์ข้อความค้นหามากมาย มีตัวชี้วัดสำหรับแต่ละคำขอเกี่ยวกับการใช้ทรัพยากร และเมื่อไม่นานมานี้ เราได้เพิ่มตัวสร้างโปรไฟล์การสืบค้นระดับล่างเพื่อดูว่าการสืบค้นใช้เวลาไปที่ไหนทุกมิลลิวินาที แต่เพื่อใช้ฟังก์ชันนี้ ฉันต้องเปิดคอนโซลไคลเอ็นต์และพิมพ์คำขอ ซึ่งฉันมักจะลืมไปเสมอ ฉันบันทึกไว้ที่ไหนสักแห่งและลืมไปว่าอยู่ที่ไหน
ฉันหวังว่าจะมีเครื่องมือที่เพิ่งพูดว่า นี่คือข้อความค้นหาจำนวนมากของคุณ ซึ่งจัดกลุ่มตามคลาสข้อความค้นหา ฉันกดไปอันหนึ่ง แล้วพวกเขาจะบอกฉันว่าทำไมมันถึงหนัก ยังไม่มีวิธีแก้ปัญหาดังกล่าวในขณะนี้ และค่อนข้างแปลกจริงๆ ที่เมื่อมีคนถามฉัน: "บอกฉันหน่อยว่ามีแดชบอร์ดสำเร็จรูปสำหรับ Grafana หรือไม่" ฉันพูดว่า: "ไปที่เว็บไซต์ Grafana มีชุมชน "แดชบอร์ด" และมีแดชบอร์ด จาก Dimka มีแดชบอร์ดจาก Kostyan ฉันไม่รู้ว่ามันคืออะไรฉันไม่ได้ใช้มันเอง”
จะมีอิทธิพลต่อการผสานเพื่อให้เซิร์ฟเวอร์ไม่ขัดข้องใน OOM ได้อย่างไร
ฉันมีตาราง มีเพียงพาร์ติชั่นเดียวในตาราง นั่นคือ ReplacingMergeTree ฉันเขียนข้อมูลลงไปเป็นเวลาสี่ปีแล้ว ฉันต้องทำการเปลี่ยนแปลงและลบข้อมูลบางส่วน
ฉันทำสิ่งนี้ และในระหว่างการประมวลผลคำขอนี้ หน่วยความจำทั้งหมดบนเซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ถูกใช้ไป และเซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ได้เข้าสู่ OOM จากนั้นพวกเขาทั้งหมดก็รวมตัวกัน เริ่มรวมการดำเนินการเดียวกัน บล็อกข้อมูลนี้ และตกลงไปที่ OOM อีกครั้ง แล้วพวกเขาก็ลุกขึ้นอีกครั้งและล้มลงอีก และสิ่งนี้ไม่ได้หยุด
จากนั้นปรากฎว่านี่เป็นข้อผิดพลาดจริง ๆ ที่พวกเขาแก้ไข มันเจ๋งมากขอบคุณมาก แต่ยังมีสารตกค้างอยู่ และตอนนี้ เมื่อฉันคิดถึงการผสานบางอย่างในตาราง ฉันมีคำถาม - เหตุใดฉันจึงไม่สามารถมีอิทธิพลต่อการผสานเหล่านี้ได้ ตัวอย่างเช่น จำกัดด้วยจำนวน RAM ที่ต้องการ หรือตามหลักการแล้ว ตามจำนวนที่จะประมวลผลตารางนี้โดยเฉพาะ
ฉันมีตารางชื่อ "เมตริก" โปรดดำเนินการให้ฉันเป็นสองเธรด ไม่จำเป็นต้องสร้างการผสานสิบหรือห้าครั้งพร้อมกัน แต่ทำเป็นสองส่วน ฉันคิดว่าฉันมีหน่วยความจำเพียงพอสำหรับสองคน แต่อาจจะไม่เพียงพอที่จะประมวลผลสิบ ทำไมความกลัวจึงยังคงอยู่? เพราะตารางกำลังเติบโต และสักวันหนึ่งฉันจะต้องเผชิญกับสถานการณ์ที่โดยหลักการแล้ว ไม่ได้เกิดจากจุดบกพร่องอีกต่อไป แต่เนื่องจากข้อมูลจะเปลี่ยนแปลงในปริมาณมากจนฉันไม่มีหน่วยความจำเพียงพอในนั้น เซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะขัดข้องใน OOM เมื่อรวมเข้าด้วยกัน ยิ่งไปกว่านั้น ฉันสามารถยกเลิกการกลายพันธุ์ได้ แต่ Merji ไม่อยู่ที่นั่นอีกต่อไปแล้ว
คุณรู้ไหมว่าเมื่อทำการรวม เซิร์ฟเวอร์จะไม่ตกอยู่ใน OOM เนื่องจากเมื่อทำการรวม จำนวน RAM จะใช้สำหรับข้อมูลช่วงเล็กๆ เพียงช่วงเดียวเท่านั้น ดังนั้นทุกอย่างจะเรียบร้อยดีโดยไม่คำนึงถึงปริมาณข้อมูล
วลาดิมีร์ โคโลบาเยฟ: ดี. ช่วงเวลานี้หลังจากที่แก้ไขข้อบกพร่องแล้วฉันก็ดาวน์โหลดเวอร์ชันใหม่สำหรับตัวเองและอีกตารางหนึ่งซึ่งเป็นตารางที่เล็กกว่าซึ่งมีพาร์ติชั่นจำนวนมากฉันก็ดำเนินการที่คล้ายกัน และในระหว่างการรวม RAM ประมาณ 100 GB ก็ถูกเบิร์นบนเซิร์ฟเวอร์ ฉันมีพื้นที่ว่าง 150 รายการ กินไป 100 รายการ และเหลือหน้าต่างอีก 50 GB ดังนั้นฉันจึงไม่ตกอยู่ใน OOM
สิ่งใดที่ช่วยปกป้องฉันจากการตกสู่ OOM หากใช้ RAM จริงขนาด 100 GB จะทำอย่างไรถ้าจู่ๆ RAM ในการผสานก็หมด?
อเล็กเซย์ มิโลวิดอฟ: มีปัญหาดังกล่าวว่าการใช้ RAM สำหรับการรวมโดยเฉพาะนั้นไม่ จำกัด และปัญหาที่สองคือ หากมีการกำหนดการผสานบางประเภท จะต้องดำเนินการดังกล่าวเนื่องจากถูกบันทึกไว้ในบันทึกการจำลอง บันทึกการจำลองแบบคือการดำเนินการที่จำเป็นเพื่อนำแบบจำลองเข้าสู่สถานะที่สอดคล้องกัน ถ้าคุณไม่ทำการจัดการด้วยตนเองที่จะย้อนกลับบันทึกการจำลองแบบนี้ การผสานจะต้องดำเนินการไม่ทางใดก็ทางหนึ่ง
แน่นอนว่าการมีข้อจำกัด RAM ที่ "เผื่อไว้" จะป้องกัน OOM ไม่ใช่เรื่องฟุ่มเฟือย มันจะไม่ช่วยให้การผสานเสร็จสมบูรณ์ แต่จะเริ่มอีกครั้ง ถึงเกณฑ์บางอย่าง โยนข้อยกเว้น แล้วเริ่มใหม่อีกครั้ง - จะไม่มีอะไรดีเกิดขึ้น แต่โดยหลักการแล้ว การแนะนำข้อจำกัดนี้จะเป็นประโยชน์
ไดรเวอร์ Golang สำหรับ ClickHouse จะได้รับการพัฒนาอย่างไร
ไดรเวอร์ Golang ซึ่งเขียนโดย Kirill Shvakov ได้รับการสนับสนุนอย่างเป็นทางการจากทีมงาน ClickHouse แล้ว เขา ตอนนี้เขาใหญ่และเป็นจริงแล้ว
บันทึกเล็กๆ น้อยๆ มีพื้นที่เก็บข้อมูลที่ยอดเยี่ยมและเป็นที่รักในรูปแบบปกติของลำดับอนันต์ - นี่คือ Vertica พวกเขายังมีไดรเวอร์ Python อย่างเป็นทางการซึ่งได้รับการสนับสนุนโดยนักพัฒนา Vertica และหลายครั้งที่มันเกิดขึ้นที่เวอร์ชันที่เก็บข้อมูลและเวอร์ชันไดรเวอร์แยกกันค่อนข้างมากและไดรเวอร์ก็หยุดทำงานในบางจุด และประเด็นที่สอง สำหรับฉันดูเหมือนว่าการสนับสนุนไดรเวอร์อย่างเป็นทางการนี้จะดำเนินการโดยระบบ "จุกนม" - คุณเขียนปัญหาไว้และมันจะค้างตลอดไป
ฉันมีสองคำถาม ตอนนี้ไดรเวอร์ Golang ของ Kirill เกือบจะเป็นวิธีเริ่มต้นในการสื่อสารจาก Golang ด้วย ClickHouse เว้นแต่จะมีคนสื่อสารผ่านอินเทอร์เฟซ http เพราะเขาชอบแบบนั้น การพัฒนาไดรเวอร์นี้จะดำเนินต่อไปอย่างไร? มันจะซิงโครไนซ์กับการเปลี่ยนแปลงที่เสียหายในที่เก็บหรือไม่? และมีขั้นตอนการพิจารณาเรื่องอย่างไร?
คิริลล์ ชวาคอฟ: ประการแรกคือวิธีการจัดระเบียบทุกอย่างตามระบบราชการ ประเด็นนี้ไม่ได้พูดคุยกันดังนั้นฉันจึงไม่มีอะไรจะตอบ
เพื่อตอบคำถามเกี่ยวกับปัญหานี้ เราจำเป็นต้องมีประวัติคนขับเล็กน้อย ฉันทำงานให้กับบริษัทที่มีข้อมูลจำนวนมาก มันเป็นตัวหมุนโฆษณาที่มีกิจกรรมจำนวนมากที่ต้องเก็บไว้ที่ไหนสักแห่ง และเมื่อถึงจุดหนึ่ง ClickHouse ก็ปรากฏขึ้น เรากรอกข้อมูลลงไป และในตอนแรกทุกอย่างเรียบร้อยดี แต่แล้ว ClickHouse ก็ขัดข้อง ในขณะนั้นเราตัดสินใจว่าเราไม่ต้องการมัน
หนึ่งปีต่อมาเรากลับมาที่แนวคิดในการใช้ ClickHouse และเราจำเป็นต้องเขียนข้อมูลที่นั่น ข้อความเกริ่นนำคือ: ฮาร์ดแวร์อ่อนแอมาก มีทรัพยากรน้อย แต่เราทำงานในลักษณะนี้มาโดยตลอด ดังนั้นเราจึงมองไปที่โปรโตคอลดั้งเดิม
เนื่องจากเราทำงานใน Go จึงชัดเจนว่าเราต้องการไดรเวอร์ Go ฉันทำมันเกือบเต็มเวลา - มันเป็นงานของฉัน เรามาถึงจุดหนึ่งแล้ว และโดยหลักการแล้วไม่มีใครคิดว่าใครอื่นนอกจากเราจะใช้มัน จากนั้น CloudFlare ก็มาพร้อมกับปัญหาเดียวกันเป๊ะ และในบางครั้งเราก็ทำงานร่วมกับพวกเขาได้อย่างราบรื่นมาก เพราะพวกเขาก็มีงานเดียวกัน ยิ่งกว่านั้น เราทำสิ่งนี้ทั้งใน ClickHouse เองและในไดรเวอร์
เมื่อถึงจุดหนึ่ง ฉันก็หยุดทำเพราะกิจกรรมของฉันในแง่ของ ClickHouse และงานเปลี่ยนไปเล็กน้อย จึงไม่ปิดประเด็น ผู้ที่ต้องการบางสิ่งบางอย่างด้วยตนเองจะถูกส่งไปยังพื้นที่เก็บข้อมูลเป็นระยะๆ จากนั้นฉันก็ดูคำขอดึงและบางครั้งฉันก็แก้ไขบางอย่างด้วยตัวเอง แต่สิ่งนี้เกิดขึ้นไม่บ่อยนัก
ฉันต้องการที่จะกลับไปหาคนขับ เมื่อหลายปีก่อน เมื่อเรื่องทั้งหมดนี้เริ่มต้นขึ้น ClickHouse ก็แตกต่างและมีความสามารถที่แตกต่างกัน ตอนนี้เรามีความเข้าใจเกี่ยวกับวิธีการสร้างไดรเวอร์ใหม่เพื่อให้ทำงานได้ดี หากสิ่งนี้เกิดขึ้น เวอร์ชัน 2 จะไม่สามารถเข้ากันไม่ว่าในกรณีใด ๆ เนื่องจากมีไม้ค้ำยันสะสม
ฉันไม่รู้วิธีจัดระเบียบเรื่องนี้ ฉันเองก็มีเวลาไม่มาก ถ้ามีคนขับรถเสร็จแล้ว ผมสามารถช่วยพวกเขาได้และบอกพวกเขาว่าต้องทำอย่างไร แต่ยังไม่ได้พูดคุยถึงการมีส่วนร่วมอย่างแข็งขันของยานเดกซ์ในการพัฒนาโครงการ
อเล็กเซย์ มิโลวิดอฟ: ในความเป็นจริง ยังไม่มีระบบราชการเกี่ยวกับไดรเวอร์เหล่านี้ สิ่งเดียวคือส่งไปยังองค์กรอย่างเป็นทางการนั่นคือไดรเวอร์นี้ได้รับการยอมรับว่าเป็นโซลูชันเริ่มต้นอย่างเป็นทางการสำหรับ Go มีไดร์เวอร์อื่นๆ บ้าง แต่มาแยกกัน
เราไม่มีการพัฒนาภายในสำหรับไดรเวอร์เหล่านี้ คำถามคือว่าเราสามารถจ้างเป็นรายบุคคลได้หรือไม่ ไม่ใช่สำหรับคนขับรายนี้ แต่เพื่อการพัฒนาผู้ขับขี่ในชุมชนทั้งหมด หรือเราจะหาคนจากภายนอกได้หรือไม่
พจนานุกรมภายนอกไม่โหลดหลังจากรีบูตโดยเปิดใช้งานการตั้งค่าlazy_load จะทำอย่างไร?
เราเปิดใช้งานการตั้งค่า lazy_load และหลังจากที่เซิร์ฟเวอร์รีบูตแล้ว พจนานุกรมจะไม่โหลดเอง มันจะเกิดขึ้นหลังจากที่ผู้ใช้เข้าถึงพจนานุกรมนี้เท่านั้น และครั้งแรกที่เข้าก็เกิดข้อผิดพลาด เป็นไปได้ไหมที่จะโหลดพจนานุกรมโดยอัตโนมัติโดยใช้ ClickHouse หรือคุณจำเป็นต้องควบคุมความพร้อมด้วยตนเองอยู่เสมอเพื่อไม่ให้ผู้ใช้ได้รับข้อผิดพลาด
บางทีเราอาจมี ClickHouse เวอร์ชันเก่า ดังนั้นพจนานุกรมจึงไม่โหลดโดยอัตโนมัติ อาจเป็นเช่นนี้หรือไม่?
ประการแรก พจนานุกรมสามารถบังคับโหลดได้โดยใช้แบบสอบถาม ระบบรีโหลดพจนานุกรม. ประการที่สอง เกี่ยวกับข้อผิดพลาด - หากโหลดพจนานุกรมแล้ว การสืบค้นจะทำงานตามข้อมูลที่โหลด หากยังไม่ได้โหลดพจนานุกรม พจนานุกรมจะถูกโหลดโดยตรงในระหว่างการร้องขอ
สิ่งนี้ไม่สะดวกสำหรับพจนานุกรมที่มีเนื้อหาหนักมาก ตัวอย่างเช่น คุณต้องดึงแถวจำนวนหนึ่งล้านแถวจาก MySQL มีคนทำการเลือกแบบธรรมดา แต่การเลือกนี้จะรอถึงล้านแถวเท่าเดิม มีสองวิธีที่นี่ ประการแรกคือการปิดlazy_load ประการที่สอง เมื่อเซิร์ฟเวอร์พร้อมใช้งาน ก่อนที่จะโหลดให้ทำ พจนานุกรมรีโหลดระบบ หรือเพียงแค่ค้นหาโดยใช้พจนานุกรม จากนั้นพจนานุกรมก็จะโหลดขึ้นมา คุณต้องควบคุมความพร้อมใช้งานของพจนานุกรมโดยเปิดใช้งานการตั้งค่า lazy_load เนื่องจาก ClickHouse จะไม่โหลดพจนานุกรมเหล่านั้นโดยอัตโนมัติ
คำตอบสำหรับคำถามสุดท้ายคือเวอร์ชันเก่าหรือจำเป็นต้องแก้ไขจุดบกพร่อง
จะทำอย่างไรกับความจริงที่ว่าระบบโหลดพจนานุกรมซ้ำไม่โหลดพจนานุกรมใด ๆ จำนวนมากหากพจนานุกรมอย่างน้อยหนึ่งรายการขัดข้องด้วยข้อผิดพลาด
มีคำถามอื่นเกี่ยวกับพจนานุกรมรีโหลดระบบ เรามีพจนานุกรมสองเล่ม - อันหนึ่งไม่ได้โหลด ส่วนอันที่สองถูกโหลด ในกรณีนี้ พจนานุกรมการโหลดซ้ำของระบบจะไม่โหลดพจนานุกรมใดๆ และคุณต้องโหลดพจนานุกรมที่เจาะจงทีละจุดโดยใช้ชื่อโดยใช้พจนานุกรมการโหลดซ้ำของระบบ สิ่งนี้เกี่ยวข้องกับเวอร์ชัน ClickHouse ด้วยหรือไม่
ฉันต้องการทำให้คุณมีความสุข. พฤติกรรมนี้มีการเปลี่ยนแปลง ซึ่งหมายความว่าหากคุณอัปเดต ClickHouse มันก็จะเปลี่ยนไปเช่นกัน หากคุณไม่พอใจกับพฤติกรรมปัจจุบันของคุณ ระบบรีโหลดพจนานุกรมอัปเดต และหวังว่าจะเปลี่ยนแปลงไปในทางที่ดีขึ้น
มีวิธีกำหนดค่ารายละเอียดในการกำหนดค่า ClickHouse แต่ไม่แสดงในกรณีที่เกิดข้อผิดพลาดหรือไม่?
คำถามต่อไปเป็นเรื่องเกี่ยวกับข้อผิดพลาดที่เกี่ยวข้องกับพจนานุกรม กล่าวคือ รายละเอียด เราได้ระบุรายละเอียดการเชื่อมต่อในการกำหนดค่า ClickHouse สำหรับพจนานุกรม และหากมีข้อผิดพลาด เราได้รับรายละเอียดและรหัสผ่านเหล่านี้เป็นการตอบกลับ
เราแก้ไขข้อผิดพลาดนี้ด้วยการเพิ่มรายละเอียดลงในการกำหนดค่าไดรเวอร์ ODBC มีวิธีใดบ้างในการกำหนดค่ารายละเอียดในการกำหนดค่า ClickHouse แต่ไม่แสดงรายละเอียดเหล่านี้ในกรณีที่เกิดข้อผิดพลาด
วิธีแก้ปัญหาที่แท้จริงคือระบุข้อมูลประจำตัวเหล่านี้ใน odbc.ini และใน ClickHouse เองจะระบุเฉพาะชื่อแหล่งข้อมูล ODBC เท่านั้น สิ่งนี้จะไม่เกิดขึ้นกับแหล่งพจนานุกรมอื่นๆ - ทั้งสำหรับพจนานุกรมที่มี MySQL หรือสำหรับแหล่งอื่นๆ คุณไม่ควรเห็นรหัสผ่านเมื่อคุณได้รับข้อความแสดงข้อผิดพลาด สำหรับ ODBC ฉันจะตรวจสอบด้วย - หากมีอยู่ คุณเพียงแค่ต้องลบมันออก
โบนัส: พื้นหลังสำหรับ Zoom จากการรวมตัว
เมื่อคลิกที่ภาพ พื้นหลังโบนัสจากการรวมตัวจะเปิดให้ผู้อ่านที่ติดตามมากที่สุด เราดับไฟพร้อมกับมาสคอตเทคโนโลยี Avito เราหารือกับเพื่อนร่วมงานจากห้องผู้ดูแลระบบหรือชมรมคอมพิวเตอร์รุ่นเก่า และเราจัดการประชุมทุกวันใต้สะพานโดยมีฉากหลังเป็นกราฟฟิตี้
ที่มา: will.com