ฉันต้องการถามคำถามเกี่ยวกับแนวปฏิบัติที่ดีที่สุดที่อธิบายไว้ในเอกสารนี้:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

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

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

mongosกระบวนการทั้งหมดเชื่อมต่อกับ 3 เซิร์ฟเวอร์การกำหนดค่าและหลาย mongo shards (พร้อมชุดแบบจำลองภายในแต่ละ shard) แม้ว่าเราจะใช้การปรับใช้ที่ใช้ร่วมกัน แต่เราก็ไม่ได้ทำลายคอลเลกชันของเราจริงๆ ในความเป็นจริงเรามีฐานข้อมูลจำนวนมากซึ่งกระจายไปทั่วเศษทั้งหมดในช่วงเวลาที่สร้าง (และนี่เป็นกรณีการใช้งานหลักของเราสำหรับการแยกส่วนในขณะนี้)

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

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

เมื่อเร็ว ๆ นี้เราเริ่มพิจารณาการจัดการคลัสเตอร์สำหรับบริการเว็บไร้สัญชาติของเราซึ่งฉันหมายถึงเครื่องมือเช่น Docker, Apache Mesos และ Kubernetes ถ้าเราใช้นักเทียบท่ามันเป็นวิธีที่ท้อแท้ในการรันมากกว่าหนึ่งกระบวนการภายในคอนเทนเนอร์ เมื่อพิจารณาถึงความจริงแล้วมันก็ยากที่จะตรวจสอบให้แน่ใจว่าแอ็พพลิเคชันเซิร์ฟเวอร์คอนเทนเนอร์และmongosคอนเทนเนอร์อยู่ในตำแหน่งเดียวกันบนโหนดฟิสิคัลเดียวกันและมีจำนวนกระบวนการเท่ากันเสมอ สิ่งนี้ทำให้ฉันสงสัยว่าวิธีปฏิบัติที่ดีที่สุดนี้ยังคงใช้กับสถาปัตยกรรมคลัสเตอร์ที่ฉันเพิ่งอธิบาย ถ้าไม่ใช่คุณสามารถแนะนำสิ่งที่จะเป็นวิธีที่ดีกว่าในการค้นหาและปรับใช้mongosกระบวนการในสถาปัตยกรรมนี้

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

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

กรณีพื้นหลัง

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

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

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

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

เวอร์ชันเฉพาะ / การใช้งานเฉพาะ

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

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

ทดสอบทดสอบจากนั้นทดสอบอีกครั้ง

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

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

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

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

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

เนื่องจากแนวปฏิบัติที่ดีที่สุดยังแนะนำว่า "กระบวนการ mongos จำนวนที่เหมาะสมจะขึ้นอยู่กับลักษณะของแอปพลิเคชันและการปรับใช้" ฉันเริ่มสงสัยว่าการใช้ mongos ของเราเหมาะสมหรือไม่

ฉันคิดว่านี่เป็นคำถามที่ในที่สุดคุณเท่านั้นที่สามารถตอบได้ตามเอกสารอ้างอิง

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

ถ้าเราใช้นักเทียบท่ามันเป็นวิธีที่ท้อแท้ในการรันมากกว่าหนึ่งกระบวนการภายในคอนเทนเนอร์

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

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

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

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

คุณสามารถดูวิดีโอนี้จากหลักสูตรออนไลน์ MongoDB M102ซึ่งครอบคลุมหัวข้อเหล่านี้และอาจต้องการลองสมัครใช้คลาส M102 สำหรับ DBAsในครั้งถัดไปที่อยู่ในเซสชัน (ฟรีออนไลน์)