Glossary
BSON
Binary JSON, il formato di archiviazione di MongoDB
By Buğra SözeriPublished Updated
BSON (Binary JSON) è il formato dati binario che MongoDB usa per l’archiviazione e la comunicazione su rete. Con struttura JSON a livello API — stessa gerarchia oggetto/array — ma binario su disco e in rete.
Perché un formato binario quando esiste JSON:
- Fedeltà del tipo. JSON ha solo stringa, numero, booleano, null, oggetto, array. BSON aggiunge Date, Binary, ObjectId, Decimal128, Regex, Timestamp, Int32 vs Int64. I round-trip attraverso BSON preservano il tipo esatto.
- Intestazioni di lunghezza auto-descrittive. Ogni documento e valore BSON è preceduto dalla sua lunghezza, quindi MongoDB può saltare i campi senza analizzarli. JSON richiede la lettura dall’inizio.
- Aritmetica decimale. Il tipo Decimal128 di BSON memorizza numeri decimali esatti fino a 34 cifre significative — importante per i dati finanziari dove i float IEEE 754 arrotondano male.
I file BSON sono tipicamente del 10-20% più grandi del JSON equivalente a causa delle intestazioni di lunghezza e dei tag di tipo espliciti, ma le prestazioni delle query sono notevolmente più veloci perché MongoDB non deve analizzare il documento per trovare un campo.
La maggior parte dei driver MongoDB (Node, Python, Java, Go) converte automaticamente tra BSON e i tipi nativi del linguaggio. Raramente si interagisce direttamente con BSON a meno che non si stia scrivendo un driver o leggendo i file di backup bson al di fuori di MongoDB stesso.
Il limite di 16 MB per documento: un singolo documento BSON non può superare i 16 megabyte. Questo è un vincolo rigido del server MongoDB, non un limite della specifica BSON — il formato stesso usa lunghezze con segno a 32 bit e potrebbe teoricamente raggiungere i 2 GB. Il limite di 16 MB protegge dai casi d’uso degenerati (memorizzare interi libri o binari di immagini all’interno di un documento) e corrisponde alle dimensioni della tipica finestra di pacchetti di rete. La crescita del documento oltre il limite forza un workaround GridFS (dividere il payload in chunk su più documenti), o una riprogettazione dove i blob di grandi dimensioni si trovano nell’object storage con il documento che contiene un riferimento.
Perché l’ObjectId di BSON è a 12 byte e non un UUID: il _id predefinito di MongoDB è un ObjectId a 12 byte composto da un timestamp Unix a 4 byte, un identificatore di «processo» casuale a 5 byte (sostituisce il vecchio split machine-id/PID) e un contatore incrementale a 3 byte. La struttura fornisce l’ordinamento temporale (i documenti più recenti si ordinano naturalmente alla fine) ed evita il costo di coordinazione di un UUID4. Il compromesso è 12 byte vs 16 per UUID, che su un miliardo di documenti risparmia 4 GB di archiviazione della chiave primaria. Le collezioni più recenti spesso usano UUID v7 al posto per la compatibilità tra database. Correlato: IEEE 754, BigInt. Riferimento: BSON Specification.
Esempio pratico
Il documento JSON {"x": 1} è di 8 byte come testo. Lo stesso documento in BSON è 0C 00 00 00 10 78 00 01 00 00 00 00 — 12 byte: 4 byte di lunghezza totale, 1 byte di codice tipo (0x10 = int32), il nome del campo x come stringa terminata con null (2 byte), 4 byte per il valore intero e un terminatore di documento a 1 byte. JSON è più corto per payload piccoli ma BSON vince sulla velocità di analisi e sui documenti con tipi non-stringa. Un esempio reale: memorizzare una transazione finanziaria con un prezzo Decimal128 di 123,45 fa il round-trip esattamente attraverso BSON; attraverso JSON diventa 123,45 come float e rischia di tornare come 123,44999999999999 in JavaScript. La rappresentazione Decimal128 è di 16 byte indipendentemente dalla grandezza.
Quando e perché è importante
Se costruisci qualsiasi app su MongoDB e persisti denaro, dovresti archiviarlo come Decimal128, non come un Number JavaScript serializzato in JSON. Gli schemi Mongoose usano per impostazione predefinita Number, che diventa double in BSON, che introduce silenziosamente l’arrotondamento IEEE-754 su prezzi come 0,10 + 0,20. Lo stesso vale per le date: memorizzare le date come stringhe («2026-01-15») perde l’ordinamento indicizzabile attraverso i confini del fuso orario; memorizzarle come BSON Date preserva la precisione in millisecondi e consente alle query di intervallo di usare efficientemente gli indici B-tree. Quando si migrano dati dentro o fuori da MongoDB, usa mongoexport --jsonFormat=canonical piuttosto che la modalità relaxed per preservare le informazioni sul tipo BSON attraverso l’intermediario JSON. Riferimento: MongoDB Manual — BSON Types.
Frequently asked questions
- Che cos'è BSON?
- BSON (Binary JSON) è il formato di serializzazione binaria che MongoDB usa per archiviare e trasmettere documenti. Estende JSON con tipi di dati aggiuntivi — incluse date, dati binari, ObjectId e interi a 64 bit — ed è progettato per la traversata rapida e gli aggiornamenti sul posto.
- Quali tipi supporta BSON che JSON non supporta?
- BSON aggiunge: Date (millisecondi a 64 bit dall'epoch), ObjectId (ID univoco a 12 byte), Int32, Int64, Decimal128 (per decimali esatti), Binary, Regular Expression e Undefined. JSON ha solo stringa, numero, booleano, null, array e oggetto.
- BSON è più efficiente in termini di spazio rispetto a JSON?
- Non necessariamente — BSON incorpora i nomi dei campi e le informazioni sul tipo in ogni documento, rendendolo spesso più grande del JSON compatto. Il suo vantaggio è la velocità: le stringhe e gli array con prefisso di lunghezza consentono ricerche di dimensioni O(1), abilitando l'analisi più rapida e gli aggiornamenti sul posto dei campi senza ri-serializzare l'intero documento.
- Cos'è un ObjectId di MongoDB e come è costruito?
- Un ObjectId è un valore BSON a 12 byte usato come _id predefinito. Codifica un timestamp Unix a 4 byte, un valore casuale a 5 byte univoco per la macchina e il processo, e un contatore incrementale a 3 byte — rendendolo ordinabile per ora di creazione e globalmente univoco senza un coordinatore centrale.
Related
Published May 15, 2026 · Last reviewed May 31, 2026