HighLoad++ มอสโก 2018, หอประชุมใหญ่ วันที่ 9 พฤศจิกายน เวลา 15:00 น
บทคัดย่อและการนำเสนอ:
Yuri Nasretdinov (VKontakte): รายงานจะพูดถึงประสบการณ์การใช้งาน ClickHouse ในบริษัทของเรา - เหตุใดเราจึงต้องการมัน ปริมาณข้อมูลที่เราจัดเก็บ วิธีที่เราเขียนมัน และอื่นๆ
วัสดุเพิ่มเติม:
ยูริ นาเร็ตดินอฟ: - สวัสดีทุกคน! ฉันชื่อ Yuri Nasretdinov ตามที่ฉันได้แนะนำไปแล้ว ฉันทำงานที่ VKontakte ฉันจะพูดถึงวิธีที่เราแทรกข้อมูลลงใน ClickHouse จากฟลีตเซิร์ฟเวอร์ของเรา (นับหมื่น)
บันทึกคืออะไร และเหตุใดจึงต้องรวบรวมมัน
สิ่งที่เราจะบอกคุณ: สิ่งที่เราทำ, ทำไมเราถึงต้องการ "ClickHouse" ตามลำดับ, ทำไมเราถึงเลือกมัน, ประสิทธิภาพประเภทใดที่คุณจะได้รับโดยประมาณโดยไม่ต้องกำหนดค่าอะไรเป็นพิเศษ ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับตารางบัฟเฟอร์ เกี่ยวกับปัญหาที่เรามีกับตารางเหล่านั้น และเกี่ยวกับโซลูชันที่เราพัฒนาจากโอเพ่นซอร์ส - KittenHouse และ Lighthouse
ทำไมเราต้องทำอะไรเลย (บน VKontakte ทุกอย่างดีเสมอใช่ไหม?) เราต้องการรวบรวมบันทึกการแก้ไขข้อบกพร่อง (และมีข้อมูลหลายร้อยเทราไบต์) บางทีการคำนวณสถิติอาจจะสะดวกกว่า และเรามีเซิร์ฟเวอร์นับหมื่นเครื่องที่จำเป็นต้องดำเนินการทั้งหมดนี้
ทำไมเราถึงตัดสินใจ? เราอาจมีวิธีแก้ปัญหาสำหรับการจัดเก็บบันทึก ที่นี่ – มี “Backend VK” สาธารณะเช่นนี้ ฉันขอแนะนำให้สมัครเป็นสมาชิก
บันทึกคืออะไร? นี่คือเอ็นจิ้นที่ส่งคืนอาร์เรย์ว่าง เอ็นจิ้นใน VK คือสิ่งที่คนอื่นเรียกว่าไมโครเซอร์วิส และนี่คือสติ๊กเกอร์ยิ้ม (ถูกใจค่อนข้างมาก) ยังไงล่ะ? เอาล่ะ ฟังต่อไป!
สิ่งที่สามารถใช้เพื่อจัดเก็บบันทึก? เป็นไปไม่ได้ที่จะไม่พูดถึง Hadup ตัวอย่างเช่น Rsyslog (จัดเก็บบันทึกเหล่านี้ในไฟล์) แอลเอสดี. ใครรู้บ้างว่า LSD คืออะไร? ไม่ ไม่ใช่ LSD นี้ จัดเก็บไฟล์ตามลำดับอีกด้วย ClickHouse เป็นตัวเลือกที่แปลก
Clickhouse และคู่แข่ง: ข้อกำหนดและโอกาส
เราต้องการอะไร? เราต้องการให้แน่ใจว่าเราไม่จำเป็นต้องกังวลมากเกินไปเกี่ยวกับการดำเนินการ เพื่อให้สามารถทำงานได้นอกกรอบ โดยควรมีการกำหนดค่าน้อยที่สุด เราอยากเขียนเยอะๆ และเขียนเร็วๆ และเราอยากจะเก็บมันไว้เป็นเดือน เป็นปี หรือเป็นเวลานาน เราอาจต้องการเข้าใจปัญหาบางอย่างที่พวกเขามาหาเราและพูดว่า "มีบางอย่างใช้งานไม่ได้ที่นี่" และนั่นคือเมื่อ 3 เดือนที่แล้ว) และเราต้องการที่จะเห็นว่าเกิดอะไรขึ้นเมื่อ 3 เดือนที่แล้ว " การบีบอัดข้อมูล – เป็นที่ชัดเจนว่าเหตุใดจึงต้องเป็นบวก – เนื่องจากจะช่วยลดจำนวนพื้นที่ที่ใช้
และเรามีข้อกำหนดที่น่าสนใจ: บางครั้งเราเขียนผลลัพธ์ของคำสั่งบางคำสั่ง (เช่น บันทึก) ซึ่งอาจมีขนาดมากกว่า 4 กิโลไบต์ได้อย่างง่ายดาย และหากสิ่งนี้ใช้งานได้บน UDP ก็ไม่จำเป็นต้องใช้... มันจะไม่มี "โอเวอร์เฮด" สำหรับการเชื่อมต่อ และสำหรับเซิร์ฟเวอร์จำนวนมาก นี่จะถือเป็นข้อดี
มาดูกันว่าโอเพ่นซอร์สเสนออะไรให้เราบ้าง ประการแรก เรามี Logs Engine - นี่คือเครื่องยนต์ของเรา โดยหลักการแล้วเขาทำได้ทุกอย่าง แม้กระทั่งเขียนบรรทัดยาวๆ ก็ได้ มันไม่บีบอัดข้อมูลอย่างโปร่งใส เราสามารถบีบอัดคอลัมน์ขนาดใหญ่ได้เองหากต้องการ... แน่นอนว่าเราไม่ต้องการ (ถ้าเป็นไปได้) ปัญหาเดียวคือเขาสามารถให้เฉพาะสิ่งที่เหมาะสมกับความทรงจำของเขาเท่านั้น หากต้องการอ่านส่วนที่เหลือ คุณจะต้องได้รับ binlog ของเอ็นจิ้นนี้ และด้วยเหตุนี้จึงใช้เวลานานพอสมควร
มีทางเลือกอื่นอะไรบ้าง? ตัวอย่างเช่น "Hadup" ใช้งานง่าย... ใครคิดว่า Hadup ติดตั้งง่าย? แน่นอนว่าไม่มีปัญหาในการบันทึก เมื่ออ่านบางครั้งมีคำถามเกิดขึ้น โดยหลักการแล้ว ฉันจะบอกว่าอาจจะไม่ โดยเฉพาะอย่างยิ่งสำหรับบันทึก การจัดเก็บข้อมูลระยะยาว - แน่นอน ใช่ การบีบอัดข้อมูล - ใช่ สตริงที่ยาว - คุณสามารถบันทึกได้อย่างชัดเจน แต่การบันทึกจากเซิร์ฟเวอร์จำนวนมาก... คุณยังต้องทำอะไรบางอย่างด้วยตัวเอง!
Rsyslog. ที่จริงแล้ว เราใช้มันเป็นตัวเลือกสำรองเพื่อให้เราสามารถอ่านมันได้โดยไม่ต้องทิ้ง binlog แต่มันไม่สามารถเขียนบรรทัดยาวๆ ได้ โดยหลักการแล้ว มันไม่สามารถเขียนเกิน 4 กิโลไบต์ได้ คุณต้องทำการบีบอัดข้อมูลในลักษณะเดียวกับตัวคุณเอง การอ่านจะมาจากไฟล์
จากนั้นก็มีการพัฒนา "badushka" ของ LSD โดยพื้นฐานแล้วเหมือนกับ "Rsyslog": รองรับสตริงที่ยาว แต่ไม่สามารถทำงานผ่าน UDP ได้ และอันที่จริง ด้วยเหตุนี้ จึงต้องเขียนสิ่งต่าง ๆ มากมายที่นั่น LSD จำเป็นต้องได้รับการออกแบบใหม่เพื่อให้สามารถบันทึกจากเซิร์ฟเวอร์นับหมื่นเครื่องได้
และที่นี่! ตัวเลือกที่ตลกคือ ElasticSearch วิธีการพูด? เขาอ่านหนังสือได้ดี กล่าวคือ เขาอ่านเร็วแต่เขียนไม่เก่งนัก ประการแรกถ้ามันบีบอัดข้อมูลก็จะอ่อนแอมาก เป็นไปได้มากว่าการค้นหาแบบเต็มต้องใช้โครงสร้างข้อมูลที่มีขนาดใหญ่กว่าโวลุ่มต้นฉบับ ใช้งานยากและมักเกิดปัญหาตามมา และอีกครั้งการบันทึกใน Elastic - เราต้องทำทุกอย่างด้วยตัวเอง
แน่นอนว่า ClickHouse เป็นตัวเลือกในอุดมคติ สิ่งเดียวก็คือการบันทึกจากเซิร์ฟเวอร์นับหมื่นเป็นปัญหา แต่อย่างน้อยก็มีปัญหาอยู่อย่างหนึ่งเราสามารถลองแก้ไขด้วยวิธีใดวิธีหนึ่งได้ และรายงานที่เหลือเกี่ยวกับปัญหานี้ คุณสามารถคาดหวังประสิทธิภาพประเภทใดจาก ClickHouse?
เราจะใส่มันยังไง? เมิร์จทรี
ใครในพวกคุณไม่เคยได้ยินหรือรู้จัก “ClickHouse” บ้าง? ฉันต้องบอกคุณใช่ไหม? เร็วมาก. การแทรกที่นั่น - 1-2 กิกะบิตต่อวินาทีการระเบิดสูงสุด 10 กิกะบิตต่อวินาทีสามารถทนต่อการกำหนดค่านี้ได้จริง - มี Xeons 6-core สองตัว (นั่นคือไม่ได้ทรงพลังที่สุดด้วยซ้ำ), RAM 256 กิกะไบต์, 20 เทราไบต์ ใน RAID (ไม่มีใครกำหนดค่า การตั้งค่าเริ่มต้น) Alexey Milovidov ผู้พัฒนา ClickHouse อาจจะนั่งร้องไห้อยู่ตรงนั้นเพราะเราไม่ได้กำหนดค่าอะไรเลย (ทุกอย่างทำงานแบบนั้นสำหรับเรา) ด้วยเหตุนี้ ความเร็วในการสแกนจึงสามารถรับได้ประมาณ 6 พันล้านบรรทัดต่อวินาทีหากข้อมูลถูกบีบอัดอย่างดี หากคุณชอบ % ในสตริงข้อความ - 100 ล้านบรรทัดต่อวินาที นั่นก็ดูเหมือนว่าจะค่อนข้างเร็ว
เราจะใส่มันยังไง? คุณรู้ไหมว่า VK ใช้ PHP เราจะแทรกจากผู้ปฏิบัติงาน PHP แต่ละคนผ่าน HTTP ลงใน "ClickHouse" ลงในตาราง MergeTree สำหรับแต่ละระเบียน ใครเห็นปัญหากับโครงการนี้บ้าง? ด้วยเหตุผลบางอย่าง ไม่ใช่ทุกคนที่ยกมือขึ้น ให้ฉันบอกคุณ.
ประการแรก มีเซิร์ฟเวอร์จำนวนมาก - ดังนั้นจะมีการเชื่อมต่อจำนวนมาก (ไม่ดี) เป็นการดีกว่าที่จะแทรกข้อมูลลงใน MergeTree ไม่เกินหนึ่งครั้งต่อวินาที และใครจะรู้ว่าทำไม? ตกลงตกลง. ฉันจะบอกคุณอีกเล็กน้อยเกี่ยวกับเรื่องนี้ คำถามที่น่าสนใจอีกข้อหนึ่งคือ เราไม่ได้ทำการวิเคราะห์ เราไม่จำเป็นต้องเพิ่มคุณค่าของข้อมูล เราไม่ต้องการเซิร์ฟเวอร์ระดับกลาง เราต้องการแทรกโดยตรงลงใน "ClickHouse" (ยิ่งดีก็ยิ่งดี)
ดังนั้นการแทรกใน MergeTree ทำอย่างไร? เหตุใดจึงดีกว่าที่จะไม่แทรกบ่อยกว่าหนึ่งครั้งต่อวินาทีหรือน้อยกว่านั้น? ความจริงก็คือว่า "ClickHouse" เป็นฐานข้อมูลเรียงเป็นแนวและเรียงลำดับข้อมูลตามลำดับจากน้อยไปมากของคีย์หลักและเมื่อคุณแทรกไฟล์จำนวนหนึ่งจะถูกสร้างขึ้นอย่างน้อยเท่ากับจำนวนคอลัมน์ที่จัดเรียงข้อมูล ตามลำดับจากน้อยไปมากของคีย์หลัก (สร้างไดเร็กทอรีแยกต่างหาก ชุดของไฟล์บนดิสก์สำหรับแต่ละส่วนแทรก) จากนั้นการแทรกครั้งต่อไปจะเกิดขึ้นและในพื้นหลังจะรวมกันเป็น "พาร์ติชัน" ที่ใหญ่ขึ้น เนื่องจากข้อมูลถูกจัดเรียง จึงเป็นไปได้ที่จะ "รวม" ไฟล์ที่จัดเรียงสองไฟล์โดยไม่ต้องใช้หน่วยความจำมากนัก
แต่อย่างที่คุณอาจเดาได้ หากคุณเขียน 10 ไฟล์สำหรับแต่ละส่วนแทรก ClickHouse (หรือเซิร์ฟเวอร์ของคุณ) จะสิ้นสุดอย่างรวดเร็ว ดังนั้นจึงแนะนำให้แทรกเป็นชุดใหญ่ ดังนั้นเราจึงไม่เคยเปิดตัวโครงการแรกสู่การผลิตเลย เราเปิดตัวหนึ่งทันที ซึ่งที่นี่หมายเลข 2 มี:
ลองจินตนาการว่ามีเซิร์ฟเวอร์ประมาณพันเซิร์ฟเวอร์ที่เราเปิดตัว มีเพียง PHP เท่านั้น และในแต่ละเซิร์ฟเวอร์จะมีตัวแทนในพื้นที่ของเรา ซึ่งเราเรียกว่า "Kittenhouse" ซึ่งรักษาการเชื่อมต่อเดียวกับ "ClickHouse" และแทรกข้อมูลทุกๆ สองสามวินาที แทรกข้อมูลไม่ได้อยู่ใน MergeTree แต่ลงในตารางบัฟเฟอร์ ซึ่งทำหน้าที่อย่างแม่นยำเพื่อหลีกเลี่ยงการแทรกลงใน MergeTree โดยตรงทันที
การทำงานกับตารางบัฟเฟอร์
มันคืออะไร? ตารางบัฟเฟอร์คือชิ้นส่วนของหน่วยความจำที่ถูกแบ่งส่วน (นั่นคือ สามารถแทรกลงในหน่วยความจำได้บ่อยครั้ง) ประกอบด้วยหลายชิ้น และแต่ละชิ้นทำงานเป็นบัฟเฟอร์อิสระ และพวกมันจะถูกล้างอย่างอิสระ (หากคุณมีหลายชิ้นในบัฟเฟอร์ ก็จะมีส่วนแทรกจำนวนมากต่อวินาที) คุณสามารถอ่านจากตารางเหล่านี้ได้ - จากนั้นคุณจะอ่านการรวมกันของเนื้อหาของบัฟเฟอร์และตารางหลัก แต่ในขณะนี้ การเขียนถูกบล็อก ดังนั้นจึงเป็นการดีกว่าที่จะไม่อ่านจากที่นั่น และตารางบัฟเฟอร์แสดง QPS ที่ดีมากนั่นคือมากถึง 3 QPS คุณจะไม่มีปัญหาใด ๆ เลยเมื่อทำการแทรก เห็นได้ชัดว่าหากเซิร์ฟเวอร์สูญเสียพลังงาน ข้อมูลอาจสูญหายได้เนื่องจากถูกเก็บไว้ในหน่วยความจำเท่านั้น
ในเวลาเดียวกันโครงร่างที่มีบัฟเฟอร์จะทำให้ ALTER มีความซับซ้อนเนื่องจากก่อนอื่นคุณต้องทิ้งตารางบัฟเฟอร์เก่าด้วยโครงร่างเก่า (ข้อมูลจะไม่หายไปทุกที่เพราะจะถูกล้างก่อนที่ตารางจะถูกลบ) จากนั้นคุณ "แก้ไข" ตารางที่คุณต้องการและสร้างตารางบัฟเฟอร์อีกครั้ง ดังนั้น แม้ว่าจะไม่มีตารางบัฟเฟอร์ แต่ข้อมูลของคุณจะไม่ไหลไปที่ใดก็ได้ แต่คุณสามารถมีไว้บนดิสก์ได้อย่างน้อยในเครื่อง
Kittyhouse คืออะไรและทำงานอย่างไร?
KittyHouse คืออะไร? นี่คือพร็อกซี ให้ทายว่าภาษาอะไร? ฉันรวบรวมหัวข้อที่ได้รับความนิยมมากที่สุดในรายงานของฉัน - "Clickhouse" ไปสิ บางทีฉันอาจจะจำอย่างอื่นได้ ใช่ สิ่งนี้เขียนด้วยภาษา Go เพราะฉันไม่รู้วิธีเขียนด้วยภาษา C จริงๆ ฉันจึงไม่อยากเขียน
ดังนั้นจึงรักษาการเชื่อมต่อกับแต่ละเซิร์ฟเวอร์และสามารถเขียนลงในหน่วยความจำได้ ตัวอย่างเช่นหากเราเขียนบันทึกข้อผิดพลาดไปที่ Clickhouse ถ้า Clickhouse ไม่มีเวลาใส่ข้อมูล (ท้ายที่สุดหากเขียนมากเกินไป) เราจะไม่ขยายหน่วยความจำ - เราก็แค่โยนส่วนที่เหลือทิ้งไป เพราะถ้าเราเขียนข้อผิดพลาดหลายกิกะบิตต่อวินาที เราก็อาจจะโยนข้อผิดพลาดบางส่วนออกไปได้ บ้านลูกแมวก็ทำได้ นอกจากนี้ยังสามารถดำเนินการจัดส่งที่เชื่อถือได้ กล่าวคือ เขียนลงดิสก์บนเครื่องท้องถิ่น และพยายามส่งข้อมูลจากไฟล์นี้ทุกครั้ง (ที่นั่น ทุกๆ สองสามวินาที) และในตอนแรกเราใช้รูปแบบค่าปกติ - ไม่ใช่รูปแบบไบนารีบางรูปแบบซึ่งเป็นรูปแบบข้อความ (เช่นเดียวกับใน SQL ทั่วไป)
แต่แล้วสิ่งนี้ก็เกิดขึ้น เราใช้การจัดส่งที่เชื่อถือได้ เขียนบันทึก จากนั้นจึงตัดสินใจ (เป็นคลัสเตอร์ทดสอบแบบมีเงื่อนไข)... มันถูกปล่อยออกมาเป็นเวลาหลายชั่วโมงและนำกลับมาใหม่ และการแทรกเริ่มต้นจากเซิร์ฟเวอร์นับพัน - ปรากฎว่า Clickhouse ยังคงมี “ เธรดในการเชื่อมต่อ” - ดังนั้นในการเชื่อมต่อพันครั้งการแทรกที่ใช้งานอยู่จะนำไปสู่โหลดเฉลี่ยบนเซิร์ฟเวอร์ประมาณหนึ่งพันครึ่ง น่าประหลาดใจที่เซิร์ฟเวอร์ยอมรับคำขอ แต่ข้อมูลยังคงถูกแทรกหลังจากนั้นระยะหนึ่ง แต่เซิร์ฟเวอร์จะให้บริการได้ยากมาก...
เพิ่ม nginx
วิธีแก้ปัญหาสำหรับ Thread ต่อโมเดลการเชื่อมต่อคือ nginx เราติดตั้ง nginx ที่ด้านหน้า Clickhouse ในเวลาเดียวกันก็ตั้งค่าสมดุลสำหรับสองแบบจำลอง (ความเร็วในการแทรกของเราเพิ่มขึ้น 2 เท่า แม้ว่าจะไม่ใช่ความจริงที่ว่าควรเป็นเช่นนั้นก็ตาม) และจำกัดจำนวนการเชื่อมต่อกับ Clickhouse ไว้ที่ ต้นน้ำและดังนั้น มากกว่าในการเชื่อมต่อ 50 รายการ ดูเหมือนว่าไม่มีประโยชน์ที่จะแทรก
จากนั้นเราก็ตระหนักว่าโดยทั่วไปรูปแบบนี้มีข้อเสีย เนื่องจากเรามี nginx เพียงอันเดียวที่นี่ ดังนั้น หาก nginx นี้ขัดข้อง แม้ว่าจะมีแบบจำลองอยู่ เราก็สูญเสียข้อมูลหรืออย่างน้อยก็ไม่เขียนที่ใดเลย นั่นเป็นเหตุผลที่เราสร้างสมดุลภาระงานของเราเอง นอกจากนี้เรายังตระหนักด้วยว่า "Clickhouse" ยังคงเหมาะสำหรับบันทึกและ "ปีศาจ" ก็เริ่มเขียนบันทึกของเขาใน "Clickhouse" ซึ่งสะดวกมากพูดตามตรง เรายังคงใช้มันเพื่อ "ปีศาจ" อื่น ๆ
จากนั้นเราค้นพบปัญหาที่น่าสนใจนี้: หากคุณใช้วิธีการแทรกในโหมด SQL ที่ไม่ได้มาตรฐาน มันจะบังคับให้มีตัวแยกวิเคราะห์ SQL ที่ใช้ AST เต็มรูปแบบซึ่งค่อนข้างช้า ดังนั้นเราจึงได้เพิ่มการตั้งค่าเพื่อให้แน่ใจว่าสิ่งนี้จะไม่เกิดขึ้น เราทำโหลดบาลานซ์ ตรวจสุขภาพ เพื่อที่ว่าหากมีคนเสียชีวิต เรายังคงทิ้งข้อมูลไว้ ตอนนี้เรามีตารางค่อนข้างมากที่เราจำเป็นต้องมีคลัสเตอร์ Clickhouse ที่แตกต่างกัน และเรายังเริ่มคิดถึงการใช้งานอื่นๆ ด้วย เช่น เราต้องการเขียนบันทึกจากโมดูล nginx แต่พวกเขาไม่รู้วิธีสื่อสารโดยใช้ RPC ของเรา ฉันอยากจะสอนพวกเขาถึงวิธีการส่งอย่างน้อยที่สุด - ตัวอย่างเช่นการรับกิจกรรมบน localhost ผ่าน UDP แล้วส่งต่อไปที่ Clickhouse
ห่างจากวิธีแก้ปัญหาเพียงก้าวเดียว
รูปแบบสุดท้ายเริ่มมีลักษณะเช่นนี้ (เวอร์ชันที่สี่ของรูปแบบนี้): ในแต่ละเซิร์ฟเวอร์ที่ด้านหน้า Clickhouse จะมี nginx (บนเซิร์ฟเวอร์เดียวกัน) และเป็นเพียงคำขอพรอกซีไปยัง localhost โดยจำกัดจำนวนการเชื่อมต่อที่ 50 ชิ้นส่วน. และโครงการนี้ค่อนข้างได้ผลแล้ว ทุกอย่างค่อนข้างดีด้วย
เราใช้ชีวิตแบบนี้ประมาณหนึ่งเดือน ทุกคนมีความสุข พวกเขาเพิ่มตาราง เพิ่ม เพิ่ม... โดยทั่วไป ปรากฎว่าวิธีที่เราเพิ่มตารางบัฟเฟอร์นั้นไม่เหมาะสมที่สุด (เอาเป็นว่าเป็นเช่นนั้น) เราทำ 16 ชิ้นในแต่ละโต๊ะและช่วงเวลาแฟลชไม่กี่วินาที เรามี 20 ตารางและแต่ละตารางได้รับการแทรก 8 รายการต่อวินาที - และ ณ จุดนี้ "Clickhouse" ได้เริ่มขึ้น... บันทึกเริ่มช้าลง พวกเขาไม่ผ่านเลยด้วยซ้ำ... โดยค่าเริ่มต้น Nginx มีสิ่งที่น่าสนใจมาก ซึ่งหากการเชื่อมต่อสิ้นสุดลงที่อัปสตรีม มันก็จะส่งคืน "502" ไปยังคำขอใหม่ทั้งหมด
และนี่คือ (ฉันเพิ่งดูบันทึกใน Clickhouse เอง) คำขอประมาณครึ่งเปอร์เซ็นต์ล้มเหลว ดังนั้นการใช้งานดิสก์จึงสูงจึงมีการผสานกันมากมาย ฉันทำอะไรลงไป? โดยธรรมชาติแล้ว ฉันไม่สนใจที่จะเข้าใจว่าทำไมการเชื่อมต่อและอัปสตรีมจึงสิ้นสุดลง
การแทนที่ nginx ด้วยพร็อกซีย้อนกลับ
ฉันตัดสินใจว่าเราต้องจัดการสิ่งนี้ด้วยตัวเอง เราไม่จำเป็นต้องปล่อยให้มันเป็น nginx - nginx ไม่รู้ว่ามีตารางใดบ้างใน Clickhouse และฉันแทนที่ nginx ด้วยพร็อกซีย้อนกลับ ซึ่งฉันก็เขียนเองด้วย
เขากำลังทำอะไร? มันทำงานบนไลบรารี fasthttp “goshnoy” ซึ่งก็คือเร็ว เกือบจะเร็วเท่ากับ nginx ขออภัย Igor หากคุณอยู่ที่นี่ (หมายเหตุ: Igor Sysoev เป็นโปรแกรมเมอร์ชาวรัสเซียที่สร้างเว็บเซิร์ฟเวอร์ nginx) สามารถเข้าใจได้ว่าแบบสอบถามเหล่านี้คืออะไร – INSERT หรือ SELECT – ดังนั้นจึงเก็บกลุ่มการเชื่อมต่อที่แตกต่างกันสำหรับแบบสอบถามประเภทต่างๆ
ดังนั้น แม้ว่าเราจะไม่มีเวลาดำเนินการตามคำขอแทรก แต่ "การเลือก" จะผ่าน และในทางกลับกัน และจะจัดกลุ่มข้อมูลลงในตารางบัฟเฟอร์ - ด้วยบัฟเฟอร์ขนาดเล็ก: หากมีข้อผิดพลาด ข้อผิดพลาดทางไวยากรณ์ และอื่นๆ - เพื่อไม่ให้ส่งผลกระทบต่อข้อมูลที่เหลือมากนัก เพราะเมื่อเราแทรกลงในตารางบัฟเฟอร์ เราจะ มี " bachi" เล็กน้อย และข้อผิดพลาดทางไวยากรณ์ทั้งหมดส่งผลต่อส่วนเล็กๆ นี้เท่านั้น และที่นี่จะส่งผลต่อบัฟเฟอร์ขนาดใหญ่แล้ว ขนาดเล็กคือ 1 เมกะไบต์ ซึ่งไม่เล็กนัก
การแทรกการซิงโครไนซ์และการแทนที่ nginx โดยพื้นฐานแล้วจะทำสิ่งเดียวกันกับที่ nginx ทำก่อนหน้านี้ - คุณไม่จำเป็นต้องเปลี่ยน "Kittenhouse" ในพื้นที่สำหรับสิ่งนี้ และเนื่องจากใช้ fasthttp จึงรวดเร็วมาก - คุณสามารถส่งคำขอมากกว่า 100 คำขอต่อวินาทีสำหรับการแทรกครั้งเดียวผ่านพร็อกซีย้อนกลับ ตามทฤษฎี คุณสามารถแทรกทีละบรรทัดลงในพร็อกซีย้อนกลับของบ้านลูกแมวได้ แต่แน่นอนว่าเราไม่ทำเช่นนั้น
โครงการเริ่มมีลักษณะเช่นนี้: "Kittenhouse" ซึ่งเป็นพร็อกซีย้อนกลับจัดกลุ่มคำขอจำนวนมากลงในตารางและในทางกลับกัน ตารางบัฟเฟอร์จะแทรกคำขอเหล่านั้นลงในคำขอหลัก
Killer เป็นวิธีการแก้ปัญหาชั่วคราว ส่วน Kitty เป็นวิธีถาวร
นี่เป็นปัญหาที่น่าสนใจ... มีใครเคยใช้ fasthttp บ้างไหม? ใครใช้ fasthttp กับคำขอ POST อาจเป็นไปได้ว่าสิ่งนี้ไม่ควรทำจริงๆ เพราะมันบัฟเฟอร์เนื้อหาคำขอตามค่าเริ่มต้น และขนาดบัฟเฟอร์ของเราถูกกำหนดไว้ที่ 16 เมกะไบต์ การแทรกนั้นหยุดตามทัน และชิ้นส่วนขนาด 16 เมกะไบต์ก็เริ่มเข้ามาจากเซิร์ฟเวอร์นับหมื่น และพวกมันทั้งหมดถูกบัฟเฟอร์ไว้ในหน่วยความจำก่อนที่จะถูกส่งไปยัง Clickhouse ดังนั้น หน่วยความจำจึงหมด นักฆ่าหน่วยความจำไม่เพียงพอจึงเข้ามาและฆ่า Reverse proxy (หรือ "Clickhouse" ซึ่งในทางทฤษฎีสามารถ "กิน" มากกว่า Reverse proxy) วงจรซ้ำรอยเดิม ไม่ใช่ปัญหาที่น่าพอใจมาก แม้ว่าเราจะสะดุดกับสิ่งนี้หลังจากดำเนินการไปหลายเดือนเท่านั้น
ฉันทำอะไรลงไป? ฉันไม่ชอบที่จะเข้าใจว่าเกิดอะไรขึ้นจริงๆ ฉันคิดว่ามันค่อนข้างชัดเจนว่าคุณไม่ควรบัฟเฟอร์ในหน่วยความจำ ฉันไม่สามารถแก้ไข fasthttp ได้ แม้ว่าฉันจะลองแล้วก็ตาม แต่ฉันพบวิธีที่จะทำได้โดยไม่จำเป็นต้องแก้ไขอะไรเลย และฉันก็คิดวิธีการของตัวเองขึ้นมาใน HTTP - ฉันเรียกมันว่า KITTEN มันสมเหตุสมผล - "VK", "ลูกแมว"... อะไรอีก?..
หากมีคำขอมาถึงเซิร์ฟเวอร์ด้วยวิธี Kitty เซิร์ฟเวอร์ควรตอบสนอง "meow" - ตามตรรกะ หากเขาตอบสนองต่อสิ่งนี้ ก็ถือว่าเขาเข้าใจโปรโตคอลนี้ จากนั้นฉันก็สกัดกั้นการเชื่อมต่อ (fasthttp มีวิธีดังกล่าว) และการเชื่อมต่อจะเข้าสู่โหมด "ดิบ" ทำไมฉันถึงต้องการมัน? ฉันต้องการควบคุมการอ่านจากการเชื่อมต่อ TCP ที่เกิดขึ้น TCP มีคุณสมบัติที่ยอดเยี่ยม: หากไม่มีใครอ่านจากอีกด้านหนึ่ง การเขียนจะเริ่มรอและไม่ได้ใช้หน่วยความจำกับสิ่งนี้เป็นพิเศษ
ดังนั้นฉันจึงอ่านจากลูกค้าประมาณ 50 รายในแต่ละครั้ง (จากห้าสิบเพราะห้าสิบน่าจะเพียงพออย่างแน่นอนแม้ว่าอัตราจะมาจาก DC อื่นก็ตาม)... การบริโภคลดลงด้วยวิธีนี้อย่างน้อย 20 ครั้ง แต่พูดตามตรง ฉันไม่สามารถวัดเวลาได้แน่ชัดเพราะมันไม่มีจุดหมายอยู่แล้ว (ถึงระดับข้อผิดพลาดแล้ว) โปรโตคอลเป็นแบบไบนารี กล่าวคือ ประกอบด้วยชื่อตารางและข้อมูล ไม่มีส่วนหัว http ดังนั้นฉันจึงไม่ได้ใช้เว็บซ็อกเก็ต (ฉันไม่จำเป็นต้องสื่อสารกับเบราว์เซอร์ - ฉันสร้างโปรโตคอลที่เหมาะกับความต้องการของเรา) และทุกอย่างก็ดีกับเขา
โต๊ะบัฟเฟอร์เศร้า
เมื่อเร็ว ๆ นี้เราพบคุณสมบัติที่น่าสนใจอีกอย่างหนึ่งของตารางบัฟเฟอร์ และปัญหานี้ก็เจ็บปวดมากกว่าปัญหาอื่น ๆ อยู่แล้ว ลองจินตนาการถึงสถานการณ์นี้: คุณใช้งาน Clickhouse อยู่แล้ว คุณมีเซิร์ฟเวอร์ Clickhouse หลายสิบเครื่อง และคุณมีคำขอบางคำขอที่ใช้เวลานานมากในการอ่าน (เช่น มากกว่า 60 วินาที) และคุณมาทำ Alter ในขณะนี้... ในระหว่างนี้ "การเลือก" ที่เริ่มต้นก่อน "Alter" จะไม่รวมอยู่ในตารางนี้ "Alter" จะไม่เริ่มทำงาน - อาจเป็นคุณลักษณะบางอย่างของการทำงานของ "Clickhouse" สถานที่นี้. อาจจะสามารถแก้ไขได้? หรือมันเป็นไปไม่ได้?
โดยทั่วไปเป็นที่ชัดเจนว่าในความเป็นจริงนี่ไม่ใช่ปัญหาใหญ่ แต่ด้วยตารางบัฟเฟอร์มันจะเจ็บปวดมากขึ้น เพราะหากสมมุติว่าการหมดเวลา “Alter” ของคุณ (และอาจหมดเวลาบนโฮสต์อื่น - ไม่ใช่บนโฮสต์ของคุณ แต่บนแบบจำลอง เป็นต้น) ดังนั้น... คุณลบตารางบัฟเฟอร์แล้ว “Alter” ของคุณ ( หรือโฮสต์อื่น ๆ บางส่วน) หมดเวลา จากนั้นเกิดข้อผิดพลาด "แก้ไข" - คุณยังต้องแน่ใจว่าข้อมูลยังคงถูกเขียนต่อไป: คุณสร้างตารางบัฟเฟอร์กลับ (ตามรูปแบบเดียวกันกับตารางหลัก) จากนั้น “Alter” ดำเนินไปจนจบ และบัฟเฟอร์ของตารางเริ่มมีความแตกต่างในสคีมาจากพาเรนต์ ส่วนแทรกอาจไม่ไปที่ตารางบัฟเฟอร์นี้อีกต่อไป ขึ้นอยู่กับว่า "Alter" คืออะไร - เป็นเรื่องน่าเศร้ามาก
นอกจากนี้ยังมีสัญญาณดังกล่าว (อาจมีบางคนสังเกตเห็น) - เรียกว่า query_thread_log ใน Clickhouse เวอร์ชันใหม่ โดยค่าเริ่มต้น ในบางเวอร์ชันจะมีอยู่หนึ่งรายการ ที่นี่เราได้สะสม 840 ล้านบันทึกภายในสองสามเดือน (100 กิกะไบต์) นี่เป็นเพราะความจริงที่ว่ามีการเขียน "ส่วนแทรก" ไว้ที่นั่น (บางทีตอนนี้ยังไม่ได้เขียนเลย) อย่างที่ฉันบอกคุณว่า "ส่วนแทรก" ของเรามีขนาดเล็ก - เรามี "ส่วนแทรก" จำนวนมากในตารางบัฟเฟอร์ ชัดเจนว่าสิ่งนี้ถูกปิดใช้งาน - ฉันแค่บอกคุณถึงสิ่งที่ฉันเห็นบนเซิร์ฟเวอร์ของเรา ทำไม นี่เป็นอีกข้อโต้แย้งที่ต่อต้านการใช้ตารางบัฟเฟอร์! สปอตตี้เสียใจมาก
ใครจะรู้ว่าผู้ชายคนนี้ชื่อสปอตตี้? พนักงาน VK ยกมือขึ้น ตกลง.
เกี่ยวกับแผนการของ “KitttenHouse”
ปกติแผนจะไม่แชร์กันใช่ไหม? ทันใดนั้นคุณจะไม่เติมเต็มพวกเขาและจะไม่ดูดีในสายตาคนอื่น แต่ฉันจะเสี่ยง! เราต้องการทำสิ่งต่อไปนี้: สำหรับฉันแล้ว ดูเหมือนว่าตารางบัฟเฟอร์ยังคงเป็นไม้ยันรักแร้ และเราจำเป็นต้องบัฟเฟอร์การแทรกด้วยตนเอง แต่เรายังคงไม่ต้องการบัฟเฟอร์ไว้บนดิสก์ ดังนั้นเราจะบัฟเฟอร์การแทรกในหน่วยความจำ
ดังนั้น เมื่อทำการ "แทรก" มันจะไม่ซิงโครนัสอีกต่อไป - มันจะทำงานเป็นตารางบัฟเฟอร์อยู่แล้ว จะแทรกลงในตารางหลัก (สักวันหนึ่งในภายหลัง) และรายงานผ่านช่องทางแยกต่างหากที่ส่วนแทรกได้ผ่านไปแล้วและ ไม่ได้
เหตุใดฉันจึงไม่สามารถทิ้งการแทรกแบบซิงโครนัสได้ สะดวกกว่ามาก ความจริงก็คือถ้าคุณแทรกจาก 10 โฮสต์ทุกอย่างก็ดี - คุณจะได้รับเล็กน้อยจากแต่ละโฮสต์ คุณแทรกที่นั่นวินาทีละครั้งทุกอย่างเรียบร้อยดี แต่ฉันต้องการให้รูปแบบนี้ใช้งานได้เช่นจากสองเครื่องเพื่อให้คุณสามารถดาวน์โหลดด้วยความเร็วสูง - อาจจะไม่ได้ประโยชน์สูงสุดจาก Clickhouse แต่เขียนอย่างน้อย 100 เมกะไบต์ต่อวินาทีจากเครื่องหนึ่งผ่านพร็อกซีย้อนกลับ - รูปแบบนี้ต้องปรับขนาดเป็นทั้งปริมาณมากและน้อย ดังนั้นเราจึงไม่สามารถรอสักครู่สำหรับการแทรกแต่ละครั้งได้ ดังนั้นจึงต้องเป็นแบบอะซิงโครนัส และในทำนองเดียวกัน การยืนยันแบบอะซิงโครนัสควรเกิดขึ้นหลังจากการแทรกเสร็จสมบูรณ์ เราจะรู้ว่ามันผ่านหรือไม่
สิ่งที่สำคัญที่สุดคือในโครงการนี้เรารู้แน่ว่าการแทรกเกิดขึ้นหรือไม่ ลองนึกภาพสถานการณ์นี้: คุณมีตารางบัฟเฟอร์ คุณเขียนอะไรบางอย่างลงไป จากนั้น สมมติว่าตารางเข้าสู่โหมดอ่านอย่างเดียวและพยายามล้างบัฟเฟอร์ ข้อมูลจะไปไหน? พวกเขาจะยังคงอยู่ในบัฟเฟอร์ แต่เราไม่แน่ใจในเรื่องนี้ - จะเกิดอะไรขึ้นหากมีข้อผิดพลาดอื่น ๆ ซึ่งทำให้ข้อมูลไม่คงอยู่ในบัฟเฟอร์... (กล่าวกับ Alexey Milovidov, Yandex, ผู้พัฒนา ClickHouse) หรือจะยังคงอยู่? เสมอ? Alexey โน้มน้าวเราว่าทุกอย่างจะเรียบร้อยดี เราไม่มีเหตุผลที่จะไม่เชื่อเขา แต่ทั้งหมดก็เหมือนกัน: ถ้าเราไม่ใช้ตารางบัฟเฟอร์ ก็จะไม่มีปัญหาใดๆ กับตารางเหล่านั้น การสร้างตารางเป็นสองเท่าก็ไม่สะดวกเช่นกัน แม้ว่าโดยหลักการแล้วจะไม่มีปัญหาใหญ่ก็ตาม นี่คือแผน
มาพูดถึงการอ่านกันดีกว่า
ทีนี้มาพูดถึงการอ่านกันดีกว่า เรายังเขียนเครื่องมือของเราเองที่นี่ ดูเหมือนทำไมถึงเขียนเครื่องดนตรีของคุณเองที่นี่.. แล้วใครใช้ Tabix? น้อยคนนักที่จะยกมือขึ้น... แล้วใครล่ะที่พอใจกับการแสดงของ Tabix? เราไม่พอใจกับมันและไม่สะดวกในการดูข้อมูล เป็นเรื่องปกติสำหรับการวิเคราะห์ แต่สำหรับการดูเท่านั้นยังไม่ได้รับการปรับให้เหมาะสมอย่างชัดเจน ดังนั้นฉันจึงเขียนอินเทอร์เฟซของฉันเอง
มันง่ายมาก - สามารถอ่านได้เฉพาะข้อมูลเท่านั้น เขาไม่รู้วิธีแสดงกราฟิก เขาไม่รู้วิธีทำอะไรเลย แต่มันสามารถแสดงสิ่งที่เราต้องการได้ เช่น จำนวนแถวในตาราง พื้นที่ที่ใช้ไป (โดยไม่แบ่งเป็นคอลัมน์) นั่นคืออินเทอร์เฟซพื้นฐานคือสิ่งที่เราต้องการ
และมันดูคล้ายกับ Sequel Pro มาก แต่สร้างบน Bootstrap ของ Twitter เท่านั้น และเวอร์ชันที่สอง คุณถามว่า: “ยูริ ทำไมเป็นเวอร์ชันที่สองล่ะ?” ปีอะไร? 2018? โดยทั่วไป ฉันทำสิ่งนี้เมื่อนานมาแล้วสำหรับ “Muscle” (MySQL) และเพิ่งเปลี่ยนสองสามบรรทัดในข้อความค้นหาที่นั่น และมันเริ่มทำงานกับ “Clickhouse” ซึ่งขอขอบคุณเป็นพิเศษ! เนื่องจาก parser นั้นคล้ายกับ "muscle" มากและการสืบค้นก็คล้ายกันมาก - สะดวกมากโดยเฉพาะในตอนแรก
คือสามารถกรองตารางได้ แสดงโครงสร้างและเนื้อหาของตารางได้ ช่วยให้คุณสามารถจัดเรียง กรองตามคอลัมน์ แสดงแบบสอบถามที่ทำให้เกิดผลลัพธ์ แถวที่ได้รับผลกระทบ (จำนวนผลลัพธ์) นั่นคือ สิ่งพื้นฐานสำหรับการดูข้อมูล ค่อนข้างเร็ว
มีบรรณาธิการด้วย ฉันพยายามขโมยโปรแกรมแก้ไขทั้งหมดจาก Tabix จริงๆ แต่ก็ทำไม่ได้ แต่อย่างใดมันก็ใช้งานได้ โดยหลักการแล้วก็แค่นั้นแหละ
"คลิกเฮาส์" เหมาะสำหรับรัง
ฉันอยากจะบอกคุณว่า Clickhouse แม้จะมีปัญหาทั้งหมดที่อธิบายไว้ แต่ก็เหมาะอย่างยิ่งสำหรับบันทึก สิ่งสำคัญที่สุดคือช่วยแก้ปัญหาของเราได้ - รวดเร็วมากและช่วยให้คุณสามารถกรองบันทึกตามคอลัมน์ได้ โดยหลักการแล้ว ตารางบัฟเฟอร์ทำงานได้ไม่ดีนัก แต่โดยปกติจะไม่มีใครรู้ว่าทำไม... บางทีตอนนี้คุณอาจรู้ดีขึ้นแล้วว่าจุดใดที่คุณจะมีปัญหา
ทีพีซี? โดยทั่วไปใน VK เป็นเรื่องปกติที่จะใช้ UDP และเมื่อฉันใช้ TCP... แน่นอนว่าไม่มีใครบอกฉันว่า: “ยูริ คุณกำลังพูดถึงอะไร! คุณทำไม่ได้ คุณต้องมี UDP” ปรากฎว่า TCP ไม่ได้น่ากลัวขนาดนั้น สิ่งเดียวคือถ้าคุณมีสารประกอบออกฤทธิ์นับหมื่นที่คุณเขียน คุณต้องเตรียมมันอย่างระมัดระวังมากขึ้นอีกเล็กน้อย แต่มันเป็นไปได้และค่อนข้างง่าย
ฉันสัญญาว่าจะโพสต์ "Kittenhouse" และ "Lighthouse" บน HighLoad Siberia หากทุกคนสมัครรับ "แบ็กเอนด์ VK" สาธารณะของเรา... และคุณรู้ไหม ไม่ใช่ทุกคนที่สมัครรับข้อมูล... แน่นอนว่าฉันจะไม่ขอให้คุณสมัครรับข้อมูลของเรา สาธารณะ. ยังมีอีกเยอะครับ อาจจะมีคนไม่พอใจ แต่ยังไงก็ช่วยกดติดตามด้วยนะครับ (และนี่ผมต้องทำตาให้เหมือนแมว) นั่นก็คือ . ขอบคุณมาก! Github เป็นของเรา . ด้วย Clickhouse ผมของคุณจะนุ่มสลวย
ผู้ดำเนินรายการ: - เพื่อน ๆ ตอนนี้มีคำถาม หลังจากที่เราแสดงใบรับรองการขอบคุณและรายงานของคุณเกี่ยวกับ VHS
ยูริ นัสเร็ตดินอฟ (ต่อไปนี้จะเรียกว่า YN): – คุณสามารถบันทึกรายงานของฉันเกี่ยวกับ VHS ได้อย่างไรถ้ามันเพิ่งจบลง?
ผู้ดำเนินรายการ: – คุณยังไม่สามารถระบุได้อย่างครบถ้วนว่า “Clickhouse” จะทำงานอย่างไรหรือไม่! เพื่อน ๆ ขอเวลาซักถาม 5 นาที!
คำถาม
คำถามจากผู้ฟัง (ต่อไปนี้จะเรียกว่า Q): - สวัสดีตอนบ่าย. ขอบคุณมากสำหรับรายงาน ฉันมีสองคำถาม ฉันจะเริ่มต้นด้วยสิ่งไม่สำคัญ: จำนวนตัวอักษร t ในชื่อ "Kittenhouse" ในแผนภาพ (3, 4, 7...) ส่งผลต่อความพึงพอใจของแมวหรือไม่?
ยิน: - ปริมาณอะไร?
З: – ตัวอักษร ต. มีสามตัว ประมาณสามตัว
ยิน: - ฉันไม่ได้ซ่อมมันเหรอ? แน่นอนว่าเป็นเช่นนั้น! นี่เป็นผลิตภัณฑ์ที่แตกต่างกัน - ฉันแค่หลอกลวงคุณตลอดเวลานี้ โอเค ฉันล้อเล่น - มันไม่สำคัญ เอ่อ ที่นี่! ไม่หรอก มันเป็นสิ่งเดียวกัน ฉันพิมพ์ผิด
З: - ขอบคุณ. คำถามที่สองจริงจัง เท่าที่ฉันเข้าใจ ใน Clickhouse ตารางบัฟเฟอร์จะอยู่ในหน่วยความจำโดยเฉพาะ ไม่ได้ถูกบัฟเฟอร์บนดิสก์ ดังนั้นจึงไม่คงอยู่ถาวร
ยิน: - ใช่.
З: – และในเวลาเดียวกัน ไคลเอนต์ของคุณบัฟเฟอร์ไปที่ดิสก์ ซึ่งหมายถึงการรับประกันการส่งมอบบันทึกเดียวกันเหล่านี้ แต่นี่ไม่รับประกันที่ Clickhouse อธิบายว่าดำเนินการรับประกันอย่างไรเนื่องจากอะไร.. นี่คือกลไกนี้โดยละเอียด
ยิน: – ใช่ ตามทฤษฎีแล้วไม่มีความขัดแย้งที่นี่ เพราะเมื่อ Clickhouse ล้ม คุณสามารถตรวจจับมันได้ด้วยวิธีที่แตกต่างกันนับล้านวิธี หาก Clickhouse ขัดข้อง (หากจบลงอย่างไม่ถูกต้อง) คุณสามารถย้อนกลับบันทึกเล็กน้อยที่คุณจดไว้และเริ่มจากช่วงเวลาที่ทุกอย่างเรียบร้อยดี สมมติว่าคุณกรอกลับหนึ่งนาที นั่นคือ ถือว่าคุณได้ล้างทุกอย่างในหนึ่งนาทีแล้ว
З: – คือ “บ้านลูกแมว” ยึดหน้าต่างให้ยาวขึ้น และหากล้ม สามารถรับรู้และกรอกลับได้หรือไม่?
ยิน: – แต่นี่เป็นในทางทฤษฎี ในทางปฏิบัติ เราไม่ทำเช่นนี้ และการจัดส่งที่เชื่อถือได้คือจากศูนย์ถึงอนันต์ครั้ง แต่โดยเฉลี่ยแล้ว เราพอใจที่หาก Clickhouse ขัดข้องด้วยเหตุผลบางประการหรือเซิร์ฟเวอร์ "รีบูต" เราก็จะสูญเสียเพียงเล็กน้อย ในกรณีอื่นๆ ทั้งหมด จะไม่มีอะไรเกิดขึ้น
З: - สวัสดี. ตั้งแต่เริ่มต้น สำหรับฉันแล้วดูเหมือนว่าคุณจะใช้ UDP จริงๆ ตั้งแต่เริ่มต้นรายงาน คุณมี http ทั้งหมดนี้... และปัญหาส่วนใหญ่ที่คุณอธิบายตามที่ฉันเข้าใจนั้นเกิดจากวิธีแก้ปัญหาเฉพาะนี้...
ยิน: – เราใช้ TCP อะไร?
З: - โดยพื้นฐานแล้วใช่
ยิน: - เลขที่.
З: – ด้วย fasthttp ที่คุณมีปัญหากับการเชื่อมต่อที่คุณมีปัญหา หากคุณเพิ่งใช้ UDP คุณจะช่วยตัวเองได้ระยะหนึ่ง คงจะมีปัญหากับข้อความยาวๆหรืออย่างอื่น...
ยิน: - กับอะไร?
З: – ด้วยข้อความที่ยาวเนื่องจากอาจไม่เข้ากับ MTU อย่างอื่น... ก็อาจมีปัญหาเกิดขึ้นเอง คำถามคือ: ทำไมไม่ UDP?
ยิน: – ฉันเชื่อว่าผู้เขียนที่พัฒนา TCP/IP นั้นฉลาดกว่าฉันมากและรู้ดีกว่าฉันถึงวิธีการซีเรียลไลซ์แพ็คเก็ต (เพื่อให้พวกเขาไป) ในเวลาเดียวกันก็ปรับหน้าต่างการส่ง ไม่ให้โอเวอร์โหลดเครือข่าย ให้ข้อเสนอแนะเกี่ยวกับอะไร ไม่ได้อ่านไม่นับอีกด้านหนึ่ง... ในความคิดของฉันปัญหาทั้งหมดนี้จะมีอยู่ใน UDP เพียงฉันเท่านั้นที่จะต้องเขียนโค้ดมากกว่าที่ฉันเขียนไปแล้วเพื่อนำไปใช้ในสิ่งเดียวกันด้วยตัวเองและเป็นไปได้มากที่สุด ไม่ดี ฉันไม่ชอบเขียนด้วยภาษา C เลย ไม่ต้องพูดถึงที่นั่นเลย...
З: - แค่สะดวก! ส่งเรียบร้อยและไม่ต้องรออะไรเลย - มันไม่ซิงโครนัสเลย มีการแจ้งเตือนกลับมาว่าทุกอย่างเรียบร้อยดี นั่นหมายความว่ามาถึงแล้ว ถ้าไม่มาแสดงว่าแย่
ยิน: – ฉันต้องการทั้งสองอย่าง – ฉันต้องสามารถส่งทั้งสองอย่างโดยมีการรับประกันการจัดส่งและไม่มีการรับประกันการจัดส่ง นี่เป็นสองสถานการณ์ที่แตกต่างกัน ฉันจะต้องไม่สูญเสียบันทึกบางส่วนหรือไม่สูญเสียมันไปอย่างสมเหตุสมผล
З: – ฉันจะไม่เสียเวลา. เรื่องนี้จะต้องมีการพูดคุยเพิ่มเติม ขอบคุณ
ผู้ดำเนินรายการ: – ใครมีคำถาม – ชูมือขึ้นฟ้า!
З: - สวัสดี ฉันชื่อซาชา ในช่วงกลางของรายงานความรู้สึกปรากฏว่านอกเหนือจาก TCP แล้วคุณยังสามารถใช้โซลูชันสำเร็จรูปได้ - คาฟคาบางประเภท
ยิน: – ก็... ฉันบอกคุณไปแล้วว่าฉันไม่ต้องการใช้เซิร์ฟเวอร์ระดับกลาง เพราะ... ในคาฟคา ปรากฎว่าเรามีโฮสต์นับหมื่น จริงๆ แล้ว เรามีโฮสต์มากกว่าหมื่นราย การทำคาฟคาโดยไม่มีผู้รับมอบฉันทะอาจเป็นเรื่องที่เจ็บปวดได้เช่นกัน นอกจากนี้ สิ่งสำคัญที่สุดคือ มันยังคงให้ “เวลาแฝง” มันให้โฮสต์เพิ่มเติมที่คุณต้องการ แต่ฉันไม่อยากจะมีมัน - ฉันอยากได้...
З: “แต่สุดท้ายมันก็กลายเป็นแบบนั้น”
ยิน: – ไม่ ไม่มีเจ้าภาพ! ทั้งหมดนี้ใช้ได้กับโฮสต์ Clickhouse
З: - แล้ว "Kittenhouse" ซึ่งตรงกันข้าม - เขาอาศัยอยู่ที่ไหน?
ยิน: – บนโฮสต์ Clickhouse จะไม่มีการเขียนสิ่งใดลงดิสก์
З: - เรามาสมมุติกัน.
ผู้ดำเนินรายการ: – คุณพอใจไหม? เราให้เงินเดือนคุณได้ไหม?
З: - ใช่คุณสามารถ. ในความเป็นจริงมีไม้ค้ำมากมายเพื่อให้ได้สิ่งเดียวกันและตอนนี้ - คำตอบก่อนหน้าในหัวข้อ TCP ขัดแย้งกับสถานการณ์นี้ในความคิดของฉัน ฉันรู้สึกเหมือนว่าทุกอย่างทำได้ด้วยการคุกเข่าลงโดยใช้เวลาน้อยลงมาก
ยิน: – และสาเหตุที่ฉันไม่ต้องการใช้ Kafka เนื่องจากมีการร้องเรียนค่อนข้างมากในการแชท Clickhouse Telegram เช่น ข้อความจาก Kafka หายไป ไม่ใช่จาก Kafka เอง แต่เป็นการบูรณาการของ Kafka และ Clickhaus หรือมีบางอย่างไม่เชื่อมต่อที่นั่น พูดโดยคร่าวๆ ก็คือจำเป็นต้องเขียนลูกค้าให้กับ Kafka ฉันไม่คิดว่าจะมีวิธีแก้ปัญหาที่ง่ายกว่าหรือเชื่อถือได้มากกว่านี้
З: – บอกฉันทีว่าทำไมคุณไม่ลองต่อคิวหรือรถโดยสารประจำทางบ้าง? เมื่อคุณบอกว่าเมื่อใช้อะซิงโครนัสคุณสามารถส่งบันทึกด้วยตนเองผ่านคิวและรับการตอบกลับแบบอะซิงโครนัสผ่านคิวได้หรือไม่
ยิน: – ช่วยแนะนำหน่อยว่าจะใช้คิวอะไรได้บ้าง?
З: – ใดๆ แม้ว่าจะไม่มีการรับประกันว่าเป็นไปตามระเบียบก็ตาม Redis, RMQ บางชนิด...
ยิน: – ฉันรู้สึกว่า Redis มักจะไม่สามารถดึงการแทรกปริมาณดังกล่าวได้แม้แต่ในโฮสต์เดียว (ในแง่ของเซิร์ฟเวอร์หลายเครื่อง) ที่ดึง Clickhouse ออกมา ฉันไม่สามารถสำรองข้อมูลนี้ด้วยหลักฐานใด ๆ (ฉันไม่ได้เปรียบเทียบ) แต่สำหรับฉันแล้วดูเหมือนว่า Redis ไม่ใช่ทางออกที่ดีที่สุดที่นี่ โดยหลักการแล้ว ระบบนี้ถือได้ว่าเป็นคิวข้อความชั่วคราว แต่ได้รับการปรับแต่งสำหรับ "Clickhouse" เท่านั้น
ผู้ดำเนินรายการ: – ยูริ ขอบคุณมาก ฉันเสนอให้จบคำถามและคำตอบที่นี่และบอกว่าใครที่ถามคำถามเราจะมอบหนังสือเล่มนี้ให้
ยิน: – ฉันอยากจะมอบหนังสือให้กับคนแรกที่ถามคำถาม
ผู้ดำเนินรายการ: - มหัศจรรย์! ยอดเยี่ยม! เลิศ! ขอบคุณมาก!
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com