Oltre NoSQL: il caso di SQL distribuito

All'inizio c'erano dei file. Successivamente c'erano database di navigazione basati su file strutturati. Poi c'erano IMS e CODASYL e circa 40 anni fa avevamo alcuni dei primi database relazionali. Per gran parte degli anni '80 e '90 "database" significava strettamente "database relazionale". Governato SQL. 

Poi, con la crescente popolarità dei linguaggi di programmazione orientati agli oggetti, alcuni pensavano che la soluzione al "disadattamento di impedenza" dei linguaggi orientati agli oggetti e dei database relazionali fosse mappare gli oggetti nel database. Così siamo finiti con "database orientati agli oggetti". La cosa divertente dei database a oggetti era che in molti casi erano fondamentalmente un database normale con un mappatore di oggetti incorporato. Questi sono diminuiti in popolarità e il prossimo vero tentativo di mercato di massa è stato "NoSQL" negli anni 2010.

L'attacco a SQL

NoSQL ha attaccato sia i database relazionali che SQL nello stesso modo. Il problema principale questa volta era che Internet aveva distrutto la premessa sottostante dell'architettura del sistema di gestione del database relazionale (RDBMS) di 40 anni. Questi database sono stati progettati per conservare prezioso spazio su disco e scalare verticalmente. Adesso c'erano troppi utenti e troppi da gestire per un server grasso. I database NoSQL affermavano che se avessi un database senza join, nessun linguaggio di query standard (perché l'implementazione di SQL richiede tempo) e nessuna integrità dei dati, potresti ridimensionare orizzontalmente e gestire quel volume. Ciò ha risolto il problema della scala verticale ma ha introdotto nuovi problemi.

Parallelamente a questi sistemi di elaborazione delle transazioni online (OLTP) è stato sviluppato un altro tipo di database principalmente relazionale chiamato sistema di elaborazione analitica online (OLAP). Questi database supportavano la struttura relazionale ma eseguivano query con la consapevolezza che avrebbero restituito enormi quantità di dati. Le aziende negli anni '80 e '90 erano ancora in gran parte guidate dall'elaborazione in batch. Inoltre, i sistemi OLAP hanno sviluppato la capacità per sviluppatori e analisti di immaginare e archiviare i dati come cubi n-dimensionali. Se immagini un array bidimensionale e ricerche basate su due indici in modo da essere fondamentalmente efficienti come il tempo costante, ma poi prendi quello e aggiungi un'altra dimensione o un'altra in modo da poter fare ciò che sono essenzialmente ricerche di tre o più fattori (diciamo domanda e offerta,e il numero di concorrenti): potresti analizzare e prevedere le cose in modo più efficiente. La costruzione di questi, tuttavia, è laboriosa e uno sforzo molto orientato ai lotti.

Più o meno nello stesso periodo in cui NoSQL è scalabile, sono emersi database a grafo. Molte cose non sono "relazionali" di per sé, o non si basano sulla teoria degli insiemi e sull'algebra relazionale, ma invece sulle relazioni genitore-figlio o amico di un amico. Un classico esempio è da linea di prodotto a marca di prodotto da modellare a componenti nel modello. Se vuoi sapere "quale scheda madre è nel mio laptop", scopri che i produttori hanno un approvvigionamento complicato e il marchio o il numero di modello potrebbero non essere sufficienti. Se vuoi sapere quali sono le schede madri utilizzate in una linea di prodotti, in SQL classico (non CTE o Common Table Expression) devi seguire le tabelle ed eseguire query in più passaggi. Inizialmente, la maggior parte dei database a grafo non si frammentava affatto. In verità, molti tipi di analisi del grafico possono essere eseguiti senza effettivamente memorizzare i dati come un grafico.

NoSQL promette mantenute e promesse non mantenute

I database NoSQL hanno scalato molto, molto meglio di Oracle Database, DB2 o SQL Server, che sono tutti basati su un design vecchio di 40 anni. Tuttavia, ogni tipo di database NoSQL aveva nuove restrizioni:

  • Archivi chiave-valore: non esiste una ricerca più semplice di db.get (chiave). Tuttavia, gran parte dei dati e dei casi d'uso del mondo non possono essere strutturati in questo modo. Inoltre, stiamo davvero parlando di una strategia di memorizzazione nella cache. Le ricerche di chiavi primarie sono veloci in qualsiasi database; è semplicemente ciò che è nella memoria che conta. Nel migliore dei casi, questi si ridimensionano come una mappa hash. Tuttavia, se devi fare 30 viaggi nel database per rimettere insieme i tuoi dati o eseguire qualsiasi tipo di query complicata, questo non funzionerà. Questi sono ora più frequentemente implementati come cache davanti ad altri database. (Esempio: Redis.)
  • Database di documenti: hanno raggiunto la loro popolarità perché usano JSON e gli oggetti sono facili da serializzare in JSON. Le prime versioni di questi database non avevano collegamenti e l'inserimento dell'intera "entità" in un unico gigantesco documento aveva i suoi inconvenienti. Senza garanzie transazionali, hai anche avuto problemi di integrità dei dati. Oggi, alcuni database di documenti supportano una forma di transazione meno robusta, ma non è lo stesso livello di garanzia a cui la maggior parte delle persone è abituata. Inoltre, anche per query semplici, queste sono spesso lente in termini di latenza, anche se scalano meglio in termini di tutto. (Esempi: MongoDB, Amazon DocumentDB.)
  • Archivi di colonne: sono veloci quanto gli archivi di valori-chiave per le ricerche e possono memorizzare strutture di dati più complicate. Tuttavia, fare qualcosa che assomiglia a un join tra tre tabelle (nel gergo RDBMS) o tre raccolte (nel gergo MongoDB) è doloroso nella migliore delle ipotesi. Questi sono davvero ottimi per i dati delle serie temporali (dammi tutto quello che è successo tra le 13:00 e le 14:00).

E ci sono altri database NoSQL più esoterici. Tuttavia, ciò che tutti questi database avevano in comune è la mancanza di supporto per gli idiomi comuni dei database e la tendenza a concentrarsi su uno "scopo speciale". Alcuni popolari database NoSQL (ad esempio MongoDB) hanno scritto ottimi front-end per database e strumenti per ecosistemi che hanno reso davvero facile l'adozione per gli sviluppatori, ma hanno progettato gravi limitazioni nel loro motore di archiviazione, per non parlare dei limiti di resilienza e scalabilità.

Gli standard dei database sono ancora importanti

Una delle cose che rendevano i database relazionali dominanti era che avevano un ecosistema comune di strumenti. In primo luogo, c'era SQL. Sebbene i dialetti potessero essere diversi - come sviluppatore o analista se sei passato da SQL Server 6.5 a Oracle 7, potresti dover correggere le tue query e utilizzare "(+)" per i join esterni - ma le cose semplici funzionavano e le cose difficili erano ragionevolmente facili tradurre.

In secondo luogo, avevi ODBC e, successivamente, JDBC, tra gli altri. Quasi qualsiasi strumento in grado di connettersi a un RDBMS (a meno che non sia stato creato appositamente per gestire tale RDBMS) potrebbe connettersi a qualsiasi altro RDBMS. Ci sono molte persone che si connettono quotidianamente a un RDBMS e succhiano i dati in Excel per analizzarli. Non mi riferisco a Tableau o ad altre centinaia di altri strumenti; Sto parlando della "nave madre", Excel.

NoSQL ha eliminato gli standard. MongoDB non utilizza SQL come lingua principale. Quando il concorrente più vicino di MongoDB, Couchbase, stava cercando un linguaggio di query per sostituire il loro framework mapreduce basato su Java, ha creato il proprio dialetto SQL.

Gli standard sono importanti sia per supportare l'ecosistema degli strumenti, sia perché molte persone che interrogano i database non sono sviluppatori e conoscono SQL.

GraphQL e l'ascesa della gestione statale

Sai chi ha due pollici e vuole solo che lo stato della sua app si faccia strada nel database e non gli importa come? Questo ragazzo. E si scopre un'intera generazione di sviluppatori. GraphQL, che non ha nulla a che fare con i database a grafo, memorizza il tuo oggetto grafico in un archivio dati sottostante. Libera lo sviluppatore dalla preoccupazione di questo problema.

Un precedente tentativo in questo senso erano strumenti di mappatura relazionale a oggetti, o ORM, come Hibernate. Hanno preso un oggetto e fondamentalmente lo hanno trasformato in SQL sulla base di una configurazione di mappatura oggetto-tabella. Molte delle prime generazioni di questo erano difficili da configurare. Inoltre, eravamo su una curva di apprendimento.

La maggior parte delle implementazioni di GraphQL funziona con strumenti di mappatura relazionale a oggetti come Sequelize o TypeORM. Invece di far trapelare la preoccupazione di gestione dello stato in tutto il codice, un'implementazione GraphQL ben strutturata e un'API scriveranno e restituiranno i dati rilevanti man mano che vengono apportate modifiche al grafico a oggetti. Chi, a livello di applicazione, si preoccupa davvero di come vengono archiviati i dati?

Una delle basi dei database orientati agli oggetti e NoSQL era che lo sviluppatore dell'applicazione doveva essere consapevole delle complessità di come i dati vengono archiviati nel database. Naturalmente questo era difficile da padroneggiare per gli sviluppatori con le nuove tecnologie, ma non lo è più. Perché GraphQL elimina del tutto questa preoccupazione.

Immettere NewSQL o SQL distribuito

Google ha avuto un problema con il database e ha scritto un documento e successivamente un'implementazione chiamata "Spanner", che descriveva come avrebbe funzionato un database relazionale distribuito a livello globale. Spanner ha innescato una nuova ondata di innovazione nella tecnologia dei database relazionali. Potresti effettivamente avere un database relazionale e farlo scalare non solo con i frammenti ma in tutto il mondo, se necessario. E stiamo parlando di scala nel senso moderno, non nel modo spesso deludente e complicato RAC / Streams / GoldenGate.

Quindi la premessa di "immagazzinare oggetti" in un sistema relazionale era sbagliata. E se il problema principale con i database relazionali fosse il back-end e non il front-end? Questa è l'idea alla base dei cosiddetti database "NewSQL" o più propriamente "SQL distribuiti". L'idea è di combinare gli insegnamenti sull'archiviazione NoSQL e l'idea di Spanner di Google con un front-end RDBMS maturo e open source come PostgreSQL o MySQL / MariaDB.

Cosa significa? Significa che puoi avere la tua torta e mangiarla anche tu. Significa che puoi avere più nodi e scalare orizzontalmente, anche attraverso le zone di disponibilità del cloud. Significa che puoi avere più data center o aree geografiche cloud - con un database. Significa che puoi avere una vera affidabilità, un cluster di database che non si ferma mai per quanto riguarda gli utenti.

Nel frattempo, l'intero ecosistema SQL funziona ancora! Puoi farlo senza ricostruire l'intera infrastruttura IT. Anche se potresti non essere un gioco per "copiare e sostituire" il tuo RDBMS tradizionale, la maggior parte delle aziende non sta cercando di utilizzare più Oracle. E soprattutto, puoi ancora utilizzare SQL e tutti i tuoi strumenti sia nel cloud che in tutto il mondo.