Se avessi chiesto a un professionista IT se l’object storage è utile per i database, la risposta per la maggior parte degli ultimi dieci anni circa sarebbe stata un sonoro “no”.
La risposta sarebbe stata abbastanza ovvia perché i database, specialmente in ambienti affollati e mission-critical, sono soggetti a molte modifiche da parte di molti utenti, contemporaneamente o quasi contemporaneamente.
I database necessitano di IOPS (operazioni di input/output al secondo) e hanno bisogno di un modo per imporre la coerenza dei dati, il che significa che lo storage SAN con accesso a blocchi è stato a lungo il modo per fornirlo.
Tuttavia, quella risposta “no” potrebbe essere cambiata negli ultimi anni in qualcosa di più simile a un “forse”.
Con l’aumento dei database che utilizzano l’archiviazione in memoria, gli IOPS sono in abbondanza vicino al calcolo, quindi è diventato possibile che l’archiviazione degli oggetti sia il sito per l’archiviazione in blocco dei set di dati, con i segmenti spostati in memoria durante l’elaborazione.
Ma si tratta di operazioni di database che utilizzano l’archiviazione di oggetti?
Le SAN sono buone per IOPS ma la capacità rappresenta un collo di bottiglia
Per un paio di decenni, lo storage SAN ad accesso a blocchi è stato il punto di riferimento per l’esecuzione di database e le applicazioni aziendali basate su di essi. IOPS era il re, poiché potenzialmente numerose richieste di I/O colpivano il database dai sistemi client.
Per far fronte, le SAN sono diventate sempre più grandi e performanti, con l’eventuale adozione mainstream di flash media molto rapidi, in termini IOPS. L’attuale consiglio di NetApp sul dimensionamento dello storage per SAP HANA, ad esempio, riguarda gli HDD SAS (presumibilmente in loco) e la capacità flash.
Ma mentre le SAN possono fornire in termini di IOPS, anche se diventa parzialmente ridondante quando i database delle applicazioni entrano in memoria, hanno comunque i loro limiti, e questo in termini di scalabilità. Qui, la conservazione degli oggetti eccelle. Non può produrre il tipo di IOPS che una SAN può fornire alle operazioni del database, ma può fornire un throughput in grandi volumi.
Ci sono due buone ragioni per cui questo è un grosso problema in questo momento. Primo, per diversi anni i volumi di dati analizzati sono diventati sempre più grandi. Con lo storage di accesso a blocchi o file che inizia a diventare ingombrante al di sopra dei 100 TB, lo storage di oggetti sembra una buona scommessa con la sua capacità di scalare a PB.
Allo stesso tempo, l’archiviazione degli oggetti è diventata la modalità di archiviazione de facto per il cloud, aumentando la sua prevalenza sia fuori sede che in loco. Inoltre, come parte dello scenario, abbiamo assistito all’emergere di applicazioni basate su database in memoria come SAP HANA distribuite nel cloud.
Un grande vantaggio dell’archiviazione di oggetti nel cloud è il basso costo. Su Amazon, ad esempio, lo storage di file o blocchi può costare 10 volte di più rispetto allo storage di oggetti.
Object storage, S3 come bulk storage per database, AI/ML
Con l’emergere dello storage di oggetti, e in particolare di S3, abbiamo assistito all’aumento del suo utilizzo come storage di massa che può essere distribuito al lavoro di database in memoria e per l’analisi AI/ML.
Accanto a questa traiettoria c’è stato l’emergere di database che funzioneranno con S3 (o storage compatibile con S3) come archivio dati, come MongoDB, CockroachDB, MariaDB e Teradata. Anche il fenomeno del cloud data warehousing Snowflake è basato su S3.
Ma dobbiamo ricordare i limiti. Le SAN funzionano bene con i database perché le richieste degli utenti stanno letteralmente entrando e leggendo, scrivendo e così via in parti di file. Esistono meccanismi per limitare il potenziale di conflitti tra le richieste degli utenti.
L’archiviazione degli oggetti non può funzionare allo stesso modo di un’origine dati per i database come possono fare i file, con blocchi all’interno che possono essere manipolati, ma è possibile archiviare i dati con capacità molto maggiori nell’archiviazione degli oggetti. L’architettura per l’archiviazione degli oggetti e il lavoro con i database è diversa, con quest’ultimo messo in scena in memoria per i processi di lavoro e quindi inviato nuovamente all’archivio di backup degli oggetti.
Ciò rende l’archiviazione degli oggetti più simile a un archivio in questi casi? Forse, sebbene fornitori come Minio abbiano accettato la sfida di fornire un rapido accesso ai set di dati archiviati nell’archiviazione di oggetti per casi d’uso di database e analisi. Minio lo chiama storage “caldo”, quindi chiaramente non è incredibilmente veloce in termini di I/O e maggiore in termini di throughput.
S3 Seleziona – S3 incontra SQL
L’idea di archivi oggetti molto grandi con la possibilità di scegliere il sottoinsieme di dati che si desidera e lavorare su questa è l’idea alla base di S3 Select. Qui usi le istruzioni di query SQL per filtrare il contenuto di un archivio dati e semplicemente estrarre i dati desiderati. Ciò riduce i costi di uscita dei dati e offre un set di dati più piccolo e una latenza inferiore.
I risultati di S3 Select sono disponibili nei formati CSV, JSON e Apache Parquet e puoi eseguire query dalla console AWS, dalla riga di comando o tramite API, il che significa che è del tutto possibile selezionare i dati da S3 per l’analisi su un calcolo locale più veloce.
Tuttavia, non è davvero un database. E con i dati che arrivano in formati specifici, come CSV e JSON, avrà bisogno di un po’ di codifica per inserirli nel tuo strumento di analisi preferito.
Quindi, l’archiviazione degli oggetti è utile per i database? Il verdetto è: dipende – o non proprio.
L’archiviazione degli oggetti non può archiviare i database in modo da fornire a più utenti l’accesso coerente con i principi di atomicità, coerenza, isolamento e durabilità (ACID). L’archiviazione degli oggetti è disponibile per casi d’uso che soddisfino le esigenze di elaborazione transazionale. L’archiviazione oggetti non dispone dell’I/O o dei meccanismi di blocco dei file secondari per eseguire questa operazione.
L’archiviazione degli oggetti, tuttavia, eccelle nell’archiviazione di grandi volumi di dati, di cui un sottoinsieme può essere scaricato, a velocità di trasmissione potenzialmente elevate, per la conservazione in memoria durante l’elaborazione locale. Questi sono i tipi di approcci promossi da artisti del calibro di Minio e possibilmente nei casi d’uso che utilizzano AWS S3 Select. Ma stiamo parlando principalmente dell’elaborazione in batch dei dati nelle impostazioni di analisi.