Speicherplatz einer MongoDB freigeben

Hat man viele Daten in einer Datenbank gelöscht und möchte den Speicherplatz freigeben, kann die Funktion „repairDatabase()“ verwendet werden.

Dabei ist zu beachten, dass die Datenbank in ein „_tmp_repairDatabase_0“ Verzeichnis kopiert wird. Damit muss bei großen Datenbanken darauf geachtet werden, dass immer genug Speicherplatz zur Verfügung steht. Im Idealfall sollte die Platte mit maximal 50% belegt sein.

Ist genug Platz vorhanden, kann die Größe wie folgt reduziert werden:

> db.repairDatabase()
{ "ok" : 1 }

Ist nicht genug Platz vorhanden, bekommt man eine Fehlermeldung:

> db.repairDatabase()
{
    "ok" : 0,
    "errmsg" : "Cannot repair database DBNAME having size: 
    12342263808 (bytes) because free disk space is: 5431107584 (bytes)"
}

Als zweiter Stolperstein könnte sich auch der zu gering bemessene Memory erweisen. Als Richtwert sollten zirka 20% der Größe der Datenbank zur Verfügung stehen. Ist das nicht der Fall, könnte „repairDatabase()“ mit einem OOM abbrechen:

[conn164] Assertion: 13524:out of memory AlignedBuilder

Bei einem OOM kann man direkt mit Backup/Restore weitermachen, da ein größeres Dateisystem nicht helfen wird.

Ob das Dateisystem erweitert werden kann, hängt von der Architektur ab. Setzt man z.B. LVM mit EXT3 ein, wäre folgender Weg möglich:

# lvextend -L XXG /dev/sdaX
# resize2fs /dev/sdaX

Kann das Dateisystem nicht erweitert werden, bleibt als Lösung noch ein Backup/Restore. Bei sehr großen Datenbanken sollte eine Downtime eingeplant werden.

Im ersten Schritt erstellt man ein aktuelles Backup:

# mongodump -o backup/mongodb/ --authenticationDatabase admin \
  -d DBBAME -u admin -p

Danach löscht man die Datenbank:

# mongo localhost/admin -u admin -p
> use DBNAME
> db.dropDatabase()

Jetzt kann das Backup wiederhergestellt werden:

# mongorestore backup/mongodb/DBNAME/ -u admin -p

Danach ist der überflüssige Speicherplatz wieder frei.

MongoDB Performance

SQL Datenbanken eignen sich besonders für strukturierte Daten mit Relationen. Wer jedoch unstrukturierte Daten ohne Zusammenhang zwischeneinander speichern möchte, sollte sich Vertreter der NoSQL Kategorie wie z.B. MongoDB anschauen.

Ein Anwendungsfall sind Logs von Betriebssystemen und Anwendungen. Diese werden oft nur für einen bestimmten Zeitraum benötigt und sind in der Regel sehr vielfältig. Damit passen sie selten in vorgegebene Strukturen von klassischen SQL Datenbanken.

Bei vielen Anwendungen kommen jedoch auch viele Daten zusammen, die halbwegs konsistent gespeichert werden wollen. Die meisten Performance Tests beleuchten bei NoSQL jedoch nur die Lesegeschwindigkeit. Der folgende Artikel soll die Schreibgeschwindigkeit von MongoDB auf verschiedenen Platformen beleuchten:

Die Geschwindigkeit bei externen Anbietern (Database as a Service) wird primär durch die Bandbreite des Netzwerks bestimmt. Wer eigene Systeme betreiben möchte, sollte SSD’s einsetzen und schnelle CPU’s verwenden. Eine schnelle und kostengünstige Platform bietet Hetzner mit dem Root Server EX40-SSD an.

Datenbank Hosting

Und wieder gibt es neue Pakete für häufig angefragte Dienste:

In Kombination mit Webhosting oder Tomcat Hosting können damit professionelle Anwendungen mit hoher Performance, Verfügbarkeit und Sicherheit betrieben werden.

Ein kleines Beispiel aus der Praxis:

Ein Kunde wünscht eine ausfallsichere DB2 Datenbank mit zirka 10 GB SSD Storage und 100 GB SATA Storage. Die Datenbank wird mit Version 10.1 betrieben und soll durch Multi-Temperature Storage die aktuellen Daten auf SSD’s vorhalten und ältere Daten kostengünstig auf SATA. Die Datenbank soll durch HADR hochverfügbar gemacht werden.

Die Architektur sieht damit wie folgt aus:

datenbank_cluster

Jedem DB2 Host stehen 24 GB RAM und 4 CPU Cores zur Verfügung. Durch SSD’s sind die Antwortzeiten der Datenbank extrem performant. Dank HADR (Log Replikation) im NEARSYNC Modus, ist der maximale Datenverlusst auf wenige Sekunden beschränkt. Im Fehlerfall des aktiven Server, steht der passive Server in sehr kurzer Zeit wieder zur Verfügung.

Die DB2 Lizenzen stellt der Kunde. Für den Betrieb fallen bei aktuell zirka 110 GB Gesamtgröße der Datenbank monatlich zirka 580€ an.

[Update]

Die Dokumentation für diesen Aufbau findet man im Wiki:

Wer DB2 mit HADR und Multi-Temperature Storage unter CentOS aufsetzen möchte, findet hier alle wichtigen Informationen.