FileStream: un ibrido tra l'archiviazione dei file nei blob e nel file system (parte 1)

L'annoso problema della gestione e memorizzazione di dati non strutturati (tipicamente file binari) ha da sempre avuto due diverse soluzioni:

1. archiviazione su file system;
2. archiviazione sotto forma di blob su database (nel caso di SQL Server in campi BINARY, VARBINARY o, nell’ormai deprecato, IMAGE).

Entrambi gli approcci presentano punti di forza e aspetti negativi.

L’archiviazione su file system non appesantisce l’operatività di SQL Server, garantisce buone prestazioni in lettura e scrittura, offre la possibilità di aprire stream di dati partendo direttamente dalla sorgente (il file).
Di contro si può evidenziare che la scelta di archiviazione su file system non garantisce un legame forte tra dati e database in quanto il legame stesso non è vincolato alle regole di integrità con i dati e alla gestione transazionale del db. Inoltre sono da riscontrare difficoltà nella gestione di eventuali backup e il fatto che la security dei file non sia quella cui sono sottoposti i dati del db. Da ciò discende l’esigenza di attivare politiche di backup e di security sui file parallele e coerenti con quelle di SQL Server.

L’approccio database garantisce la consistenza dei dati binari che, risiedendo in una tabella di SQL Server, sono soggetti anche alle normali politiche di backup e di sicurezza. Anche in questo contesto però sussistono alcuni punti deboli tra i quali si possono annoverare: le scarse prestazioni, l’appesantimento di SQL Server (memoria e cache) nelle fasi di ritrovamento e di memorizzazione dei blob, l’impossibilità di aprire stream di dati direttamente dal blob (il file viene caricato interamente in memoria prima di poter essere gestito applicativamente).
Se poi i blob da memorizzare sono di dimensioni notevoli, c’è il rischio di frammentazione fisica dei dati e di paging durante le operazioni di lettura degli stessi, nonchè di far lievitare pesantemente il file di log di SQL Server (naturalmente se il recovery model è di tipo full).

Per un ulteriore approfondimento dei pro e dei contro riguardo la questione, si consulti l’amletico documento di Microsoft research To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem.
Le conclusioni tratte dalla ricerca sono facilmente riassumibili con un assunto generale: con blob più piccoli di 256KB è più efficente SQL Server mentre con blob superiori ad 1MB è più efficente NTFS. Le situazione intermedia non presentano particolari vantaggi o svantaggi in una configurazione o nell’altra.

Una possibile alternativa

Con l’avvento di SQL Server 2008 il problema ha una nuova soluzione grazie all’introduzione di FILESTREAM, una tecnologia che punta ad offrire un buon compromesso tra le due soluzioni “tradizionali” prendendo il meglio e lasciando il peggio di entrambe.