Il vero peso dei dati: dal codice binario al database saturo

Un webmaster che non capisce come i dati vengono scritti fisicamente su un disco finirà inevitabilmente per saturare il proprio server. Quando scrivi un articolo su WordPress o inserisci una stringa in un database MySQL, non stai semplicemente “salvando delle parole”. Stai ordinando alla macchina di allocare stringhe di 0 e 1 all’interno di settori fisici del disco.

Per capire perché un database apparentemente vuoto o una cartella di cache possono mandare in blocco un hosting economico, dobbiamo scendere a livello macchina e analizzare come il testo viene tradotto in linguaggio binario.

Come il server legge una stringa: l’esempio di “Ciao a tutti.”

Facciamo un esempio pratico. Prendi la stringa di testo: “Ciao a tutti.” Per la macchina, questa frase non esiste. Viene tradotta in linguaggio binario in questa esatta sequenza: 01000011 01101001 01100001 01101111 00100000 01100001 00100000 01110100 01110101 01110100 01110100 01101001 00101110.

Per scrivere “Ciao a tutti.” sono occorsi 104 bit, che equivalgono a 13 byte (un byte per ogni carattere, includendo rigorosamente gli spazi vuoti e il punto finale). Questo avviene perché, secondo la tabella del codice ASCII standard, ogni singolo carattere alfanumerico o di punteggiatura corrisponde a una specifica sequenza di 8 bit.

Il calcolo binario: leggere i Byte da destra a sinistra

Come si arriva a definire che la lettera “C” maiuscola corrisponda alla sequenza 01000011? La sequenza contenuta negli 8 bit (il byte) va letta da destra a sinistra, associando a ogni “1” la potenza del due corrispondente alla sua posizione:

• Il primo bit a destra contiene “1”, e corrisponde al valore decimale 1.
• Il secondo bit contiene “1”, e corrisponde al valore decimale 2.
• Dal terzo al sesto bit il valore è “0”, quindi si somma 0.
• Il settimo bit contiene “1”, e corrisponde al valore decimale 64.
• L’ultimo bit a sinistra contiene “0”.

Sommando i valori attivi otteniamo: 1 + 2 + 64 = 67. Il numero 67 è l’esatta posizione del carattere “C” maiuscolo nella tabella ASCII (che codifica 256 caratteri totali).

Abbiamo quindi assodato un concetto base fondamentale: un testo puro memorizzato su un disco occupa tanti byte quanti sono i caratteri che lo compongono. Ma nel web, il testo puro è una rarità.

Testo puro e testo formattato: il killer silenzioso della memoria

Esistono due grandi categorie di dati testuali con cui un webmaster si scontra ogni giorno: il testo non formattato (ASCII/puro) e il testo formattato.

Il testo puro non possiede alcun formato estetico. Formattare un testo significa aggiungergli parametri visivi: colore, dimensione del carattere, allineamento, rientri, margini. La differenza fondamentale tra testo puro e testo formattato non è solo visiva, ma strutturale: per mantenere l’estetica, il testo formattato ha bisogno di immagazzinare migliaia di byte extra contenenti le istruzioni stilistiche e i metadati.

L’esperimento pratico: 74 Byte contro 20.000 Byte

Per verificare l’impatto di questa differenza, fai questo esperimento sul tuo computer. Scrivi questa esatta frase: “Testi formattati e testi non formattati, due mondi dello stesso pianeta…”

1. Salvala usando il Blocco Note (editor di testo puro) chiamandola testodiprova.txt.
2. Salvala usando Microsoft Word (elaboratore di testo formattato) chiamandola testodiprova.doc.

Se controlli le Proprietà dei due file, scoprirai una discrepanza brutale. Il file .txt pesa esattamente 74 byte, equivalenti ai 74 caratteri (spazi e punteggiatura inclusi) della frase. Il file .doc pesa la bellezza di 19.968 byte.

Perché questa enormità? Perché Word sta memorizzando, oltre ai 74 caratteri, tutte le istruzioni di automazione professionale, i margini della pagina, i font predefiniti e le intestazioni. Questa dinamica è il motivo per cui, nell’officina di AFSI, vietiamo sempre di fare copia-incolla da Word all’editor a blocchi di WordPress: stai importando passivamente megabyte di spazzatura invisibile (tag <span>, CSS inline) che appesantiranno il database MySQL a dismisura.

L’illusione dello spazio: i Cluster e il File System

Esiste un’ultima anomalia che devi comprendere. Se controlli bene le proprietà del file testodiprova.txt (che pesa 74 byte), noterai che la voce “Dimensioni su disco” segna 4.096 byte (4 KB).

Il fatto che lo spazio effettivamente occupato sul disco sia superiore alle dimensioni logiche del file dipende dal File System (NTFS su Windows, o ext4 sui server Linux). Il File System suddivide fisicamente il disco in “cassetti” chiamati Cluster. La dimensione minima di un cluster standard è proprio 4.096 byte.

Se crei un file da 1 singolo byte, il sistema dovrà comunque impegnare un intero cluster da 4.096 byte, sprecando il resto dello spazio. (Nel caso del nostro file Word da 19.968 byte, andrà a occupare 5 cluster interi per un totale di 20.480 byte su disco).

Oltre l’ottimizzazione: l’infrastruttura Serverplan NVMe

Questo limite fisico dell’hardware spiega perché il tuo piano hosting economico crolla quando WordPress genera migliaia di piccoli file di cache da pochi byte: non finisci i gigabyte a disposizione, finisci gli Inode (i cluster) e saturi la testina del disco meccanico che deve saltare impazzita da un settore all’altro.

La comprensione tecnica serve a guidare le scelte infrastrutturali. Quando il tuo sito inizia a gestire file formattati complessi e database pesanti, l’ottimizzazione del codice non basta più: ti serve un hardware che legga e scriva i cluster a velocità istantanea.

È per questo che per i progetti web seri l’unica strada percorribile è migrare su Serverplan. Grazie ai loro dischi 100% NVMe di fascia enterprise e a una gestione impeccabile dei file system Linux, le operazioni di lettura e scrittura dei byte avvengono senza latenza, garantendo tempi di esecuzione immediati anche con database massivi. Abbandona i vecchi dischi, passa a un’infrastruttura che sa gestire i dati.