การมีส่วนร่วมของยานเดกซ์ในฐานข้อมูลต่อไปนี้จะได้รับการตรวจสอบ
- คลิกเฮาส์
- โอดิสซี
- ฟื้นตัวสู่จุดเวลา (WAL-G)
- PostgreSQL (รวมถึงข้อผิดพลาดในการบันทึก, Amcheck, heapcheck)
- กรีนพลัม
วิดีโอ:
สวัสดีชาวโลก! ฉันชื่ออันเดรย์ โบโรดิน และสิ่งที่ฉันทำที่ Yandex.Cloud คือการพัฒนาฐานข้อมูลเชิงสัมพันธ์แบบเปิดเพื่อผลประโยชน์ของลูกค้า Yandex.Cloud และ Yandex.Cloud
ในการพูดคุยนี้ เราจะพูดถึงความท้าทายที่ฐานข้อมูลแบบเปิดต้องเผชิญในวงกว้าง ทำไมมันถึงสำคัญ? เพราะปัญหาเล็กๆ น้อยๆ เช่นยุงก็กลายเป็นช้าง พวกมันจะใหญ่ขึ้นเมื่อคุณมีหลายกลุ่ม
แต่นั่นไม่ใช่สิ่งสำคัญ สิ่งเหลือเชื่อเกิดขึ้น สิ่งที่เกิดขึ้นเป็นหนึ่งในล้านกรณี และในสภาพแวดล้อมแบบคลาวด์ คุณต้องเตรียมพร้อมสำหรับสิ่งนั้น เนื่องจากสิ่งที่เหลือเชื่อจะมีความเป็นไปได้สูงเมื่อมีบางสิ่งเกิดขึ้นในปริมาณมาก
แต่! ข้อดีของฐานข้อมูลแบบเปิดคืออะไร? ความจริงก็คือคุณมีโอกาสทางทฤษฎีในการจัดการกับปัญหาใดๆ คุณมีซอร์สโค้ด คุณมีความรู้ด้านการเขียนโปรแกรม เรารวมมันเข้าด้วยกันและใช้งานได้
มีวิธีใดบ้างในการทำงานกับซอฟต์แวร์โอเพ่นซอร์ส?
- แนวทางที่ตรงไปตรงมาที่สุดคือการใช้ซอฟต์แวร์ หากคุณใช้โปรโตคอล หากคุณใช้มาตรฐาน หากคุณใช้รูปแบบ หากคุณเขียนคำสั่งในซอฟต์แวร์โอเพ่นซอร์ส แสดงว่าคุณรองรับมันแล้ว
- คุณกำลังทำให้ระบบนิเวศของมันใหญ่ขึ้น คุณทำให้โอกาสในการตรวจพบจุดบกพร่องตั้งแต่เนิ่นๆ มีมากขึ้น คุณเพิ่มความน่าเชื่อถือของระบบนี้ คุณเพิ่มความพร้อมของนักพัฒนาในตลาด คุณปรับปรุงซอฟต์แวร์นี้ คุณเป็นผู้มีส่วนร่วมอยู่แล้วหากคุณเพิ่งเริ่มมีสไตล์และปรับแต่งบางอย่างที่นั่น
- อีกแนวทางหนึ่งที่เข้าใจได้คือการสนับสนุนซอฟต์แวร์โอเพ่นซอร์ส ตัวอย่างเช่น โปรแกรม Google Summer of Code ที่รู้จักกันดี เมื่อ Google จ่ายเงินให้กับนักเรียนจำนวนมากจากทั่วทุกมุมโลกด้วยเงินที่เข้าใจได้ เพื่อที่พวกเขาจะได้พัฒนาโครงการซอฟต์แวร์แบบเปิดที่ตรงตามข้อกำหนดด้านลิขสิทธิ์บางประการ
- นี่เป็นแนวทางที่น่าสนใจมากเพราะช่วยให้ซอฟต์แวร์สามารถพัฒนาได้โดยไม่ต้องหันเหความสนใจไปจากชุมชน Google ในฐานะยักษ์ใหญ่ด้านเทคโนโลยีไม่ได้บอกว่าเราต้องการฟีเจอร์นี้ เราต้องการแก้ไขข้อบกพร่องนี้ และนี่คือจุดที่เราต้องขุดลึกลงไป Google พูดว่า: “ทำในสิ่งที่คุณทำ แค่ทำงานตามที่คุณเคยทำงานต่อไป แล้วทุกอย่างจะเรียบร้อยดี”
- แนวทางต่อไปในการเข้าร่วมโอเพ่นซอร์สคือการเข้าร่วม เมื่อคุณมีปัญหาในซอฟต์แวร์โอเพ่นซอร์สและมีนักพัฒนาอยู่ นักพัฒนาของคุณจะเริ่มแก้ไขปัญหา พวกเขาเริ่มทำให้โครงสร้างพื้นฐานของคุณมีประสิทธิภาพมากขึ้น โปรแกรมของคุณเร็วขึ้นและเชื่อถือได้มากขึ้น
หนึ่งในโครงการ Yandex ที่มีชื่อเสียงที่สุดในสาขาซอฟต์แวร์โอเพ่นซอร์สคือ ClickHouse นี่คือฐานข้อมูลที่ถือกำเนิดขึ้นเพื่อตอบสนองต่อความท้าทายที่ Yandex.Metrica เผชิญอยู่
และในฐานะฐานข้อมูล มันถูกสร้างในโอเพ่นซอร์สเพื่อสร้างระบบนิเวศและพัฒนาร่วมกับนักพัฒนารายอื่น (ไม่ใช่เฉพาะในยานเดกซ์) และตอนนี้นี่เป็นโครงการใหญ่ที่มีบริษัทต่างๆ มากมายเข้ามาเกี่ยวข้อง
ใน Yandex.Cloud เราสร้าง ClickHouse ที่ด้านบนของ Yandex Object Storage เช่น ด้านบนของที่เก็บข้อมูลบนคลาวด์
เหตุใดสิ่งนี้จึงสำคัญในระบบคลาวด์ เพราะฐานข้อมูลใดๆ ทำงานในสามเหลี่ยมนี้ ในปิรามิดนี้ ในลำดับชั้นของประเภทหน่วยความจำนี้ คุณมีรีจิสเตอร์ที่รวดเร็วแต่มีขนาดเล็ก และ SSD ขนาดใหญ่แต่ช้าราคาถูก ฮาร์ดไดรฟ์ และอุปกรณ์บล็อกอื่นๆ และถ้าคุณมีประสิทธิภาพที่จุดสูงสุดของปิรามิด คุณก็จะมีฐานข้อมูลที่รวดเร็ว หากคุณมีประสิทธิภาพที่ด้านล่างของปิระมิดนี้ คุณก็จะมีฐานข้อมูลที่ปรับขนาดได้ และในเรื่องนี้การเพิ่มอีกเลเยอร์จากด้านล่างเป็นแนวทางเชิงตรรกะในการเพิ่มความสามารถในการปรับขนาดของฐานข้อมูล
มันจะทำได้อย่างไร? นี่เป็นจุดสำคัญในรายงานนี้
- เราสามารถใช้ ClickHouse บน MDS ได้ MDS เป็นอินเทอร์เฟซที่เก็บข้อมูลบนคลาวด์ Yandex ภายใน มีความซับซ้อนมากกว่าโปรโตคอล S3 ทั่วไป แต่เหมาะสำหรับอุปกรณ์บล็อกมากกว่า จะดีกว่าสำหรับการบันทึกข้อมูล มันต้องมีการเขียนโปรแกรมเพิ่มเติม โปรแกรมเมอร์จะเขียนโปรแกรม แม้จะดีก็น่าสนใจ
- S3 เป็นแนวทางทั่วไปที่ทำให้อินเทอร์เฟซง่ายขึ้นโดยมีค่าใช้จ่ายในการปรับให้เข้ากับปริมาณงานบางประเภทน้อยลง
โดยปกติแล้ว เราต้องการมอบฟังก์ชันการทำงานให้กับระบบนิเวศ ClickHouse ทั้งหมด และทำงานที่จำเป็นภายใน Yandex.Cloud เราจึงตัดสินใจทำให้แน่ใจว่าชุมชน ClickHouse ทั้งหมดจะได้รับประโยชน์จากสิ่งนี้ เราใช้ ClickHouse บน S3 ไม่ใช่ ClickHouse บน MDS และนี่เป็นงานที่เยอะมาก
อ้างอิง:
"เลเยอร์นามธรรมของระบบไฟล์"
"การบูรณาการ AWS SDK S3"
“การใช้งานพื้นฐานของอินเทอร์เฟซ IDisk สำหรับ S3”
"บูรณาการกลไกการจัดเก็บบันทึกเข้ากับอินเทอร์เฟซ IDisk"
"การสนับสนุนกลไกบันทึกสำหรับ S3 และ SeekableReadBuffer"
"รองรับ Stripe Log S3 ที่เก็บข้อมูล"
"การสนับสนุนเบื้องต้นของ Storage MergeTree สำหรับ S3"
"MergeTree รองรับ S3 เต็มรูปแบบ"
"สนับสนุน ReplicatedMergeTree บน S3"
“เพิ่มข้อมูลประจำตัวเริ่มต้นและส่วนหัวที่กำหนดเองสำหรับที่เก็บข้อมูล s3”
"S3 พร้อมการกำหนดค่าพร็อกซีแบบไดนามิก"
"S3 พร้อมตัวแก้ไขพร็อกซี"
นี่คือรายการคำขอดึงสำหรับการนำระบบไฟล์เสมือนไปใช้ใน ClickHouse นี่เป็นคำขอดึงจำนวนมาก
อ้างอิง:
"DiskS3 hardlinks การใช้งานที่เหมาะสมที่สุด"
“ไคลเอ็นต์ S3 HTTP — หลีกเลี่ยงการคัดลอกสตรีมการตอบสนองลงในหน่วยความจำ”
“หลีกเลี่ยงการคัดลอกสตรีมการตอบสนองทั้งหมดลงในหน่วยความจำใน S3 HTTP
ลูกค้า"
“ความสามารถในการแคชเครื่องหมายและไฟล์ดัชนีสำหรับดิสก์ S3”
"ย้ายส่วนต่างๆ จาก DiskLocal ไปยัง DiskS3 แบบขนาน"
แต่งานไม่ได้จบเพียงแค่นั้น หลังจากสร้างฟีเจอร์นี้แล้ว จำเป็นต้องมีการทำงานเพิ่มเติมบางอย่างเพื่อเพิ่มประสิทธิภาพฟังก์ชันการทำงานนี้
อ้างอิง:
"เพิ่มเหตุการณ์ SelectedRows และ SelectedBytes"
"เพิ่มกิจกรรมการทำโปรไฟล์จากคำขอ S3 ไปยัง system.events"
"เพิ่ม QueryTimeMicroseconds, SelectQueryTimeMicroseconds และ InsertQueryTimeMicroseconds"
จากนั้นจึงจำเป็นต้องทำให้สามารถวินิจฉัยได้ ตั้งค่าการติดตาม และทำให้สามารถจัดการได้
และทั้งหมดนี้ทำเพื่อให้ชุมชนทั้งหมด รวมถึงระบบนิเวศ ClickHouse ทั้งหมดได้รับผลของงานนี้
มาดูฐานข้อมูลธุรกรรมกันดีกว่า ฐานข้อมูล OLTP ซึ่งใกล้กับฉันเป็นการส่วนตัวมากกว่า
นี่คือแผนกพัฒนา DBMS แบบโอเพ่นซอร์ส คนเหล่านี้กำลังทำสิ่งมหัศจรรย์บนท้องถนนเพื่อปรับปรุงฐานข้อมูลแบบเปิดของธุรกรรม
หนึ่งในโปรเจ็กต์ที่ใช้ตัวอย่างที่เราสามารถพูดถึงวิธีการและสิ่งที่เราทำคือ Connection Pooler ใน Postgres
Postgres เป็นฐานข้อมูลกระบวนการ ซึ่งหมายความว่าฐานข้อมูลควรมีการเชื่อมต่อเครือข่ายน้อยที่สุดเท่าที่จะเป็นไปได้เพื่อจัดการธุรกรรม
ในทางกลับกัน ในสภาพแวดล้อมคลาวด์ สถานการณ์โดยทั่วไปคือเมื่อมีการเชื่อมต่อนับพันมาที่คลัสเตอร์เดียวในคราวเดียว และงานของตัวรวบรวมการเชื่อมต่อคือการรวมการเชื่อมต่อนับพันเข้ากับการเชื่อมต่อเซิร์ฟเวอร์จำนวนเล็กน้อย
เราสามารถพูดได้ว่าตัวรวบรวมการเชื่อมต่อคือตัวดำเนินการโทรศัพท์ที่จัดเรียงไบต์ใหม่เพื่อให้เข้าถึงฐานข้อมูลได้อย่างมีประสิทธิภาพ
น่าเสียดายที่ไม่มีคำภาษารัสเซียที่ดีสำหรับตัวรวบรวมการเชื่อมต่อ บางครั้งเรียกว่าการเชื่อมต่อมัลติเพล็กเซอร์ หากคุณรู้ว่าจะเรียกตัวรวบรวมการเชื่อมต่อว่าอะไร โปรดบอกฉันด้วยว่าฉันยินดีเป็นอย่างยิ่งที่จะพูดภาษาทางเทคนิคภาษารัสเซียที่ถูกต้อง
เราตรวจสอบตัวรวบรวมการเชื่อมต่อที่เหมาะสมสำหรับคลัสเตอร์ postgres ที่มีการจัดการ และ PgBouncer คือตัวเลือกที่ดีที่สุดสำหรับเรา แต่เราพบปัญหาหลายประการกับ PgBouncer เมื่อหลายปีก่อน Volodya Borodin รายงานว่าเราใช้ PgBouncer เราชอบทุกอย่าง แต่มีความแตกต่างและมีบางอย่างที่ต้องทำ
และเราก็ทำงาน เราแก้ไขปัญหาที่เราพบ เราแพตช์ Bouncer และพยายามส่งคำขอดึงต้นทาง แต่การใช้เธรดเดี่ยวขั้นพื้นฐานนั้นทำงานได้ยาก
เราต้องรวบรวมน้ำตกจาก Bouncers ที่ปะปะแล้ว เมื่อเรามี Bouncers แบบเธรดเดียวจำนวนมาก การเชื่อมต่อที่ชั้นบนสุดจะถูกถ่ายโอนไปยังชั้นในของ Bouncers นี่เป็นระบบที่มีการจัดการไม่ดีซึ่งยากต่อการสร้างและปรับขนาดไปมา
เราได้ข้อสรุปว่าเราได้สร้างตัวรวบรวมการเชื่อมต่อของเราเอง ซึ่งเรียกว่า Odyssey เราเขียนมันตั้งแต่เริ่มต้น
ในปี 2019 ที่การประชุม PgCon ฉันได้นำเสนอ Pooler นี้แก่ชุมชนนักพัฒนา ตอนนี้เรามีดาวน้อยกว่า 2 ดวงบน GitHub เล็กน้อย เช่น โปรเจ็กต์ยังมีชีวิตอยู่ โปรเจ็กต์นี้ได้รับความนิยม
และหากคุณสร้างคลัสเตอร์ Postgres ใน Yandex.Cloud คลัสเตอร์นั้นก็จะเป็นคลัสเตอร์ที่มี Odyssey ในตัว ซึ่งได้รับการกำหนดค่าใหม่เมื่อปรับขนาดคลัสเตอร์กลับไปกลับมา
เราเรียนรู้อะไรจากโครงการนี้? การเปิดตัวโปรเจ็กต์ที่แข่งขันกันนั้นเป็นก้าวที่ก้าวร้าวเสมอ มันเป็นมาตรการที่รุนแรงเมื่อเราบอกว่ามีปัญหาที่แก้ไขไม่เร็วพอ ไม่ได้รับการแก้ไขในช่วงเวลาที่เหมาะสมกับเรา แต่นี่เป็นมาตรการที่มีประสิทธิภาพ
PgBouncer เริ่มพัฒนาเร็วขึ้น
และตอนนี้โครงการอื่น ๆ ก็ได้ปรากฏขึ้นแล้ว ตัวอย่างเช่น pgagroal ซึ่งพัฒนาโดยนักพัฒนา Red Hat พวกเขาไล่ตามเป้าหมายที่คล้ายกันและใช้แนวคิดที่คล้ายกัน แต่แน่นอนว่ามีเฉพาะเจาะจงของตัวเองซึ่งใกล้ชิดกับนักพัฒนา pgagroal มากขึ้น
อีกกรณีหนึ่งของการทำงานร่วมกับชุมชน postgres คือการฟื้นคืนสู่ช่วงเวลาหนึ่ง นี่คือการกู้คืนหลังจากเกิดความล้มเหลว นี่คือการกู้คืนจากข้อมูลสำรอง
มีการสำรองข้อมูลจำนวนมากและแตกต่างกันทั้งหมด ผู้จำหน่าย Postgres เกือบทุกรายมีโซลูชันการสำรองข้อมูลเป็นของตัวเอง
หากคุณใช้ระบบสำรองข้อมูลทั้งหมด สร้างเมทริกซ์คุณลักษณะ และคำนวณดีเทอร์มีแนนต์ในเมทริกซ์นี้แบบตลกๆ มันจะมีค่าเป็นศูนย์ สิ่งนี้หมายความว่า? จะเป็นอย่างไรหากคุณใช้ไฟล์สำรองข้อมูลเฉพาะเจาะจง ไฟล์นั้นจะไม่สามารถประกอบจากไฟล์อื่นๆ ทั้งหมดได้ มีเอกลักษณ์เฉพาะตัวในการนำไปปฏิบัติ มีเอกลักษณ์เฉพาะตัวในวัตถุประสงค์ มีเอกลักษณ์เฉพาะตัวในแนวความคิดที่ฝังอยู่ในนั้น และทั้งหมดนี้มีความเฉพาะเจาะจง
ขณะที่เรากำลังแก้ไขปัญหานี้ CitusData ได้เปิดตัวโครงการ WAL-G นี่คือระบบสำรองข้อมูลที่สร้างขึ้นโดยคำนึงถึงสภาพแวดล้อมคลาวด์ ตอนนี้ CitusData เป็นส่วนหนึ่งของ Microsoft แล้ว และในขณะนั้น เราชอบไอเดียที่วางไว้ใน WAL-G รุ่นแรกๆ มาก และเราเริ่มมีส่วนร่วมในโครงการนี้
ขณะนี้มีนักพัฒนาหลายสิบรายในโครงการนี้ แต่ผู้ร่วมให้ข้อมูล 10 อันดับแรกของ WAL-G ได้แก่ Yandexoids 6 ราย เรานำความคิดของเรามากมายไปที่นั่น และแน่นอนว่าเราได้นำมันไปใช้เอง ทดสอบด้วยตัวเอง นำมันออกสู่การผลิตด้วยตัวเราเอง เราใช้มันเอง เราเองก็คิดออกว่าจะไปที่ไหนต่อไป ในขณะที่โต้ตอบกับชุมชน WAL-G ขนาดใหญ่
และจากมุมมองของเรา ขณะนี้ระบบสำรองข้อมูลนี้ รวมถึงการคำนึงถึงความพยายามของเรา กลายเป็นระบบที่เหมาะสมที่สุดสำหรับสภาพแวดล้อมคลาวด์แล้ว นี่เป็นต้นทุนที่ดีที่สุดในการสำรองข้อมูล Postgres ในระบบคลาวด์
มันหมายความว่าอะไร? เรากำลังส่งเสริมแนวคิดที่ค่อนข้างใหญ่: การสำรองข้อมูลควรมีความปลอดภัย ราคาถูกในการใช้งาน และกู้คืนได้เร็วที่สุด
เหตุใดจึงต้องดำเนินการราคาถูก? เมื่อไม่มีอะไรเสียหาย คุณไม่ควรรู้ว่าคุณมีข้อมูลสำรองอยู่ ทุกอย่างทำงานได้ดี คุณสิ้นเปลือง CPU น้อยที่สุดเท่าที่จะเป็นไปได้ คุณใช้ทรัพยากรดิสก์ของคุณให้น้อยที่สุดเท่าที่จะเป็นไปได้ และส่งไบต์ไปยังเครือข่ายน้อยที่สุดเท่าที่จะเป็นไปได้ เพื่อไม่ให้รบกวนเพย์โหลดของบริการอันมีค่าของคุณ
และเมื่อทุกอย่างพัง เช่น ผู้ดูแลระบบทิ้งข้อมูล มีบางอย่างผิดพลาด และคุณต้องย้อนเวลากลับไปอย่างเร่งด่วน คุณก็กู้คืนได้พร้อมเงินทั้งหมด เพราะคุณต้องการให้ข้อมูลของคุณกลับมาอย่างรวดเร็วและครบถ้วน
และเราก็ส่งเสริมแนวคิดง่ายๆ นี้ และสำหรับเราแล้วดูเหมือนว่าเราสามารถนำไปปฏิบัติได้
แต่นั่นไม่ใช่ทั้งหมด เราต้องการสิ่งเล็กๆ อีกอย่างหนึ่ง เราต้องการฐานข้อมูลที่แตกต่างกันมากมาย ลูกค้าบางรายของเราไม่ได้ใช้ Postgres บางคนใช้ MySQL, MongoDB ในชุมชน นักพัฒนารายอื่นได้สนับสนุน FoundationDB และรายการนี้ก็มีการขยายตัวอย่างต่อเนื่อง
ชุมชนชอบแนวคิดของฐานข้อมูลที่ทำงานในสภาพแวดล้อมที่มีการจัดการในระบบคลาวด์ และนักพัฒนาก็ดูแลรักษาฐานข้อมูลของตน ซึ่งสามารถสำรองข้อมูลได้อย่างสม่ำเสมอพร้อมกับ Postgres ด้วยระบบสำรองข้อมูลของเรา
เราเรียนรู้อะไรจากเรื่องนี้? ผลิตภัณฑ์ของเราในฐานะแผนกพัฒนาไม่ใช่บรรทัดของโค้ด ไม่ใช่คำสั่ง ไม่ใช่ไฟล์ ผลิตภัณฑ์ของเราไม่ได้ดึงคำขอ เหล่านี้คือแนวคิดที่เราถ่ายทอดสู่ชุมชน นี่คือความเชี่ยวชาญทางเทคโนโลยีและการขับเคลื่อนของเทคโนโลยีไปสู่สภาพแวดล้อมคลาวด์
มีฐานข้อมูลเช่น Postgres ฉันชอบแกน Postgres มากที่สุด ฉันใช้เวลามากมายในการพัฒนาแกนหลักของ Postgres ร่วมกับชุมชน
แต่ที่นี่ต้องบอกว่า Yandex.Cloud มีการติดตั้งฐานข้อมูลที่ได้รับการจัดการภายใน และมันเริ่มต้นเมื่อนานมาแล้วใน Yandex.Mail ความเชี่ยวชาญที่นำไปสู่การจัดการ Postgres ในตอนนี้ถูกสั่งสมมาเมื่อเมลต้องการย้ายไปยัง Postgres
เมลมีข้อกำหนดที่คล้ายกันมากกับระบบคลาวด์ คุณต้องสามารถปรับขนาดไปสู่การเติบโตแบบทวีคูณที่ไม่คาดคิด ณ จุดใดก็ได้ในข้อมูลของคุณ และเมลก็เต็มไปด้วยกล่องจดหมายหลายร้อยล้านกล่องของผู้ใช้จำนวนมากที่ส่งคำขอจำนวนมากอย่างต่อเนื่อง
และนี่เป็นความท้าทายที่สำคัญสำหรับทีมที่กำลังพัฒนา Postgres ในตอนนั้นปัญหาที่เราพบก็ถูกรายงานไปยังชุมชน และปัญหาเหล่านี้ได้รับการแก้ไขและแก้ไขโดยชุมชนในบางสถานที่แม้ในระดับการสนับสนุนแบบชำระเงินสำหรับฐานข้อมูลอื่น ๆ และดียิ่งขึ้นไปอีก นั่นคือคุณสามารถส่งจดหมายถึงแฮ็กเกอร์ PgSQL และรับการตอบกลับภายใน 40 นาที การสนับสนุนแบบชำระเงินในบางฐานข้อมูลอาจคิดว่ามีสิ่งที่สำคัญมากกว่าจุดบกพร่องของคุณ
ขณะนี้การติดตั้ง Postgres ภายในมีข้อมูลขนาดบางเพตะไบต์ นี่คือคำขอหลายล้านคำขอต่อวินาที เหล่านี้เป็นกระจุกนับพัน มันมีขนาดใหญ่มาก
แต่มีความแตกต่างกันนิดหน่อย มันไม่ได้อยู่บนไดรฟ์เครือข่ายที่หรูหรา แต่อยู่บนฮาร์ดแวร์ที่ค่อนข้างเรียบง่าย และมีสภาพแวดล้อมการทดสอบสำหรับสิ่งใหม่ที่น่าสนใจโดยเฉพาะ
และในช่วงเวลาหนึ่งในสภาพแวดล้อมการทดสอบ เราได้รับข้อความระบุว่าค่าคงที่ภายในของดัชนีฐานข้อมูลถูกละเมิด
ค่าคงที่คือความสัมพันธ์บางประเภทที่เราคาดหวังว่าจะมีอยู่เสมอ
สถานการณ์ที่สำคัญมากสำหรับเรา แสดงว่าข้อมูลบางส่วนอาจสูญหาย และการสูญหายของข้อมูลถือเป็นหายนะอย่างยิ่ง
แนวคิดทั่วไปที่เราปฏิบัติตามในฐานข้อมูลที่มีการจัดการก็คือ แม้จะต้องใช้ความพยายามมาก แต่ก็ยังเป็นเรื่องยากที่จะสูญเสียข้อมูล แม้ว่าคุณจะจงใจลบออก แต่คุณก็ยังต้องเพิกเฉยต่อการขาดหายไปของพวกเขาเป็นระยะเวลานาน ความปลอดภัยของข้อมูลเป็นศาสนาที่เราปฏิบัติตามค่อนข้างขยัน
และนี่คือสถานการณ์ที่เกิดขึ้นซึ่งบ่งบอกว่าอาจมีสถานการณ์ที่เราอาจไม่พร้อม และเราก็เริ่มเตรียมตัวสำหรับสถานการณ์นี้
สิ่งแรกที่เราทำคือฝังท่อนไม้จากกระจุกนับพันเหล่านี้ เราพบว่าคลัสเตอร์ใดที่อยู่บนดิสก์ที่มีเฟิร์มแวร์ที่มีปัญหาซึ่งทำให้การอัปเดตหน้าข้อมูลสูญเสียไป ทำเครื่องหมายรหัสข้อมูล Postgres ทั้งหมด และเราได้ทำเครื่องหมายข้อความเหล่านั้นที่บ่งบอกถึงการละเมิดค่าคงที่ภายในด้วยโค้ดที่ออกแบบมาเพื่อตรวจจับความเสียหายของข้อมูล
แพตช์นี้ได้รับการยอมรับจากชุมชนโดยไม่ต้องมีการพูดคุยกันมากนัก เพราะในแต่ละกรณี เห็นได้ชัดว่ามีสิ่งเลวร้ายเกิดขึ้นและจำเป็นต้องรายงานไปยังบันทึก
หลังจากนี้ เรามาถึงจุดที่เรามีการตรวจสอบที่สแกนบันทึก และในกรณีมีข้อความน่าสงสัยเขาจะปลุกเจ้าหน้าที่เวรให้เจ้าหน้าที่เวรซ่อมให้
แต่! การสแกนบันทึกเป็นการดำเนินการที่ประหยัดบนคลัสเตอร์เดียวและมีราคาแพงมากสำหรับหนึ่งพันคลัสเตอร์
เราเขียนส่วนขยายที่เรียกว่า . มันสร้างมุมมองของฐานข้อมูลซึ่งคุณสามารถเลือกสถิติเกี่ยวกับข้อผิดพลาดในอดีตได้อย่างรวดเร็วและประหยัด และถ้าเราจำเป็นต้องปลุกเจ้าหน้าที่ประจำเวร เราจะรู้เรื่องนี้โดยไม่ต้องสแกนไฟล์กิกะไบต์ แต่โดยการแยกไบต์สองสามไบต์ออกจากตารางแฮช
ส่วนขยายนี้ถูกนำมาใช้ เช่น ในพื้นที่เก็บข้อมูลสำหรับ . หากต้องการใช้งานสามารถติดตั้งเองได้ แน่นอนว่ามันเป็นโอเพ่นซอร์ส
แต่นั่นไม่ใช่ทั้งหมด เราเริ่มใช้ Amcheck ซึ่งเป็นส่วนขยายที่สร้างโดยชุมชน เพื่อค้นหาการละเมิดที่ไม่คงที่ในดัชนี
และเราพบว่าหากคุณใช้งานในปริมาณมาก ก็จะมีข้อบกพร่องอยู่ เราเริ่มซ่อมแซมพวกเขา การแก้ไขของเราได้รับการยอมรับแล้ว
เราค้นพบว่าส่วนขยายนี้ไม่สามารถวิเคราะห์ดัชนี GiST และ GIT ได้ เราทำให้พวกเขาสนับสนุน แต่ชุมชนยังคงหารือเกี่ยวกับการสนับสนุนนี้ เนื่องจากนี่เป็นฟังก์ชันที่ค่อนข้างใหม่และมีรายละเอียดมากมาย
และเรายังค้นพบด้วยว่าเมื่อตรวจสอบดัชนีสำหรับการละเมิดผู้นำการจำลองแบบบนต้นแบบ ทุกอย่างทำงานได้ดี แต่บนแบบจำลองบนผู้ติดตาม การค้นหาความเสียหายไม่ได้ผลมากนัก ไม่ใช่ค่าคงที่ทั้งหมดจะถูกตรวจสอบ และค่าคงที่ตัวหนึ่งรบกวนเรามาก และเราใช้เวลาหนึ่งปีครึ่งในการสื่อสารกับชุมชนเพื่อให้สามารถตรวจสอบแบบจำลองนี้ได้
เราเขียนโค้ดที่ควรเป็นไปตาม can... protocols ทั้งหมด เราได้พูดคุยกันเกี่ยวกับแพตช์นี้กับ Peter Gaghan จาก Crunchy Data มาระยะหนึ่งแล้ว เขาต้องแก้ไข B-tree ที่มีอยู่ใน Postgres เล็กน้อยเพื่อที่จะยอมรับแพตช์นี้ เขาได้รับการยอมรับ และตอนนี้การตรวจสอบดัชนีบนแบบจำลองก็มีประสิทธิภาพเพียงพอในการตรวจจับการละเมิดที่เราพบ นั่นคือการละเมิดเหล่านี้อาจมีสาเหตุมาจากข้อผิดพลาดในเฟิร์มแวร์ของดิสก์, บั๊กใน Postgres, บั๊กในเคอร์เนล Linux และปัญหาฮาร์ดแวร์ รายการแหล่งที่มาของปัญหาที่เรากำลังเตรียมอยู่ค่อนข้างกว้างขวาง
แต่นอกเหนือจากดัชนีแล้วยังมีส่วนหนึ่งเช่นฮีปนั่นคือตำแหน่งที่เก็บข้อมูล และมีค่าคงที่ที่สามารถตรวจสอบได้ไม่มากนัก
เรามีส่วนขยายที่เรียกว่า Heapcheck เราเริ่มพัฒนามัน และควบคู่ไปกับเรา บริษัท EnterpriseDB ก็เริ่มเขียนโมดูลซึ่งพวกเขาเรียกว่า Heapcheck ในลักษณะเดียวกัน มีเพียงเราเท่านั้นที่เรียกมันว่า PgHeapcheck และพวกเขาก็เรียกมันว่า Heapcheck พวกเขามีฟังก์ชั่นที่คล้ายกัน มีลายเซ็นที่แตกต่างกันเล็กน้อย แต่มีแนวคิดที่เหมือนกัน พวกเขานำไปใช้ให้ดีขึ้นเล็กน้อยในบางแห่ง และพวกเขาก็โพสต์มันในโอเพ่นซอร์สมาก่อน
และตอนนี้เรากำลังพัฒนาการขยายตัวของพวกเขา เพราะมันไม่ใช่การขยายตัวของพวกเขาอีกต่อไป แต่เป็นการขยายตัวของชุมชน และในอนาคตนี่เป็นส่วนหนึ่งของเคอร์เนลที่จะจัดส่งให้กับทุกคนเพื่อให้พวกเขาทราบถึงปัญหาในอนาคตล่วงหน้า
ในบางสถานที่ เรายังได้ข้อสรุปว่าเรามีผลบวกลวงในระบบการตรวจสอบของเรา เช่น ระบบ 1C เมื่อใช้ฐานข้อมูล บางครั้ง Postgres จะเขียนข้อมูลลงในฐานข้อมูลที่สามารถอ่านได้ แต่ pg_dump ไม่สามารถอ่านได้
สถานการณ์นี้ดูเหมือนเป็นการทุจริตต่อระบบตรวจจับปัญหาของเรา เจ้าหน้าที่ประจำการก็ตื่นขึ้น เจ้าหน้าที่ปฏิบัติหน้าที่ดูว่าเกิดอะไรขึ้น สักพักก็มีลูกค้ามาบอกว่ามีปัญหา เจ้าหน้าที่ก็อธิบายว่าปัญหาคืออะไร แต่ปัญหาอยู่ที่แกน Postgres
ฉันพบการสนทนาเกี่ยวกับคุณลักษณะนี้ และเขาเขียนว่าเราเจอฟีเจอร์นี้ และมันก็ไม่น่าพอใจ มีคนตื่นขึ้นมาตอนกลางคืนเพื่อดูว่ามันคืออะไร
ชุมชนตอบว่า “โอ้ เราจำเป็นต้องแก้ไขมันจริงๆ”
ฉันมีการเปรียบเทียบง่ายๆ หากคุณกำลังเดินในรองเท้าที่มีเม็ดทรายอยู่ในนั้น โดยหลักการแล้ว คุณสามารถก้าวต่อไปได้ - ไม่มีปัญหา หากคุณขายรองเท้าบู๊ตให้คนหลายพันคน มาทำรองเท้าบูทแบบไม่มีทรายกันดีกว่า และหากผู้ใช้รองเท้าของคุณคนใดคนหนึ่งกำลังจะวิ่งมาราธอน คุณจะต้องสร้างรองเท้าที่ดีมาก จากนั้นจึงปรับขนาดให้เหมาะกับผู้ใช้ทั้งหมดของคุณ และผู้ใช้ที่ไม่คาดคิดก็จะอยู่ในสภาพแวดล้อมคลาวด์เสมอ มีผู้ใช้ที่ใช้ประโยชน์จากคลัสเตอร์ด้วยวิธีดั้งเดิมอยู่เสมอ คุณต้องเตรียมตัวสำหรับสิ่งนี้เสมอ
เราได้เรียนรู้อะไรที่นี่? เราเรียนรู้สิ่งง่ายๆ สิ่งที่สำคัญที่สุดคือการอธิบายให้ชุมชนทราบว่ามีปัญหา หากชุมชนตระหนักถึงปัญหา การแข่งขันตามธรรมชาติก็จะเกิดขึ้นเพื่อแก้ไขปัญหา เพราะใครๆ ก็อยากแก้ปัญหาสำคัญ ผู้ขายทั้งหมด แฮกเกอร์ทุกคนเข้าใจว่าตนเองสามารถก้าวเข้าสู่คราดนี้ได้ ดังนั้นพวกเขาต้องการกำจัดพวกเขา
หากคุณกำลังแก้ไขปัญหาอยู่ แต่มันไม่ได้รบกวนใครเลยนอกจากคุณ แต่คุณแก้ไขปัญหานั้นอย่างเป็นระบบและท้ายที่สุดก็ถือว่าเป็นปัญหา คำขอดึงของคุณก็จะได้รับการยอมรับอย่างแน่นอน โปรแกรมแก้ไขของคุณจะได้รับการยอมรับ การปรับปรุงของคุณหรือแม้แต่คำร้องขอการปรับปรุงจะได้รับการตรวจสอบโดยชุมชน ท้ายที่สุดแล้ว เราสร้างฐานข้อมูลให้ดีขึ้นเพื่อกันและกัน
ฐานข้อมูลที่น่าสนใจคือ Greenplum มันเป็นฐานข้อมูลแบบขนานสูงที่ใช้ฐานรหัส Postgres ซึ่งฉันคุ้นเคยมาก
และ Greenplum มีฟังก์ชันที่น่าสนใจ - ผนวกตารางที่ปรับให้เหมาะสมที่สุด นี่คือตารางที่คุณสามารถเพิ่มได้อย่างรวดเร็ว อาจเป็นได้ทั้งแบบเรียงเป็นแนวหรือแบบแถว
แต่ไม่มีการรวมกลุ่มนั่นคือ ไม่มีฟังก์ชันที่คุณสามารถจัดเรียงข้อมูลที่อยู่ในตารางตามลำดับที่อยู่ในดัชนีใดดัชนีหนึ่ง
พวกจากแท็กซี่มาหาฉันแล้วพูดว่า: "อันเดรย์ คุณรู้จัก Postgres นะ และนี่ก็เกือบจะเหมือนกัน เปลี่ยนเป็น 20 นาที คุณรับมันและทำมัน” ฉันคิดว่าใช่ ฉันรู้จัก Postgres สลับกันเป็นเวลา 20 นาที - ฉันต้องทำสิ่งนี้
แต่ไม่ มันไม่ใช่ 20 นาที ฉันเขียนมันเป็นเวลาหลายเดือน ที่การประชุม PgConf.Russia ฉันได้ติดต่อ Heikki Linakangas จาก Pivotal และถามว่า: "จะมีปัญหาใดๆ เกี่ยวกับเรื่องนี้หรือไม่? เหตุใดจึงไม่มีการรวมกลุ่มตารางที่ปรับให้เหมาะสมต่อท้าย” เขาพูดว่า: “คุณนำข้อมูลไป คุณจัดเรียงคุณจัดเรียงใหม่ มันก็แค่งาน" ฉัน: "โอ้ใช่คุณเพียงแค่ต้องรับมันและทำมัน" เขาพูดว่า: “ใช่แล้ว เราจำเป็นต้องมีมือที่ว่างเพื่อทำสิ่งนี้” ฉันคิดว่าฉันต้องทำเช่นนี้อย่างแน่นอน
และไม่กี่เดือนต่อมา ฉันก็ส่งคำขอดึงที่ใช้ฟังก์ชันนี้ คำขอดึงนี้ได้รับการตรวจสอบโดย Pivotal ร่วมกับชุมชน แน่นอนว่ายังมีข้อบกพร่องอยู่
แต่สิ่งที่น่าสนใจที่สุดคือเมื่อมีการรวมคำขอดึงนี้เข้าด้วยกัน ก็พบข้อบกพร่องใน Greenplum เอง เราพบว่าตารางฮีปบางครั้งทำลายการทำธุรกรรมเมื่อทำคลัสเตอร์ และนี่คือสิ่งที่ต้องแก้ไข และเธออยู่ในสถานที่ที่ฉันเพิ่งสัมผัส และปฏิกิริยาตามธรรมชาติของฉันคือ – โอเค ให้ฉันทำสิ่งนี้ด้วย
ฉันแก้ไขข้อผิดพลาดนี้แล้ว ส่งคำขอดึงไปยังผู้ให้บริการซ่อมแล้ว เขาถูกฆ่าตาย.
หลังจากนั้นปรากฎว่าจำเป็นต้องได้รับฟังก์ชันนี้ในเวอร์ชัน Greenplum สำหรับ PostgreSQL 12 นั่นคือการผจญภัย 20 นาทีดำเนินต่อไปด้วยการผจญภัยใหม่ที่น่าสนใจ เป็นเรื่องที่น่าสนใจที่ได้สัมผัสกับการพัฒนาในปัจจุบัน ซึ่งชุมชนกำลังตัดคุณสมบัติใหม่และที่สำคัญที่สุดออกไป มันแช่แข็งแล้ว
แต่มันไม่ได้จบเพียงแค่นั้น หลังจากทุกอย่าง ปรากฎว่าเราจำเป็นต้องเขียนเอกสารสำหรับเรื่องทั้งหมดนี้
ฉันเริ่มเขียนเอกสาร โชคดีที่มีนักทำสารคดีจาก Pivotal มาด้วย ภาษาอังกฤษเป็นภาษาแม่ของพวกเขา พวกเขาช่วยฉันเรื่องเอกสาร ที่จริงแล้วพวกเขาเองก็เขียนสิ่งที่ฉันเสนอใหม่เป็นภาษาอังกฤษจริงๆ
และดูเหมือนว่าการผจญภัยจะสิ้นสุดลงแล้ว แล้วคุณรู้ไหมว่าเกิดอะไรขึ้น? พวกบนแท็กซี่มาหาฉันแล้วพูดว่า: “ยังมีการผจญภัยอีกสองครั้ง ครั้งละ 10 นาที” และฉันควรบอกพวกเขาอย่างไร? ฉันบอกว่าตอนนี้ฉันจะรายงานตามขนาด จากนั้นเราจะได้เห็นการผจญภัยของคุณ เพราะนี่เป็นงานที่น่าสนใจ
เราเรียนรู้อะไรจากกรณีนี้? เนื่องจากการทำงานกับโอเพ่นซอร์สจะต้องทำงานร่วมกับบุคคลใดบุคคลหนึ่งเสมอ จึงทำงานร่วมกับชุมชนอยู่เสมอ เพราะในทุกขั้นตอน ฉันทำงานร่วมกับนักพัฒนา บางคนผู้ทดสอบ แฮกเกอร์ บางคนคนทำสารคดี และสถาปนิกบางคน ฉันไม่ได้ทำงานกับกรีนพลัม ฉันทำงานกับคนแถวๆ กรีนพลัม
แต่! มีอีกจุดสำคัญ - มันเป็นแค่งาน คือมาดื่มกาแฟเขียนโค้ด ค่าคงที่อย่างง่ายทุกประเภทใช้งานได้ ทำตามปกติ-มันจะดี! และเป็นงานที่น่าสนใจทีเดียว มีการร้องของานนี้จากไคลเอนต์ Yandex.Cloud ผู้ใช้คลัสเตอร์ของเราทั้งใน Yandex และภายนอก และฉันคิดว่าจำนวนโครงการที่เราเข้าร่วมจะเพิ่มขึ้นและการมีส่วนร่วมของเราก็จะเพิ่มขึ้นเช่นกัน
นั่นคือทั้งหมดที่ มาดูคำถามกันดีกว่า
ช่วงคำถาม
สวัสดี! เรามีคำถามและคำตอบอีกครั้ง และในสตูดิโอ Andrei Borodin นี่คือบุคคลที่เพิ่งบอกคุณเกี่ยวกับการมีส่วนร่วมของ Yandex.Cloud และ Yandex ในโอเพ่นซอร์ส รายงานของเราในตอนนี้ไม่ได้เกี่ยวกับคลาวด์ทั้งหมด แต่ในขณะเดียวกัน เราก็ใช้เทคโนโลยีดังกล่าว หากไม่มีสิ่งที่คุณทำใน Yandex ก็จะไม่มีบริการใน Yandex.Cloud ดังนั้นขอขอบคุณจากฉันเป็นการส่วนตัว และคำถามแรกจากการออกอากาศว่า “แต่ละโปรเจ็กต์ที่คุณพูดถึงเขียนเกี่ยวกับอะไรบ้าง?”
ระบบสำรองข้อมูลใน WAL-G เขียนเป็นภาษา Go นี่เป็นหนึ่งในโครงการใหม่ที่เราได้ดำเนินการ เขาอายุเพียง 3 ขวบเท่านั้น และฐานข้อมูลมักจะเกี่ยวกับความน่าเชื่อถือ และนั่นหมายความว่าฐานข้อมูลค่อนข้างเก่าและมักจะเขียนด้วยภาษา C โครงการ Postgres เริ่มต้นเมื่อประมาณ 30 ปีที่แล้ว ดังนั้น C89 จึงเป็นตัวเลือกที่เหมาะสม และมี Postgres เขียนอยู่บนนั้น ฐานข้อมูลสมัยใหม่ เช่น ClickHouse มักจะเขียนด้วยภาษา C++ การพัฒนาระบบทั้งหมดใช้ภาษา C และ C++
คำถามจากผู้จัดการฝ่ายการเงินของเราซึ่งรับผิดชอบค่าใช้จ่ายที่ Cloud: “เหตุใด Cloud จึงทุ่มเงินเพื่อสนับสนุนโอเพ่นซอร์ส”
มีคำตอบง่ายๆ สำหรับผู้จัดการการเงินอยู่ที่นี่ เราทำเช่นนี้เพื่อปรับปรุงบริการของเราให้ดีขึ้น เราจะทำได้ดีกว่านี้ในด้านใดบ้าง? เราสามารถทำสิ่งต่าง ๆ ได้อย่างมีประสิทธิภาพมากขึ้น เร็วขึ้น และทำให้สิ่งต่าง ๆ สามารถปรับขนาดได้มากขึ้น แต่สำหรับเรา เรื่องราวนี้เกี่ยวกับความน่าเชื่อถือเป็นหลัก ตัวอย่างเช่น ในระบบสำรองข้อมูล เราจะตรวจสอบแพตช์ที่ใช้กับมัน 100% เรารู้ว่ารหัสคืออะไร และเราก็สบายใจมากขึ้นที่จะเปิดตัวเวอร์ชันใหม่สู่การใช้งานจริง ประการแรกคือเกี่ยวกับความมั่นใจ ความพร้อมในการพัฒนา และเกี่ยวกับความน่าเชื่อถือ
คำถามอื่น: “ข้อกำหนดของผู้ใช้ภายนอกที่อาศัยอยู่ใน Yandex.Cloud แตกต่างจากผู้ใช้ภายในที่อาศัยอยู่ในคลาวด์ภายในหรือไม่”
แน่นอนว่าโปรไฟล์โหลดแตกต่างออกไป แต่จากมุมมองของแผนกของฉัน กรณีพิเศษและน่าสนใจทั้งหมดถูกสร้างขึ้นจากภาระงานที่ไม่ได้มาตรฐาน นักพัฒนาที่มีจินตนาการ นักพัฒนาที่ทำสิ่งที่ไม่คาดคิดก็มีแนวโน้มที่จะพบได้ทั้งภายในและภายนอก ในเรื่องนี้เราทุกคนก็ประมาณเดียวกัน และอาจเป็นไปได้ว่าคุณลักษณะที่สำคัญเพียงอย่างเดียวในการทำงานของฐานข้อมูล Yandex ก็คือภายใน Yandex เรามีการสอน เมื่อถึงจุดหนึ่ง โซนความพร้อมใช้งานบางแห่งจะตกอยู่ในเงามืดโดยสิ้นเชิง และบริการ Yandex ทั้งหมดจะต้องทำงานต่อไปได้แม้ว่าจะเป็นเช่นนี้ก็ตาม นี่เป็นข้อแตกต่างเล็กน้อย แต่มันสร้างการพัฒนางานวิจัยมากมายที่อินเทอร์เฟซของฐานข้อมูลและสแต็กเครือข่าย มิฉะนั้น การติดตั้งภายนอกและภายในจะสร้างคำขอคุณลักษณะเดียวกันและคำขอที่คล้ายกันเพื่อปรับปรุงความน่าเชื่อถือและประสิทธิภาพ
คำถามถัดไป: “คุณรู้สึกอย่างไรเป็นการส่วนตัวเกี่ยวกับความจริงที่ว่าสิ่งที่คุณทำส่วนใหญ่ถูกใช้โดยคลาวด์อื่น” เราจะไม่ระบุชื่อที่เฉพาะเจาะจง แต่หลายโครงการที่ทำใน Yandex.Cloud ถูกใช้ในระบบคลาวด์ของผู้อื่น
ที่นี่หนาว. ประการแรก มันเป็นสัญญาณว่าเราได้ทำสิ่งที่ถูกต้องแล้ว และมันทำลายอัตตา และเรามั่นใจมากขึ้นว่าเราตัดสินใจถูกต้องแล้ว ในทางกลับกัน นี่คือความหวังว่าในอนาคตสิ่งนี้จะนำแนวคิดใหม่ คำขอใหม่จากผู้ใช้บุคคลที่สามมาให้เรา ปัญหาส่วนใหญ่บน GitHub สร้างขึ้นโดยผู้ดูแลระบบแต่ละคน DBA แต่ละคน สถาปนิกแต่ละคน วิศวกรแต่ละคน แต่บางครั้งผู้ที่มีประสบการณ์อย่างเป็นระบบมักเข้ามาบอกว่าใน 30% ของบางกรณี เราประสบปัญหานี้ และลองมาคิดหาวิธีแก้ไขกัน นี่คือสิ่งที่เรารอคอยมากที่สุด เราหวังเป็นอย่างยิ่งว่าจะได้แบ่งปันประสบการณ์กับแพลตฟอร์มคลาวด์อื่นๆ
คุณพูดมากเกี่ยวกับการวิ่งมาราธอน ฉันรู้ว่าคุณวิ่งมาราธอนในมอสโก ผลที่ตามมา? แซงหน้าพวกจาก PostgreSQL เหรอ?
ไม่ Oleg Bartunov วิ่งเร็วมาก เขาเสร็จก่อนฉันหนึ่งชั่วโมง โดยรวมแล้วฉันพอใจกับระยะทางที่ได้มา สำหรับฉัน แค่จบสกอร์ก็ถือเป็นความสำเร็จแล้ว โดยรวมแล้ว น่าแปลกใจที่มีนักวิ่งจำนวนมากในชุมชน postgres สำหรับฉันดูเหมือนว่ามีความสัมพันธ์บางอย่างระหว่างกีฬาแอโรบิกกับความปรารถนาในการเขียนโปรแกรมระบบ
คุณกำลังบอกว่าไม่มีนักวิ่งที่ ClickHouse หรือไม่?
ฉันรู้แน่ว่าพวกเขาอยู่ที่นั่น ClickHouse ยังเป็นฐานข้อมูล ยังไงก็ตามตอนนี้ Oleg กำลังเขียนถึงฉัน:“ เราไปวิ่งตามรายงานกันไหม?” นี่เป็นความคิดที่ดี
อีกคำถามจากการออกอากาศของ Nikita: “ทำไมคุณถึงแก้ไขข้อผิดพลาดใน Greenplum ด้วยตัวเองและไม่มอบให้กับรุ่นน้อง?” จริงอยู่ ยังไม่ชัดเจนว่าจุดบกพร่องคืออะไรและบริการใด แต่อาจหมายถึงจุดบกพร่องที่คุณพูดถึง
ใช่ โดยหลักการแล้วสามารถมอบให้กับใครบางคนได้ มันเป็นเพียงรหัสที่ฉันเพิ่งเปลี่ยน และเป็นเรื่องปกติที่จะทำมันต่อทันที โดยหลักการแล้ว แนวคิดในการแบ่งปันความเชี่ยวชาญกับทีมงานถือเป็นแนวคิดที่ดี เราจะแบ่งปันงานของ Greenplum ให้กับสมาชิกทุกคนในแผนกของเราอย่างแน่นอน
เนื่องจากเรากำลังพูดถึงรุ่นน้อง ต่อไปนี้เป็นคำถาม บุคคลนั้นตัดสินใจสร้างคอมมิตแรกใน Postgres เขาต้องทำอะไรเพื่อกระทำการครั้งแรก?
นี่เป็นคำถามที่น่าสนใจ: “จะเริ่มต้นที่ไหน?” โดยปกติแล้วการเริ่มต้นด้วยบางสิ่งในเคอร์เนลมักจะค่อนข้างยาก ตัวอย่างเช่น ใน Postgres จะมีรายการสิ่งที่ต้องทำ แต่อันที่จริงนี่คือสิ่งที่พวกเขาพยายามทำแต่ไม่สำเร็จ สิ่งเหล่านี้เป็นสิ่งที่ซับซ้อน และโดยปกติแล้วคุณจะพบยูทิลิตี้บางอย่างในระบบนิเวศ ซึ่งเป็นส่วนขยายบางส่วนที่สามารถปรับปรุงได้ ซึ่งดึงดูดความสนใจจากนักพัฒนาเคอร์เนลน้อยลง และด้วยเหตุนี้จึงมีจุดเติบโตอีกมาก ที่โปรแกรม Google Summer of Code ทุกปีชุมชน postgres จะนำเสนอหัวข้อต่างๆ มากมายที่สามารถแก้ไขได้ ฉันคิดว่าปีนี้เรามีนักเรียนสามคน มีคนหนึ่งเขียนใน WAL-G ในหัวข้อที่สำคัญสำหรับยานเดกซ์ ใน Greenplum ทุกอย่างจะง่ายกว่าในชุมชน Postgres เนื่องจากแฮกเกอร์ของ Greenplum ปฏิบัติต่อคำขอดึงข้อมูลได้เป็นอย่างดี และเริ่มตรวจสอบได้ทันที การส่งแพตช์ไปที่ Postgres นั้นใช้เวลาหลายเดือน แต่ Greenplum จะมาในหนึ่งวันและดูว่าคุณได้ทำอะไรไปบ้าง อีกประการหนึ่งคือกรีนพลัมจำเป็นต้องแก้ไขปัญหาในปัจจุบัน Greenplum ไม่ได้ใช้กันอย่างแพร่หลาย ดังนั้นการค้นหาปัญหาของคุณจึงค่อนข้างยาก และก่อนอื่นเลย แน่นอนว่าเราต้องแก้ไขปัญหาก่อน
ที่มา: will.com