สำหรับผู้ที่เพิ่งเริ่มใช้ MongoDB การใช้พื้นที่ MongoDB อาจดูค่อนข้างสับสน ในบทความนี้ ผมจะอธิบายวิธีที่ MongoDB จัดสรรพื้นที่และวิธีตีความข้อมูลการใช้พื้นที่ในแดชบอร์ด ObjectRocket เพื่อตัดสินว่าเมื่อใดที่คุณต้องการกระชับอินสแตนซ์หรือเพิ่มชาร์ดเพื่อเพิ่มพื้นที่ว่างสำหรับอินสแตนซ์ของคุณ
ก่อนอื่น มาเริ่มกันด้วยอินสแตนซ์ขนาดกลางใหม่ล่าสุดที่ประกอบด้วยชาร์ด 5GB เดียว ฉันจะเติมข้อมูลอินสแตนซ์นี้ด้วยข้อมูลทดสอบในฐานข้อมูลชื่อ "มหาสมุทร" นี่คือลักษณะการใช้งานพื้นที่สำหรับอินสแตนซ์นี้หลังจากเพิ่มข้อมูลทดสอบและสร้างดัชนีบางส่วน (สำหรับวัตถุประสงค์ของบทความนี้ ฉันได้เพิ่มดัชนีเพิ่มเติมโดยเจตนาซึ่งฉันรู้ว่าจะมีขนาดค่อนข้างใหญ่เมื่อเทียบกับชุดข้อมูลทดสอบ):
ข้อมูล 315MiB และดัชนี 254MiB หมายความว่าเรากำลังใช้ 2.1 GiB จากส่วนแบ่งข้อมูล 5 GiB ของเราอย่างไร เพื่ออธิบาย เรามาเริ่มกันที่ MongoDB เก็บข้อมูลบนดิสก์เป็นชุดของขอบเขต เนื่องจากอินสแตนซ์ ObjectRocket ของเราทำงานด้วยตัวเลือก smallfiles ขอบเขตแรกจึงถูกจัดสรรเป็น 16MB ขอบเขตเหล่านี้จะขยายเป็นสองเท่าจนกว่าจะถึง 512MB หลังจากนั้นทุก ๆ ขอบเขตจะถูกจัดสรรเป็นไฟล์ 512MB ดังนั้นฐานข้อมูล "มหาสมุทร" ตัวอย่างของเราจึงมีโครงสร้างไฟล์ดังนี้:
$ ls -lh ocean/
total 1.5G
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.0
-rw------- 1 mongodb mongodb 32M Aug 20 20:44 ocean.1
-rw------- 1 mongodb mongodb 64M Aug 20 22:23 ocean.2
-rw------- 1 mongodb mongodb 128M Aug 20 22:30 ocean.3
-rw------- 1 mongodb mongodb 256M Aug 20 22:30 ocean.4
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.5
-rw------- 1 mongodb mongodb 512M Aug 20 22:30 ocean.6
-rw------- 1 mongodb mongodb 16M Aug 20 22:30 ocean.ns
drwxr-xr-x 2 mongodb mongodb 4.0K Aug 20 22:30 _tmpขอบเขตเหล่านี้จัดเก็บทั้งข้อมูลและดัชนีสำหรับฐานข้อมูลของเรา ด้วย MongoDB ทันทีที่มีการเขียนข้อมูลใดๆ ในระดับหนึ่ง ขอบเขตตรรกะถัดไปจะได้รับการจัดสรร ดังนั้น ด้วยโครงสร้างข้างต้นนี้ ocean.6 จึงมีแนวโน้มว่าไม่มีข้อมูลในขณะนี้ แต่ได้รับการจัดสรรล่วงหน้าไว้แล้วเมื่อ ocean.5 จะเต็ม ทันทีที่มีการเขียนข้อมูลใดๆ ไปยัง ocean.6 ขอบเขต 512MB ใหม่ ocean.7 จะได้รับการจัดสรรล่วงหน้าอีกครั้ง เมื่อข้อมูลถูกลบออกจากฐานข้อมูล MongoDB พื้นที่จะไม่ถูกปล่อยจนกว่าคุณจะกระชับ ดังนั้นเมื่อเวลาผ่านไป ไฟล์ข้อมูลเหล่านี้อาจแตกเป็นชิ้นเล็กชิ้นน้อยเมื่อข้อมูลถูกลบ (หรือหากเอกสารเกินตำแหน่งที่จัดเก็บเดิมเนื่องจากมีการเพิ่มคีย์เพิ่มเติม) การบดอัดจะจัดเรียงไฟล์ข้อมูลเหล่านี้ เนื่องจากในระหว่างการบีบอัด ข้อมูลจะถูกจำลองจากสมาชิกอื่นของชุดเรพพลิกา และไฟล์ข้อมูลจะถูกสร้างขึ้นใหม่ตั้งแต่ต้น
ไฟล์เพิ่มเติม 16MB เก็บเนมสเปซ ซึ่งเป็นไฟล์ ocean.ns รูปแบบเดียวกันนี้เกิดขึ้นกับแต่ละฐานข้อมูลบนอินสแตนซ์ MongoDB นอกจากฐานข้อมูล "มหาสมุทร" แล้ว ยังมีฐานข้อมูลระบบเพิ่มเติมอีกสองฐานข้อมูลบนชาร์ดของเรา:"ผู้ดูแลระบบ" และ "ในเครื่อง" ฐานข้อมูล "ผู้ดูแลระบบ" เก็บข้อมูลผู้ใช้สำหรับผู้ใช้ฐานข้อมูลทั้งหมด (ก่อน 2.6.x ฐานข้อมูลนี้ใช้สำหรับผู้ใช้ที่เป็นผู้ดูแลระบบเท่านั้น) แม้ว่าฐานข้อมูลของผู้ดูแลระบบจะมีขนาดเล็ก แต่เรายังคงมีขอบเขต 16MB ขอบเขต 32MB ที่จัดสรรไว้ล่วงหน้า และไฟล์เนมสเปซ 16MB สำหรับฐานข้อมูลนี้
ฐานข้อมูลระบบที่สองคือฐานข้อมูล "ท้องถิ่น" ชาร์ดแต่ละรายการที่เรานำเสนอที่ ObjectRocket เป็นชุดแบบจำลองสามสมาชิก เพื่อให้การจำลองเหล่านี้ตรงกัน MongoDB จะเก็บบันทึกที่เรียกว่า oplog ของการอัพเดทแต่ละครั้ง สิ่งนี้จะซิงค์กันในแต่ละแบบจำลองและใช้เพื่อติดตามการเปลี่ยนแปลงที่ต้องทำบนแบบจำลองรอง oplog นี้มีอยู่ในคอลเล็กชันต่อยอดภายในฐานข้อมูล "ท้องถิ่น" ที่ ObjectRocket เรากำหนดค่าขนาดของ oplog ให้โดยทั่วไปเป็น 10% ของขนาดชาร์ด — ในกรณีของชาร์ด 5GB ของเรา oplog จะถูกกำหนดค่าเป็น 500MB ดังนั้นฐานข้อมูล "ในเครื่อง" จึงประกอบด้วยขอบเขต 16MB, ขอบเขต 512MB และไฟล์เนมสเปซ 16MB
สุดท้าย ชาร์ดตัวอย่างของเรามีพื้นที่ดูแลทำความสะอาดอีกหนึ่งรายการ นั่นคือ วารสาร วารสารคือชุดของไฟล์ 1-3 ไฟล์ที่มีขนาดประมาณ 128MB แต่ละไฟล์ เมื่อใดก็ตามที่มีการเขียนเกิดขึ้น MongoDB จะเขียนการอัปเดตตามลำดับไปยังเจอร์นัลก่อน จากนั้นเธรดพื้นหลังจะล้างการอัปเดตเหล่านี้ไปยังไฟล์ข้อมูลจริงเป็นระยะ (ขอบเขตที่ฉันกล่าวถึงก่อนหน้านี้) โดยทั่วไปแล้วทุกๆ 60 วินาที สาเหตุของการเขียนซ้ำสองครั้งนี้คือการเขียนตามลำดับไปยังวารสารมักจะเร็วกว่าการค้นหาที่จำเป็นในการเขียนไปยังไฟล์ข้อมูลจริงมาก ด้วยการเขียนการเปลี่ยนแปลงลงในเจอร์นัลทันที MongoDB สามารถรับรองการกู้คืนข้อมูลในกรณีที่เกิดการขัดข้องโดยไม่ต้องเขียนทุกครั้งเพื่อรอจนกว่าจะมีการเขียนการเปลี่ยนแปลงลงในไฟล์ข้อมูล ในกรณีของแบบจำลองหลักปัจจุบันของเรา ฉันเห็นว่าเรามีไฟล์บันทึกการใช้งานอยู่สองไฟล์:
$ ls -lh journal/
total 273M
-rw------- 1 mongodb mongodb 149M Aug 20 22:26 j._1
-rw------- 1 mongodb mongodb 124M Aug 20 22:30 j._2MongoDB หมุนไฟล์เหล่านี้โดยอัตโนมัติขึ้นอยู่กับความถี่ของการอัปเดตเทียบกับความถี่ของการล้างพื้นหลังไปยังดิสก์
ตอนนี้ฉันได้อธิบายวิธีที่ MongoDB ใช้พื้นที่ดิสก์แล้ว สิ่งนี้สอดคล้องกับสิ่งที่แสดงในแถบการใช้พื้นที่จากแดชบอร์ด ObjectRocket ที่ฉันแสดงไว้ก่อนหน้านี้อย่างไร
- ค่า NS, 48MB — ผลรวมของไฟล์เนมสเปซ 16MB สามไฟล์สำหรับฐานข้อมูลทั้งสามที่ฉันพูดถึง ได้แก่ มหาสมุทร ผู้ดูแลระบบ และในเครื่อง
- ค่าข้อมูล 315MiB — ผลรวมของค่าที่รายงานสำหรับ dataSize ใน
db.stats()สำหรับฐานข้อมูลทั้งหมด (รวมถึงฐานข้อมูลระบบ) - ค่าดัชนี 253.9MiB — ผลรวมของค่าที่รายงานสำหรับ indexSize ใน
db.stats()สำหรับฐานข้อมูลทั้งหมด (รวมถึงฐานข้อมูลระบบ) - ค่าพื้นที่จัดเก็บ 687.2MiB — ผลรวมของข้อมูลและดัชนีสำหรับฐานข้อมูลทั้งหมด บวกกับพื้นที่ที่ไม่ถูกเรียกคืนจากการลบ
- ค่าไฟล์ทั้งหมด 2.0 GiB — เราใช้ดิสก์ทั้งหมดบนแบบจำลองหลักเป็นจำนวนเท่าใด นอกเหนือจากพื้นที่ที่ครอบคลุมโดยค่า Storage และค่า NS แล้ว ยังรวมถึงขอบเขตที่จัดสรรล่วงหน้าแต่ไม่รวมพื้นที่ที่ใช้โดยวารสาร
จากเมตริกเหล่านี้ เราสามารถทำการคำนวณง่ายๆ เพื่อพิจารณาว่าอินสแตนซ์นี้มีการแยกส่วนมากพอที่จะต้องมีการบดอัดหรือไม่ ในการคำนวณพื้นที่ที่อาจสูญหายเนื่องจากการแตกแฟรกเมนต์ ให้ใช้สิ่งต่อไปนี้:
100% – (ข้อมูล + ดัชนี) / ที่เก็บข้อมูล
ในกรณีของตัวอย่างของเรา สิ่งนี้ได้ผล 17% (100% – (315MiB Data + 253.9MiB Index) / 687.2MiB Storage =17%) ฉันขอแนะนำให้กระชับอินสแตนซ์ของคุณเมื่อการกระจายตัวเข้าใกล้ 20%
การคำนวณอีกอย่างที่เราทำได้คือต้องเพิ่มชาร์ดให้กับอินสแตนซ์นี้โดยพิจารณาจากการใช้พื้นที่โดยรวมของเราหรือไม่ ในการคำนวณการใช้พื้นที่โดยรวมของคุณให้ทำดังนี้:
(ไฟล์ทั้งหมด / (ขนาดแผน * จำนวนชาร์ด)) * 100%
สำหรับตัวอย่างของเรา วิธีนี้ได้ผลถึง 40% ((2 GiB / 5 GiB * 1 ชาร์ด) * 100% =40%) โดยทั่วไป เราแนะนำให้เพิ่มชาร์ดเมื่อการใช้พื้นที่โดยรวมใกล้ถึง 80% หากคุณสังเกตเห็นการใช้พื้นที่ของคุณถึง 80% โปรดติดต่อฝ่ายสนับสนุนและเราสามารถช่วยคุณเพิ่มชาร์ดไปยังอินสแตนซ์ของคุณได้
