Performance-Optimierung MongoDB

M

marce

Well-Known Member
wir haben hier eine MongoDB (lokale Instanz, keine Replicas / Cluster / ...) in welcher ePubs zur Bearbeitung gespeichert werden.

Aktuell hat die DB im Filesystem 46GB, verteilt auf aktuell 24 DB-Files - die üblichen Standard-Größen von Mongo (64, 128, 256, 512MB, 1GB, und dann viele mit 2GB)

Wir stellen nun bei der Benutzung der zugehörigen Applikation fest, daß die MongoDB recht hohe IO-Werte verursacht.

Um das zu optimieren (ohne an die HW des Servers ranzumüssen) stellt sich mir nun die Frage, ob man durch eine andere Organisation der DB-Files evtl. Overhead im Schreibprozess verringern könnte.
Nun sind die Optionen, die MongoDB da bietet recht "gering" - es gibt soweit ich das gesehen habe nur storage.smallFiles.

Hat jemand Erfahrung damit, ob sich diese Option im Zusammenspiel mit größeren Datenobjekten (~ 30-750MB / ePub, im Schnitt 270MB lt. db.stats) auf die IO-Last des Systems auswirkt?
 
Wie wäre es, die ePubs in einen ordentlichen Object-Store auszulagern und in der MongoDB nur die Metadaten zu lagern? Zum Volltext-Durchsuchen der ePubs noch einen ordentlichen Index (z.B. Elasticsearch) dazu nehmen?

Es ist i.d.R. schwer bis unmöglich, verfehltes Systemdesign auf der operationalen Ebene wieder rauszuhauen.

Ihr könnt ja mal versuchen die Read-Last auf mehrere Replicas zu verteilen, falls euch parallele Zugriffe zu schaffen machen.
 
Das ist leider genau die Art von Antwort, die ich befürchtet habe. :-)

Das das Systemdesign so (auch aus meiner Sicht) nicht optimal ist habe ich den Entwicklern auch schon gesagt - aus deren Sicht gibt es aber wohl div. Gründe, das doch so zu machen. Lassen wir die Diskussion bitte mal außen vor.
... und wie üblich, bei den verwendeten Testdaten (nur wenige Datensätze, kleine Größen) gibt es das Problem ja auch nicht, nur leider halten sich die Produktionsdaten nicht daran...

Da das System ein internes Redaktionssystem ist haben wir aktuell auch kein Problem mit parallelen Zugriffen - lesend ist es an sich auch kein Problem - daß es ein wenig dauert, im schlimmsten Fall ein paar hundert MB aus der DB zu lesen ist den Leuten auch klar, da haben wir auch nicht das Problem.

Das Problem besteht nur beim Insert - und da hatte ich die Hoffenung, daß ich evtl. durch einen anders strukturierte Datenbank das Grundsetting des Systems beibehalten kann, aber eben ein wenig mehr Performance rausholen kann (wenn das dann immer noch nichts bringt / nicht ausreicht sehen es ggf. auch die Entwickler ein, daß eine Strukturänderung notwendig ist - aber aktuell sträuben sie sich halt noch - und wer bin ich als armer Admin, da denen Vorschriften machen zu können :-) )

Meine Hoffnung wäre halt - aktuell habe ich DB-Files mit 2 GB - wenn das Mongo-intern "doof" gemacht ist beim Schreiben großer binärer Objekte muss ich für einen Insert im schlimmsten Fall 4GB (2 DB Files) lesen, bearbeiten und wieder schreiben. Wenn ich nun aber kleinere Db-Files habe könnte da der IO-Overhead runtergehen. Könnte, wie gesagt.

... und die 2. Hoffnung war halt, daß mir jemand schon im Vorraus eine Aussage machen kann, ob das eine Auswirkung hat oder nicht. Ohne das ich das Prodktionssystem umbaue. Die Mongo-Doku hält sich da vornehm, dezent zurück.
 
Ich würde mich da ja eindeutig positionieren und das Problem an R&D zurück geben.
Außerdem sollen die User den Frust direkt an den PO schicken und nicht an IT.

Oder die sollen genug Budget locker machen um das Zeug komplett im RAM zu cachen und auf SSD zu schreiben. Und dann isses trotzdem zu langsam...
 
You must log in or register to reply here.
Back
Top