Il problema della poliglotta: risolvere il paradosso del database “giusto”

( Leszek Glasner/)

La persistenza poliglotta, introdotta per la prima volta nel 2011, è ora quasi il diritto canonico. Quindi, quello che ho da dire può venire attraverso come blasfemia.

La maggior parte delle organizzazioni oggi ha adottato il concetto di persistenza poliglotta, implementando una varietà di diverse tecnologie di archiviazione dei dati basate sulla varietà di modi in cui interrogano, analizzano e distribuiscono i propri dati. E la crescita e la pervasività degli archivi di dati key/value, graph, time series e JSON ha fornito agli sviluppatori abbondanti scelte per scegliere lo strumento di dati giusto per il lavoro giusto.

Ma le richieste su di noi come sviluppatori si sono rapidamente evolute e credo che la persistenza poliglotta farà rapidamente fatica a tenere il passo. O, forse, questa è già la realtà che stai affrontando oggi. Perché? Perché il compito che abbiamo è scoraggiante e team di sviluppo sono già allungato sottile.

Database Diversity

Abbiamo bisogno di essere esperti in un ampio spettro di tecnologie di database, ognuno con i propri linguaggi di query. Abbiamo bisogno che le nostre applicazioni forniscano risultati efficienti in un numero crescente di casi d’uso. E ci viene chiesto di creare e gestire centinaia di migliaia di diverse applicazioni basate sui dati che richiedono una varietà di modelli di dati e distribuzioni. Riesci a immaginare di padroneggiare e mantenere un’altra tecnologia o un linguaggio di query? Che ne dici di altri cinque? Altri dieci?

Il software sta mangiando il mondo, i nostri sforzi di sviluppo cresceranno, i tempi e i costi per integrare più datastore sono insostenibili e gli sviluppatori hanno disperatamente bisogno di concentrarsi su un insieme finito di tecnologie di database.

Ancora più importante, i casi d’uso stanno crescendo in sofisticazione e ciò che chiederemo ai nostri dati richiederà l’uso di più modelli di dati, forse anche istantaneamente. La creazione di soluzioni alternative nel codice dell’applicazione per calcolare le query non è sostenibile o scalabile. Credo che sia tempo che le organizzazioni cerchino approcci ibridi che consentano loro di semplificare il loro portafoglio tecnologico e avere la flessibilità di scegliere il modello di dati giusto per il lavoro giusto.

Esplorazione dei modelli di dati

Ho scoperto che è utile capire quali modelli di dati funzionano bene per usi diversi e come questi possono essere combinati.

Database di documenti JSON

JSON è molto versatile per dati non strutturati e strutturati. La natura ricorsiva di JSON consente l’incorporamento di sottodocumenti e liste di lunghezza variabile. Inoltre, è anche possibile memorizzare le righe di una tabella come documenti JSON e gli archivi di dati moderni sono così bravi a comprimere i dati che non vi è essenzialmente alcun sovraccarico di memoria rispetto ai database relazionali. Per i dati strutturati, la convalida dello schema può essere implementata secondo necessità utilizzando un’API HTTP estensibile.

Database grafici

I database grafici sono buoni modelli di dati per le relazioni. In molti casi reali, un grafico è un modello di dati molto naturale. Cattura le relazioni e può contenere informazioni sull’etichetta con ciascun bordo e con ciascun vertice. I documenti JSON sono una misura naturale per memorizzare questo tipo di vertice e dati di bordo.

Un database grafico è particolarmente utile per le query “graphy”. La cosa cruciale qui è che il linguaggio di query deve implementare routine come “percorso più breve” e “attraversamento del grafico”, la capacità fondamentale per questi è accedere rapidamente all’elenco di tutti i bordi in uscita o in entrata di un vertice.

Database multi-modello

Un database multi-modello combina le funzionalità di database di documenti, chiavi/valori e grafici. Consente di scegliere diversi modelli di dati con un sovraccarico meno operativo. Avere più modelli di dati disponibili in un singolo motore di database allevia alcune delle sfide dell’utilizzo di diversi modelli di dati allo stesso tempo, perché significa meno sovraccarico operativo e meno sincronizzazione dei dati, e quindi consente un enorme salto nella flessibilità della modellazione dei dati.

Improvvisamente hai la possibilità di tenere insieme i dati correlati nello stesso archivio dati, anche se ha bisogno di modelli di dati diversi. La possibilità di combinare i diversi modelli di dati all’interno di una singola query aumenta le opzioni per la progettazione delle applicazioni e le ottimizzazioni delle prestazioni. E se si sceglie di dividere il livello di persistenza in diverse istanze di database diverse (anche se utilizzano lo stesso modello di dati), si ha comunque il vantaggio di dover distribuire una singola tecnologia. Inoltre, un modello di dati lock-in è impedito.

La soluzione poliglotta

La persistenza poliglotta è stata accettata perché ci ha permesso di evitare di compromettere una tecnologia di database monolitico. Abbiamo capito che la persistenza della poliglotta aveva un costo in termini di complessità, un costo per le prestazioni e un costo per la coerenza e la disponibilità man mano che i cluster diventavano sempre più grandi. Ma la maggior parte, se non tutti, di noi ha ritenuto che i benefici della flessibilità del modello di dati abbiano superato di gran lunga tali costi perché un database monolitico non esisterebbe mai e non esisterà mai per affrontare tutti o anche la maggior parte dei requisiti e dei casi d’uso.

Oggi, è chiaro che abbiamo bisogno dei benefici della persistenza poliglotta senza il costo. Dobbiamo avere la flessibilità necessaria per creare applicazioni ad alte prestazioni in grado di scalare orizzontalmente e utilizzare una varietà di modelli di dati. Abbiamo bisogno di linguaggi di query che ci consentano di eseguire query nativamente e su diversi modelli di dati. Abbiamo bisogno di database per darci la libertà e la flessibilità di utilizzare diversi modelli di dati in modi unici come i nostri progetti inevitabilmente evolvono.

Per molte organizzazioni avanzate, è già comune utilizzare un piccolo database grafico in una parte di un progetto, una distribuzione chiave/valore di grandi dimensioni per un’altra o una combinazione di modelli grafico, chiave/valore e documento (JSON) per un’altra.

Versatilità dei dati

Considera un insieme di dati complesso come quello per una flotta di aeromobili composta da diversi aeromobili, ognuno composto da diversi milioni di parti, che formano sottocomponenti, quindi componenti più grandi e più piccoli, che rientrano tutti in una gerarchia di “elementi.”

Per una manutenzione ottimale della flotta, l’organizzazione deve memorizzare una varietà di dati a diversi livelli della gerarchia, ad esempio nomi di parti o componenti, numeri di serie, informazioni sul produttore, intervalli di manutenzione, date di manutenzione, informazioni sui subappaltatori, collegamenti a manuali e documentazione, persone di contatto, informazioni sul contratto di garanzia e assistenza, ecc. Questo tipo di gerarchia dei dati è una chiara misura naturale per un database grafico perché acquisisce relazioni tra diversi punti dati, incluse le informazioni su ciascun bordo e vertice. Ma un database grafico è ideale per rispondere in modo efficiente alle domande chiave del team di manutenzione della flotta?

Un database grafico funziona bene per la domanda: “Quali sono tutte le parti in un dato componente?”E potrebbe essere in grado di aiutare a rispondere alla domanda: “Data la parte rotta A, qual è il componente più piccolo dell’aeromobile che contiene la parte e per il quale esiste una procedura di manutenzione?”Ma un database grafico sarebbe un po’ inutile con una domanda comune come ” Quali parti di questo aereo hanno bisogno di manutenzione la prossima settimana?”perché la struttura del grafico non si adatta alla query.

Tuttavia, se i dati del grafico possono essere archiviati come documenti JSON, associando dati arbitrari a vertici e bordi, è possibile rispondere facilmente a tale domanda tramite una query di documento.

Il punto è che per ottenere tutte le query in quel sistema fatto velocemente, è necessario un database in grado di memorizzare le informazioni come una varietà di modelli di dati, spesso chiamato un database multi-modello. Non sarebbe bello se quel database grafico potesse implementare indici secondari sui suoi dati di vertice?

Ma poi sarebbe essenzialmente diventato un database multi-modello. E ‘ un buon primo passo. Lo scenario ideale consiste nell’utilizzare contemporaneamente un grafico, un documento e un modello di dati chiave/valore per trovare prima le parti con manutenzione dovuta, eseguire il calcolo del percorso più breve sopra per ciascuna di esse e quindi eseguire un’operazione di join con la raccolta contatti per aggiungere informazioni di contatto concrete. L’accesso a un modello di dati diverso dovrebbe semplicemente cambiare una query, non il tuo database. Ecco dove dobbiamo andare, e presto.

Questo esempio di manutenzione della flotta non è unico o addirittura speciale. Parlando con gli sviluppatori, ho scoperto che è semplicemente un buon analogo per il numero crescente e la diversità dei casi d’uso che gli sviluppatori stanno vedendo. Dal mio punto di vista, l’apprendimento fondamentale della persistenza poliglotta è la necessità di utilizzare il modello di dati giusto per il lavoro giusto. E con le innovazioni nella tecnologia di database possiamo avere più di uno nello stesso motore di database. Altrimenti, dobbiamo riconoscere che la persistenza della poliglotta è il suo compromesso che ci limita e alla fine ci metterà dietro i nostri concorrenti.

Circa l’autore: Max Neunhoeffer è senior developer e architetto presso ArangoDB. Nella sua carriera accademica, ha lavorato per 16 anni sullo sviluppo e l’implementazione di nuovi algoritmi in computer algebra. Diversi anni fa, ha spostato la sua attenzione sui database NoSQL. In ArangoDB, è responsabile di “tutte le cose distribuite”, inclusa la distribuzione su Kubernetes, ma anche resilienza, failover e scalabilità. I suoi interessi particolari includono transazioni distribuite, sistemi distribuiti di auto-guarigione e ottimizzazione delle prestazioni. Se i suoi giorni avevano 48 ore, avrebbe giocato a golf, andare a vela, suonare il pianoforte e inventare un nuovo linguaggio di programmazione.

Tag: ArangoDB, grafico, json, valore chiave, database multi-modello, poliglotta, persistenza poliglotta, relazionale

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.