BSON

BSON (Binary JSON) est le format de données binaire que MongoDB utilise pour le stockage et la communication sur le réseau. De forme JSON au niveau API — même hiérarchie objet/tableau — mais binaire sur disque et sur le réseau.

Pourquoi un format binaire quand JSON existe :

• Fidélité des types. JSON n’a que string, number, boolean, null, object, array. BSON ajoute Date, Binary, ObjectId, Decimal128, Regex, Timestamp, Int32 vs Int64. Les allers-retours via BSON préservent le type exact.
• En-têtes de longueur auto-descriptifs. Chaque document et valeur BSON est préfixé par sa longueur, donc MongoDB peut sauter des champs sans les analyser. JSON nécessite une lecture depuis le début.
• Arithmétique décimale. Le type Decimal128 de BSON stocke des nombres décimaux exacts jusqu’à 34 chiffres significatifs — important pour les données financières où les flottants IEEE 754 arrondissent mal.

Les fichiers BSON sont généralement 10 à 20 % plus grands que le JSON équivalent en raison des en-têtes de longueur et des balises de type explicites, mais les performances des requêtes sont nettement plus rapides car MongoDB n’a pas à analyser le document pour trouver un champ.

La plupart des pilotes MongoDB (Node, Python, Java, Go) convertissent automatiquement entre BSON et les types natifs du langage. Vous interagissez rarement directement avec BSON à moins d’écrire un pilote ou de lire les fichiers de sauvegarde bson en dehors de MongoDB lui-même.

La limite de 16 Mo par document : un seul document BSON ne peut pas dépasser 16 mégaoctets. Il s’agit d’une contrainte stricte du serveur MongoDB, et non d’une limite de la spécification BSON — le format lui-même utilise des longueurs signées 32 bits et pourrait théoriquement atteindre 2 Go. Le plafond de 16 Mo protège contre les cas d’utilisation dégénérés (stocker des livres entiers ou des binaires d’image dans un document) et correspond à la taille de la fenêtre de paquets réseau typique. La croissance du document au-delà de la limite force une solution de contournement GridFS (diviser la charge en morceaux sur plusieurs documents), ou une refonte où les grands blobs résident dans du stockage objet avec le document contenant une référence.

Pourquoi l’ObjectId de BSON fait 12 octets et non un UUID : le _id par défaut de MongoDB est un ObjectId de 12 octets composé d’un horodatage Unix de 4 octets, d’un identifiant « processus’’ aléatoire de 5 octets (remplace l’ancienne division machine-id/PID) et d’un compteur incrémentiel de 3 octets. La structure fournit un ordonnancement temporel (les documents les plus récents trient naturellement en fin) et évite le coût de coordination d’un UUID4. Le compromis est de 12 octets vs 16 pour un UUID, ce qui sur un milliard de documents économise 4 Go de stockage de clé primaire. Les nouvelles collections utilisent souvent UUID v7 à la place pour la compatibilité inter-bases. Connexe : IEEE 754, BigInt. Référence : Spécification BSON.

Exemple concret

Le document JSON {"x": 1} fait 8 octets en texte. Le même document en BSON est 0C 00 00 00 10 78 00 01 00 00 00 00 — 12 octets : 4 octets de longueur totale, 1 octet de code de type (0x10 = int32), le nom de champ x comme chaîne terminée par null (2 octets), 4 octets pour la valeur entière, et un octet terminateur de document. JSON est plus court pour les petites charges utiles mais BSON gagne sur la vitesse d’analyse et sur les documents avec des types non-string. Exemple concret : stocker une transaction financière avec un prix Decimal128 de 123,45 fait un aller-retour exact via BSON ; via JSON il devient 123.45 comme flottant et risque de revenir comme 123.44999999999999 en JavaScript. La représentation Decimal128 fait 16 octets quelle que soit la magnitude.

Quand et pourquoi ça compte

Si vous construisez une application sur MongoDB et persistez de l’argent, vous devriez le stocker en Decimal128, pas comme un Number JavaScript sérialisé en JSON. Les schémas Mongoose utilisent par défaut Number, ce qui devient double en BSON, ce qui introduit silencieusement des arrondis IEEE-754 sur des prix comme 0,10 + 0,20. La même remarque s’applique aux dates : stocker des dates comme des chaînes (« 2026-01-15 ») perd l’ordonnancement indexable à travers les fuseaux horaires ; les stocker comme Date BSON préserve la précision à la milliseconde et permet aux requêtes de plage d’utiliser efficacement les index B-tree. Lors de la migration de données vers ou depuis MongoDB, utilisez mongoexport --jsonFormat=canonical plutôt que le mode relaxed pour préserver les informations de type BSON à travers l’intermédiaire JSON. Référence : Manuel MongoDB — Types BSON.