BSON

BSON (Binary JSON) ist das binär kodierte Datenformat, das MongoDB zur Speicherung und zur Kommunikation über die Leitung verwendet. Auf API-Ebene JSON-förmig – dieselbe Objekt-/Array-Hierarchie – aber binär auf der Festplatte und im Netzwerk.

Warum ein binäres Format, wenn es JSON gibt:

• Typtreue. JSON kennt nur String, Number, Boolean, null, Object, Array. BSON ergänzt Date, Binary, ObjectId, Decimal128, Regex, Timestamp, Int32 vs. Int64. Ein Round-Trip durch BSON bewahrt den exakten Typ.
• Selbstbeschreibende Längen-Header. Jedem BSON-Dokument und -Wert ist seine Länge vorangestellt, sodass MongoDB Felder überspringen kann, ohne sie zu parsen. JSON erfordert das Lesen von Anfang an.
• Dezimalarithmetik. BSONs Typ Decimal128 speichert exakte Dezimalzahlen mit bis zu 34 signifikanten Stellen – wichtig für Finanzdaten, bei denen IEEE-754-Gleitkommazahlen schlecht runden.

BSON-Dateien sind wegen der Längen-Header und expliziten Typ-Tags typischerweise 10–20 % größer als gleichwertiges JSON, doch die Abfrageleistung ist drastisch höher, weil MongoDB das Dokument nicht parsen muss, um ein Feld zu finden.

Die meisten MongoDB-Treiber (Node, Python, Java, Go) konvertieren automatisch zwischen BSON und den nativen Typen der jeweiligen Sprache. Mit BSON kommt man selten direkt in Berührung, es sei denn, man schreibt einen Treiber oder liest die bson-Backup-Dateien außerhalb von MongoDB selbst.

Das 16-MB-Dokumentlimit: Ein einzelnes BSON-Dokument darf 16 Megabyte nicht überschreiten. Dies ist eine harte Beschränkung des MongoDB-Servers, keine Grenze der BSON-Spezifikation – das Format selbst nutzt vorzeichenbehaftete 32-Bit-Längen und könnte theoretisch 2 GB erreichen. Die 16-MB-Grenze schützt vor entarteten Anwendungsfällen (ganze Bücher oder Bild-Binärdaten in einem Dokument zu speichern) und entspricht der Größe des typischen Netzwerk-Paketfensters. Wächst ein Dokument über das Limit hinaus, erzwingt das einen GridFS-Workaround (die Nutzlast in Chunks über mehrere Dokumente aufteilen) oder ein Redesign, bei dem große Blobs im Objektspeicher liegen und das Dokument nur eine Referenz hält.

Warum BSONs ObjectId 12 Byte groß ist und keine UUID: MongoDBs Standard-_id ist eine 12-Byte-ObjectId aus einem 4-Byte-Unix-Zeitstempel, einem 5-Byte-Zufalls-„Prozess“-Bezeichner (ersetzt die ältere Aufteilung in Maschinen-ID/PID) und einem 3-Byte-Inkrementzähler. Die Struktur sorgt für eine zeitliche Ordnung (neueste Dokumente sortieren natürlicherweise ans Ende) und vermeidet die Koordinationskosten einer UUID4. Der Kompromiss sind 12 Byte gegenüber 16 bei einer UUID, was über eine Milliarde Dokumente hinweg 4 GB Primärschlüssel-Speicher spart. Neuere Collections nutzen aus Gründen datenbankübergreifender Kompatibilität oft stattdessen UUID v7. Verwandt: IEEE 754, BigInt. Referenz: BSON-Spezifikation.

Durchgerechnetes Beispiel

Das JSON-Dokument {"x": 1} ist als Text 8 Byte groß. Dasselbe Dokument in BSON lautet 0C 00 00 00 10 78 00 01 00 00 00 00 – 12 Byte: 4 Byte Gesamtlänge, 1 Byte Typcode (0x10 = int32), der Feldname x als nullterminierter String (2 Byte), 4 Byte für den Ganzzahlwert und ein 1-Byte-Dokument-Terminator. JSON ist bei winzigen Nutzlasten kürzer, doch BSON gewinnt bei der Parse-Geschwindigkeit und bei Dokumenten mit Nicht-String-Typen. Ein Beispiel aus der Praxis: Das Speichern einer Finanztransaktion mit einem Decimal128-Preis von 123.45 wird durch BSON exakt zurückübertragen; durch JSON wird es zu 123.45 als Gleitkommazahl und droht in JavaScript als 123.44999999999999 zurückzukommen. Die Decimal128-Darstellung ist unabhängig von der Größenordnung 16 Byte.

Wann und warum es zählt

Wer eine App auf MongoDB baut und Geldbeträge persistiert, sollte sie als Decimal128 speichern, nicht als JavaScript-Number, die zu JSON serialisiert wird. Mongoose-Schemas verwenden standardmäßig Number, was in BSON zu double wird, was bei Preisen wie 0,10 + 0,20 still IEEE-754-Rundung einführt. Dasselbe gilt für Datumswerte: Datumswerte als Strings („2026-01-15“) zu speichern verliert die indizierbare Ordnung über Zeitzonengrenzen hinweg; sie als BSON-Date zu speichern bewahrt die Millisekundenpräzision und erlaubt Bereichsabfragen, B-Baum-Indizes effizient zu nutzen. Beim Migrieren von Daten in MongoDB hinein oder heraus verwenden Sie mongoexport --jsonFormat=canonical statt des relaxed-Modus, um BSON-Typinformationen durch das JSON-Zwischenformat hindurch zu bewahren. Referenz: MongoDB Manual — BSON Types.