Lettera aperta contro le applicazioni che memorizzano file mostruosi dove non dovrebbero.

Sono grandi. Sono lenti. Sono ingestibili. E lo diventano ogni giorno di più. Sono database usati per ospitare migliaia e migliaia di file al loro interno: immagini, documenti, archivi di ogni sorta e dimensione. Questa settimana me ne sono capitati ben tre lungo la strada, per cui è arrivato il momento di condividere qualche riflessione in merito per aiutarci a prevenire fastidiosi grattacapi.

Un percorso minato

Molti DBMS prevedono il supporto per campi LOB (Large Objects) che consentono la memorizzazione di file binari all’interno di tabelle. Questa possibilità viene valutata con favore da molti sviluppatori perché consente di mantenere in un unico luogo fisico (il database) sia i record di dati, sia gli eventuali file ad essi associati e svincola l’applicazione dal dover gestire oltre al database anche un repository su filesystem. Inizialmente sembra un’ottima idea, quando però il volume dei documenti cresce (e di solito lo fa) ci si ritrova rapidamente con database da diverse centinaia di Gigabyte, con i conseguenti problemi di gestione. Di fatto l’esperienza ci dice che, da un punto di vista infrastrutturale, stipare grandi file all’interno di un database relazionale è una cattiva idea nella maggior parte dei casi e che il posto migliore dove memorizzare i file resta il file-system (lasciando nel database solo i puntamenti a tali file). Vediamo perché.

• Costi. I costi per mantenere un gigabyte di dati all’interno di un DBMS sono almeno 10 volte superiore a quelli necessari per mantenere la stessa quantità di dati sul file-system. Un database necessita infatti di maggiori risorse hardware di un semplice file-system, può richiedere l’acquisizione di licenze software ed è soggetto a procedure di manutenzione e gestione indubbiamente più complesse (deploy, tuning, backup, ecc.). Tenere database di grandi dimensioni pone sfide affrontabili solo da tecnici altamente qualificati ed esperti.
• Performance. L’estrazione di un file da una tabella è un’operazione lenta perché i database relazionali sono pensati per servire insiemi di dati strutturati e non flussi binari. Peraltro i file prelevati dal database difficilmente potranno sfruttare le cache presenti nel percorso tra client e server (ad esempio le cache all’interno del browser, del web server o dei proxy), con notevoli ricadute sulle prestazioni.
• Backup inefficienti. Più il database aumenta di dimensione, più il backup diventa lento ed inefficiente. Uno dei clienti che mi ha contattato questa settimana era bloccato perché la procedura di backup schedulata quotidianamente era arrivata a durare più di 24 ore!
• Tornare indietro è costoso. Una volta che il database ha assunto proporzioni gigantesche tornare indietro è molto difficile. Occorre innanzitutto modificare pesantemente l’applicazione per gestire i file nella nuova modalità e predisporre una procedura per migrare i “mostri” dal database al file system: un processo costoso e complicato.

Tutte queste ragioni dovrebbero essere sufficienti a farci stare alla larga dalle applicazioni che usano il database come un repository. Purtroppo il DBA (database administrator) non ha alcuna voce in capitolo e tali scelte architetturali sono spesso lasciate al software architect. Nel caso di applicazioni pacchettizzate o fornite da un ISV, non vi è alcun margine di manovra in quanto l’applicazione è già sviluppata.

Qualche vantaggio? Sì, ma…

Perché spesso gli sviluppatori prediligono la memorizzazione dei file nel database? Quali sono i possibili vantaggi?

• Dati e documenti sono centralizzati in un unico contenitore; pertanto con il backup o la replication del database si ha il backup o la replication sia dei dati sia dei documenti;
• Il software deve gestire una sola modalità di accesso ai dati anziché due (database e filesystem);
• Può essere garantita la consistenza ACID delle transazioni evitando che il database ed il file-system si “desincronizzino” (ad es. esiste il puntatore al documento nel database, ma non esiste il file fisico sul file-system o viceversa).

Grandi vantaggi? Dipende dall’ambito e dal tipo di applicazione, ma l’esperienza ci dice che nei casi più comuni questi vantaggi non giustificano in alcun modo il “peso” che una scelta di questo tipo comporta sulla gestione e sui costi delle infrastrutture.

Quindi prima di fare entrare i pachidermi nel nostro database, pensiamoci bene. Farli uscire, domani, potrebbe essere molto doloroso.

Update

Va aggiunto per completezza che Oracle Database 11g introduce “Secure Files” che mira a superare tutte le limitazioni dei LOB (Large Objects), promettendo di ottenere prestazioni simili o superiori a quelle del file system, di ridurre il consumo di spazio grazie a funzioni di compressione e deduplica, e di aumentare la sicurezza dei file memorizzati all’interno del database. http://www.oracle.com/technetwork/articles/sql/11g-securefiles-084075.html

9.3.2014