จะเกิดอะไรขึ้นถ้ามีการแทรกใน MongoDB มากเกินไป? จะมั่นใจได้อย่างไรว่าข้อมูลทั้งหมดถูกจัดเก็บ?

ฉันใช้ MongoDB เพื่อเก็บค่าที่วัดได้เป็นระยะ ทุก ๆ ค่าประมาณ 100 ms จะถูกแทรกเป็นเอกสาร มันใช้งานได้ดี แต่ฉันกังวลเกี่ยวกับปัญหาด้านประสิทธิภาพ (ฉันใช้ส่วนแทรกที่ปลอดภัยดูเหมือนว่าใน PyMongo นี่เป็นค่าเริ่มต้น)

จะเกิดอะไรขึ้นถ้ามีการแทรกต่อวินาทีมากกว่า mongod จะสามารถบันทึกลงฮาร์ดดิสก์ได้? จะมีการเตือนภัยหรือไม่หรือจะล้มเหลวอย่างเงียบ ๆ ?

มีวิธีใดบ้างในการตรวจสอบโหลดการเขียน? ฉันพบเฉพาะdb.serverStatus().writeBacksQueuedซึ่งถูกตั้งค่าเป็นเท็จเสมอเมื่อฉันเรียกมันว่า ฉันจะทดสอบจำนวนข้อมูลที่ฉันต้องแทรกเพื่อเติมคิวการเขียนได้อย่างไร

mongostatแสดงล็อค นี่เป็นสิ่งที่ฉันควรกังวลหรือไม่?

insert  query update delete getmore command flushes mapped  vsize    res faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
  *117     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:6.5%          0       0|0     0|0   124b     6k     2  SLV   09:58:10 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:0.8%          0       0|0     0|0   124b     6k     2  SLV   09:58:11 
  *111     *0     *0     *0       0     2|0       0  17.4g  35.3g  3.76g      0     .:4.2%          0       0|0     0|0   124b     6k     2  SLV   09:58:1

ฉันต้องกังวลเรื่องล็อคการเขียนหรือไม่? เกิดอะไรขึ้นกับการแทรกระหว่างช่วงเวลาล็อคการเขียน? มันอยู่ในคิวและจัดเก็บในภายหลังหรือไม่

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

(ฉันใช้เวอร์ชั่น 2.4.3)

อัปเดต: ฉันคิดว่าได้ตอบคำถามของฉันเองบางส่วนแล้ว ฉันจัดการได้มากถึง 12.000 เม็ดต่อวินาทีโดยใช้แบบง่ายขณะที่วนซ้ำใส่เอกสารทดสอบขนาดเล็ก แต่ qr | qw ยังคงแสดงให้เห็นว่ามีคิวการอ่านและเขียนยังคงว่างเปล่า:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn repl       time 
 11234     *0      2     *0    1563     1|0       1  21.9g  44.3g  1.22g      0    testdb:58.9%          0       1|0     1|1   797k   980k     6  PRI   10:26:32 
 12768     *0      2     *0    1284     1|0       0  21.9g  44.3g  1.22g      0    testdb:58.0%          0       0|0     0|1   881k     1m     6  PRI   10:26:33 
 12839     *0      2     *0    1231     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.3%          0       0|0     0|1   883k     1m     6  PRI   10:26:34 
 12701     *0      2     *0     910     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   858k     1m     6  PRI   10:26:35 
 12241     *0      2     *0    1206     1|0       0  21.9g  44.3g  1.22g      0    testdb:56.7%          0       0|0     0|0   843k     1m     6  PRI   10:26:36 
 11581     *0      2     *0    1406     1|0       0  21.9g  44.3g  1.22g      0    testdb:61.8%          0       0|0     0|1   811k     1m     6  PRI   10:26:37 
  8719     *0      2     *0    1210     1|0       0  21.9g  44.3g  1.22g      0    testdb:43.8%          0       0|0     0|1   618k   762k     6  PRI   10:26:38 
 11429     *0      2     *0    1469     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.6%          0       0|0     0|1   804k   993k     6  PRI   10:26:39 
 12779     *0      2     *0    1092     1|0       0  21.9g  44.3g  1.22g      0    testdb:60.2%          0       1|0     0|1   872k     1m     6  PRI   10:26:40 
 12757     *0      2     *0     436     1|0       0  21.9g  44.3g  1.22g      0    testdb:59.7%          0       0|0     0|1   838k   432k     6  PRI   10:26:41 

ฉันคิดว่านี่หมายความว่าการแทรกเพียงอย่างเดียวจะไม่ก่อให้เกิดปัญหามากมาย: "คิวจะมีแนวโน้มที่จะขัดขวางหากคุณกำลังดำเนินการเขียนจำนวนมากควบคู่ไปกับการเขียนอย่างหนักอื่น ๆ เช่นการเอาออกจำนวนมาก" (พบที่นี่ ]

คำถามเปิดของฉัน:จะเกิดอะไรขึ้นกับข้อมูลของฉันหากคิวการเขียนเพิ่มขึ้นในระยะยาว

คุณได้ตอบคำถามของคุณเองที่นี่โดยเฉพาะคุณมีความคิดที่ดีเกี่ยวกับแง่มุมการเขียนของสมการ - 12,000 เม็ด / วินาทีทำให้คุณได้รับการเขียน ~ 60% นั่นเป็นระดับที่เหมาะสมเพื่อให้ได้ประสิทธิภาพที่สอดคล้องกัน - คุณจะได้รับการโต้แย้งบ้างและ ops บางอย่างจะช้าลงเล็กน้อย แต่คุณต้องการเริ่มกังวลประมาณ 80% - เหมือนของมาก ๆ เมื่อคุณเริ่มใช้งานเกิน 80% ความจุที่คุณจะเริ่มต้นการกดปุ่มปัญหาบ่อยขึ้น

ในแง่ของคอขวดอื่น ๆ และโดยเฉพาะอย่างยิ่งว่าคุณสามารถเขียนลงดิสก์ได้เร็วแค่ไหน - นี่อาจทำให้เกิดปัญหาได้ แต่เพื่อดูสถิติที่เกี่ยวข้องตลอดเวลาฉันแนะนำให้ติดตั้งMMSด้วยปลั๊กอิน munin-nodeเพื่อให้ฮาร์ดแวร์และ IO นอกจากสถิติ MongoDB แล้ว

เมื่อคุณมีสิ่งนั้นตัวชี้วัดที่คุณจะต้องจับตาคือ:

• เวลาล้างโดยเฉลี่ย (นี่คือระยะเวลาที่ซิงค์กับดิสก์เป็นระยะเวลาของ MongoDB)
• IOStats ในแท็บฮาร์ดแวร์ (โดยเฉพาะอย่างยิ่ง IOWait)
• ข้อบกพร่องของหน้า (หากดิสก์ของคุณกำลังยุ่งกับการเขียนและคุณจำเป็นต้องอ่านข้อมูลพวกเขาจะต้องแข่งขันเพื่อหาทรัพยากรที่หายาก)

มันซับซ้อนเล็กน้อย แต่นี่เป็นแนวคิดพื้นฐาน:

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

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

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

หลังจากทั้งหมดนั้นสามารถเดินไปที่คำถามบางส่วนของคุณ:

จะเกิดอะไรขึ้นถ้ามีการแทรกต่อวินาทีมากกว่า mongod จะสามารถบันทึกลงในฮาร์ดดิสก์ได้? จะมีการเตือนภัยหรือไม่หรือจะล้มเหลวอย่างเงียบ ๆ ?

หากคุณเริ่มที่จะทำให้ดิสก์มีระดับตามที่อธิบายไว้ข้างต้นในที่สุดทุกอย่างก็จะช้าลงและในบางจุด (และสิ่งนี้จะขึ้นอยู่กับเวลาว่าฮาร์ดแวร์ของคุณเป็นอย่างไรวิธีจัดการกับข้อยกเว้น) การเขียนของคุณจะล้มเหลว - ถ้า คุณกำลังใช้ pymongo รุ่นล่าสุดจากนั้นคุณจะใช้การเขียนที่ปลอดภัยโดยค่าเริ่มต้นและสิ่งเหล่านั้นจะล้มเหลว หากคุณต้องการที่จะหวาดระแวงอีกเล็กน้อยคุณสามารถทำข้อกังวลเกี่ยวกับการเขียนของj: จริงซึ่งจะรอส่งคืนตกลงจนกว่าการเขียนจะทำลงในเจอร์นัล (เช่นบนดิสก์) แน่นอนว่าสิ่งนี้จะช้ากว่าการเขียนที่ปลอดภัยปกติ แต่จะเป็นตัวบ่งชี้ปัญหาที่เกี่ยวข้องกับความจุของดิสก์ในทันทีและคุณสามารถใช้เพื่อบล็อก / คิวการดำเนินการอื่น ๆ และทำหน้าที่เป็นคันเร่งเพื่อป้องกันฐานข้อมูลของคุณ จม

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

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

จะเกิดอะไรขึ้นกับข้อมูลของฉันหากคิวการเขียนเพิ่มขึ้นในระยะยาว

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

โดยทั่วไปคุณต้องการทราบถึงปัจจัย จำกัด ของคุณไม่ว่าจะเป็นการล็อกความเร็วดิสก์เป็นต้นจากนั้นติดตามระดับเมื่อเวลาผ่านไปและปรับขนาด (การแยก) หรือเพิ่ม (ฮาร์ดแวร์ที่ดีกว่า) ก่อนที่คุณจะถึงขีด จำกัด ที่ยากและดูปัญหาด้านประสิทธิภาพ

สิ่งสุดท้ายที่db.serverStatus().writeBacksQueuedเป็นจริงคือตัวชี้วัดที่จะไม่เป็นศูนย์ในสภาพแวดล้อมที่มีเศษซากและจะต้องดำเนินการเพื่อให้แน่ใจว่าการเขียนไปยังกลุ่มระหว่างการย้ายข้อมูลจะได้รับการจัดการอย่างเหมาะสม (จัดการโดยlistback listener ) ดังนั้นมันจึงเป็นปลาเฮอริ่งแดงที่นี่ - ไม่มีส่วนเกี่ยวข้องกับปริมาณการเขียนทั่วไป