Computer >> Hướng Dẫn Máy Tính >  >> Lập Trình >> Cơ Sở Dữ Liệu

Làm chủ MongoDB Space Management: Allocation, Dashboards, và Scaling Tips

Cho những bạn mới dùng MongoDB, MongoDB space usage có thể quite confusing. Bài này giải thích cách MongoDB allocate space và cách interpret space usage info trong ObjectRocket dashboard để判断 khi nào cần compact instance hoặc add shard để grow space available.

Đầu tiên, bắt đầu với brand new Medium instance single 5GB shard. Tôi populate instance này với test data trong database "ocean". Space usage sau khi add test data và tạo vài indexes (deliberately add additional indexes biết sẽ large relative to test dataset):

Làm sao 315MiB data và 254MiB indexes nghĩa là dùng 2.1 GiB của 5 GiB shard? Để giải thích, bắt đầu với cách MongoDB store data on disk as series of extents. Vì ObjectRocket instances run với smallfiles option, extent đầu allocate 16MB. Extents double size cho đến 512MB, sau đó mọi extent allocate as 512MB file. Database "ocean" có file structure:

$ 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

Extents này store cả data và indexes. Với MongoDB, ngay khi data written to extent, next logical extent được allocate. Với structure trên, ocean.6 likely chưa data nhưng pre-allocated cho khi ocean.5 full. Ngay khi data written to ocean.6, extent 512MB mới ocean.7 lại pre-allocated. Khi data deleted từ MongoDB database, space không released cho đến khi compact - theo thời gian, data files trở nên fragmented khi data deleted (hoặc document outgrows original storage vì additional keys added). Compaction defragment data files vì trong compaction, data replicated từ member khác của replica set và data files recreated from scratch.

Additional 16MB file store namespace - ocean.ns file. Pattern này xảy ra cho mỗi database trên MongoDB instance. Ngoài database "ocean", có 2 system databases: "admin" và "local". "admin" database store user info cho all database users (trước 2.6.x, chỉ dùng cho admin users). Dù admin database nhỏ, vẫn có 16MB extent, pre-allocated 32MB extent, và 16MB namespace file.

System database thứ 2: "local". Mỗi shard ObjectRocket cung cấp là three-member replica set. Để keep replicas in sync, MongoDB maintain log gọi là oplog của mỗi update. Sync trên mỗi replica và dùng track changes cần làm trên secondary replicas. Oplog tồn tại as capped collection trong "local" database. ObjectRocket config oplog size generally 10% shard size - case 5GB shard, oplog 500MB. Vậy "local" database gồm 16MB extent, 512MB extent, 16MB namespace file.

Cuối cùng, example shard chứa housekeeping area: journal. Journal là set 1-3 files ~128MB mỗi. Khi write occurs, MongoDB first write update sequentially to journal. Rồi periodically background thread flush updates đến actual data files (extents), typically mỗi 60s. Lý do double-write: write sequentially to journal thường much faster than seeking necessary write to actual data files. Bằng cách write changes immediately to journal, MongoDB ensure data recovery nếu crash mà không require every write wait until change written to data files. Case current primary replica, thấy 2 journal files active:

$ 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._2

MongoDB rotate files tự động tùy frequency updates vs background flushes.

Bây giờ đã cover cách MongoDB dùng disk space, tương ứng với space usage bar từ ObjectRocket dashboard như thế nào?

  • NS value, 48MB — sum của 3 namespace files 16MB cho 3 databases: ocean, admin, local.
  • Data value, 315MiB — sum của dataSize từ db.stats() cho all databases (kể system).
  • Index value, 253.9MiB — sum của indexSize từ db.stats() cho all databases.
  • Storage value, 687.2MiB — sum data + indexes cho all databases + unreclaimed space từ deletes.
  • Total File value, 2.0 GiB — disk dùng total trên primary replica. Ngoài space covered bởi Storage value và NS value, cũng include preallocated extents nhưng không include journal space.

Với metrics này, có thể simple calculations xác định instance có fragmented đủ cần compaction. Tính space lost do fragmentation:

100% — (Data + Indexes) / Storage

Case example instance: 17% (100% — (315MiB Data + 253.9MiB Index) / 687.2MiB Storage = 17%). Khuyên compact khi fragmentation approach 20%.

Calculation khác: có cần add shard dựa trên overall space usage. Tính overall space usage:

(Total File / (Plan Size * number of shards)) * 100%

Example instance: 40% ((2 GiB / 5 GiB * 1 shard) * 100% = 40%). Khuyên add shard khi overall space usage approach 80%. Nếu space usage đạt 80%, contact support giúp add shard.