Warum sind meine Datenverzeichnisse beim Sharding einer Sammlung in MongoDB so groß?

Question

Ich spiele gerade mit dem Sharding einer Sammlung in MongoDB und habe einige Skripte erstellt, um Replikatsätze einzurichten, sie zu Shards hinzuzufügen und diese Shards dann zu meinem primären Prozess mongos hinzuzufügen.

ich erzeugen Daten mit einem sehr dummen Python-Skript:

import json 

def gen_data(filename): 
    with open(filename, 'w') as f: 
     for i in range(100000*33): 
      d = {"Hello": i, "World" : 99999-i} 
      json.dump(d, f) 
      f.write("\n") 

if __name__ == "__main__": 
    gen_data("my_data.json") 

Ich habe vier Scherben (a, b, c, d) mit drei repl Sätze pro Shard (0, 1, 2). Die Datenverzeichnisse heißen .

Ich mache Chunk-Größen 100M nach Aktivieren Sharding meiner Sammlung, "hello.world". Ich importiere die Daten, indexiere auf '_id', dann warte auf die Migration.

Nach meinem Balancer läuft beendet, finde ich, dass ich eine fast gleiche Anzahl von Blöcken in jeder Scherbe habe, aber die Anzahl der Stücke macht keinen Sinn in Bezug auf die Daten machen:

databases: 
    { "_id" : "hello", "primary" : "a", "partitioned" : true } 
     hello.world 
      shard key: { "_id" : 1 } 
      unique: false 
      balancing: true 
      chunks: 
       a 3 
       b 3 
       c 3 
       d 2 
//... 

my_data.json ist 118M, aber wenn ich die Größe meiner Datenverzeichnisse überprüfen, ich bin ziemlich überrascht, jeder von ihnen viel größer als die Originaldaten zu finden:

[erip@my_host shard_experiment]$ for s in {a..d}; do for n in {0..2}; do du -sh "$s$n"; done; done; 
521M a0 
420M a1 
421M a2 
344M b0 
343M b1 
342M b2 
336M c0 
337M c1 
337M c2 
335M d0 
337M d1 
337M d2 

Warum meine Datenverzeichnisse sind so groß? Ich benutze die --smallfiles, wenn ich meine Shard-Server einrichten, aber ich finde großen Aufwand mit so kleinen importierten Dokumenten.

Answer 1

Beachten Sie, dass die Option --smallfiles nur für die MMAPv1-Speicher-Engine gilt. Sie gilt nicht für die WiredTiger-Speicher-Engine, die standardmäßig in MongoDB 3.2 verwendet wird.

Die MongoDB Journal verwendet wahrscheinlich eine beträchtliche Menge Ihres Speicherplatzes, wahrscheinlich 300 MB für jeden Knoten. Sie können dies überprüfen, indem etwas wie Laufen:

find . -name "journal" -exec du -sh {} \; 

Auch ist die Replica Set Oplog wahrscheinlich auch eine angemessene Menge an Speicherplatz verwenden. Sie können die verwendete oplog-Größe überprüfen, indem Sie sich bei der mongo-Shell für einen Ihrer Replikatsätze anmelden und db.printReplicationInfo() ausführen. Sie können dies reduzieren, indem Sie oplopSize beim ersten Start der Replikatgruppe zum ersten Mal festlegen.

Mit einer sehr kleinen Menge von Daten, wie Sie haben, ist der Overhead groß, aber wenn Ihre Daten viel größer werden, wird dieser Overhead nur eine kleine Menge sein.

Chunk Splits werden präemptiv mit einem heuristischen Algorithmus durchgeführt, so dass Splits auftreten, bevor die Chunks die maximale Größe erreichen.