--- id: 2bc35fc657eb35eb5dbcb7286c1033ba author: gosunuts title: 'Server di database e database embedded: confronto tra architettura e caratteristiche di I/O' description: Questo studio confronta i RDBMS basati su processi indipendenti con i database embedded in-process, quali SQLite, RocksDB, BadgerDB e PebbleDB, dal punto di vista della latenza di I/O su NVMe SSD, dell'isolamento dei dati in MSA e della struttura di deployment. language: it date: 2025-08-21T12:11:23.268337247Z path: /blog/posts/database-servers-and-embedded-databases-zd4cb799f category: database --- ## Server di database Un server di database è un database che viene eseguito come processo server indipendente e gestisce le richieste delle applicazioni attraverso la rete. MySQL, PostgreSQL, Oracle DB e gran parte degli RDBMS a noi familiari appartengono a questo modello. Il server di database presenta i seguenti vantaggi. - **Gestione centralizzata**: i dati sono gestiti in modo integrato in un unico punto, il che facilita la coerenza, la sicurezza, il backup e il ripristino. - **Indipendenza delle risorse**: disponendo di CPU, memoria e storage dedicati, garantisce prestazioni stabili indipendentemente dallo stato dell'applicazione. - **Elevata concorrenza e scalabilità**: è ottimizzato per l'accesso simultaneo di molti utenti e la scalabilità orizzontale tramite clustering o replica risulta relativamente agevole. Grazie a queste caratteristiche, il server di database si è affermato come standard dell'infrastruttura software per diversi decenni. Tuttavia, con l'evoluzione tecnologica e i cambiamenti del contesto, in alcuni ambienti sono emersi i limiti del server di database e, come alternativa, il database embedded ha ricominciato a suscitare attenzione. ## Una nuova tendenza: il database embedded Un database embedded è un motore di database che non richiede un processo server separato, ma viene incluso nell'applicazione sotto forma di libreria e viene eseguito all'interno dello stesso processo. SQLite, LevelDB e RocksDB sono esempi rappresentativi di database embedded. Le ragioni per cui questi database sono emersi come alternative valide nel contesto tecnologico attuale sono le seguenti. - **L'avvento dell'SSD** In passato, nei sistemi basati prevalentemente su HDD, le prestazioni di accesso casuale erano sensibilmente inferiori rispetto a quelle di lettura e scrittura sequenziali. Pertanto, minimizzare l'I/O su disco e massimizzare il caching in memoria era il fulcro dell'ottimizzazione delle prestazioni. I server di database hanno superato i limiti fisici degli HDD gestendo cache di grandi dimensioni e accorpando le operazioni di scrittura. Tuttavia, l'avvento dell'SSD ha stravolto completamente tale presupposto. Gli SSD offrono prestazioni di I/O casuale migliaia di volte superiori a quelle degli HDD e una latenza notevolmente inferiore. Di conseguenza, la convinzione che "l'I/O su disco sia il collo di bottiglia principale" è venuta meno e, al contrario, la latenza derivante dall'accesso remoto al server di database tramite rete ha iniziato a emergere come nuovo collo di bottiglia. - **MSA e indipendenza dei dati** In passato era comune una struttura in cui un'unica grande applicazione monolitica dipendeva da un unico database centralizzato. Questo approccio è semplice, ma con la crescita della scala del servizio diventa difficile modificare lo schema dei dati e, poiché tutti i servizi condividono lo stesso DB, l'accoppiamento tra essi diventa eccessivo. Nell'architettura a microservizi moderna, per risolvere tali problemi, viene data importanza al principio "Database per Service". Ogni servizio possiede e incapsula il proprio archivio dati dedicato, il che garantisce l'indipendenza tra i servizi e rende più agevoli l'isolamento dei guasti e la scalabilità. In questo contesto, il DB embedded diventa una scelta ideale come archivio dati a livello di servizio. È leggero e veloce e, poiché può essere distribuito insieme al codice del servizio, si adatta molto bene all'ambiente MSA. In particolare, negli ambienti Kubernetes è ampiamente diffuso il pattern sidecar, che consiste nel collocare un DB embedded accanto al container dell'applicazione per ottimizzare l'elaborazione dei dati in locale. Ciò riduce il collo di bottiglia della rete e minimizza la latenza di accesso ai dati. - **Semplificazione dell'ambiente operativo** I server di database richiedono procedure operative complesse come installazione, patch, backup, ripristino da guasti, replica e monitoraggio delle prestazioni, e per gestirle sono necessari un DBA dedicato e personale operativo specializzato. Soprattutto in ambienti di grandi dimensioni, questo carico di gestione è molto oneroso. Il database embedded attenua notevolmente tali problemi. Quando il database è integrato all'interno dell'applicazione, test unitari, build, controllo di versione e deployment avvengono insieme, pertanto non è necessaria una gestione separata del server. Inoltre, quando l'applicazione viene scalata orizzontalmente, anche il database embedded si espande di conseguenza, e diventa possibile una gestione automatizzata attraverso la cultura DevOps e le pipeline CI/CD. In particolare, negli ambienti di startup, servizi di piccole dimensioni e sviluppo di prototipi, il database embedded riduce drasticamente la complessità operativa e accelera notevolmente lo sviluppo e il deployment. - **Linguaggi di sistema ad alte prestazioni ed evoluzione dell'ecosistema** In passato era comune che database e applicazioni fossero scritti in linguaggi diversi. Ad esempio, i motori di database che richiedevano prestazioni elevate erano scritti principalmente in C e C++, mentre le applicazioni erano sviluppate in linguaggi come Java, Python e PHP. Questo approccio era efficace per l'ottimizzazione delle prestazioni, ma presentava limiti quali problemi di sicurezza della memoria, gestione complessa della concorrenza, latenza e difficoltà nell'integrazione e nel deployment delle librerie. Tuttavia, con l'affermarsi di linguaggi di programmazione di sistema moderni come Go e Rust, tali limiti si sono notevolmente attenuati. In particolare, Go è adatto non solo allo sviluppo di applicazioni ad alte prestazioni, ma anche alla scrittura di programmi di basso livello come i motori di database, consentendo di gestire database e applicazioni all'interno di un unico ecosistema linguistico. Di fatto, in Golang sono ampiamente utilizzati database embedded ad alte prestazioni come [BadgerDB](https://github.com/hypermodeinc/badger) e [PebbleDB](https://github.com/cockroachdb/pebble). Ciò significa che il database embedded non è più soltanto un'alternativa leggera al server di database, ma si è affermato come una scelta importante e dotata di una propria competitività. ## Conclusione Quando sono richiesti la gestione centralizzata di dati su larga scala, transazioni complesse e un'elevata concorrenza, il server di database rimane la soluzione più potente. Tuttavia, per i singoli servizi in ambiente MSA, i dispositivi edge IoT, la prototipazione rapida e i progetti in cui l'efficienza operativa è fondamentale, il database embedded può rappresentare una scelta più efficiente e ragionevole. In definitiva, ciò che conta è scegliere lo strumento ottimale, più adatto al contesto e ai requisiti dati, e lo sviluppo dei database embedded ci offre opzioni più ampie e variegate.