7 dure verità sulla rivoluzione NoSQL

La parola d'ordine NoSQL ha metastatizzato per diversi anni. L'entusiasmo per questi veloci archivi di dati è stato inebriante e siamo colpevoli come chiunque altro di vedere il fascino rivoluzionario di NoSQL. Eppure la luna di miele sta volgendo al termine ed è ora di iniziare a bilanciare il nostro entusiasmo con alcune dure verità con gli occhi spalancati.

Non fraintenderci. Stiamo ancora correndo per provare l'ultimo esperimento di creazione di un semplice meccanismo per l'archiviazione dei dati. Troviamo ancora un valore profondo in MongoDB, CouchDB, Cassandra, Riak e altri elementi distintivi di NoSQL. Stiamo ancora pianificando di lanciare alcuni dei nostri dati più affidabili in queste pile di codice perché ogni giorno crescono sempre meglio e vengono testati in battaglia.

[Anche su: NoSQL standouts: Nuovi database per nuove applicazioni | Primo sguardo: Oracle NoSQL Database | Ottieni un riassunto delle storie chiave ogni giorno nella newsletter quotidiana. ]

Ma stiamo iniziando a sentire lo sfregamento, poiché i sistemi NoSQL sono tutt'altro che perfetti e spesso si sfregano nel modo sbagliato. Gli sviluppatori più intelligenti lo sapevano fin dall'inizio. Non hanno bruciato i manuali SQL e inviato bruttigrammi alla forza vendita del loro venditore SQL un tempo devoto. No, gli intelligenti sviluppatori NoSQL hanno semplicemente notato che NoSQL sta per "Not Only SQL". Se le masse interpretavano male l'acronimo, quello era il loro problema.

Questo elenco di lamentele, grandi e piccole, è quindi un tentativo di documentare questo fatto e di chiarire l'aria. Ha lo scopo di mettere le cose a posto adesso in modo che possiamo fare un lavoro migliore comprendendo i compromessi e i compromessi.

NoSQL dura verità n. 1: JOIN significa coerenza

Una delle prime lamentele che le persone hanno sui sistemi SQL è il costo computazionale dell'esecuzione di un JOIN tra due tabelle. L'idea è di memorizzare i dati in un unico posto. Se stai tenendo un elenco di clienti, inserisci i loro indirizzi in una tabella e utilizzi i loro ID cliente in ogni altra tabella. Quando si estraggono i dati, il JOIN collega gli ID con gli indirizzi e tutto rimane coerente.

Il problema è che i JOIN possono essere costosi e alcuni DBA hanno inventato comandi JOIN complessi che sbalordiscono la mente, trasformando anche l'hardware più veloce in fango. Non è stata una sorpresa che gli sviluppatori NoSQL abbiano trasformato la loro mancanza di JOIN in una caratteristica: manteniamo l'indirizzo del cliente nella stessa tabella di tutto il resto! Il metodo NoSQL consiste nel memorizzare le coppie chiave-valore per ogni persona. Quando arriva il momento, le recuperi tutte.

Purtroppo, le persone che vogliono che i loro tavoli siano coerenti hanno ancora bisogno di JOIN. Una volta che inizi a memorizzare gli indirizzi dei clienti con tutto il resto, spesso ti ritroverai con più copie di quegli indirizzi in ogni tabella. E quando hai più copie, devi aggiornarle tutte contemporaneamente. A volte funziona, ma quando non lo fa, NoSQL non è pronto ad aiutare con le transazioni.

Aspetta, dici, perché non avere una tabella separata con le informazioni del cliente? In questo modo ci sarà solo un record da modificare. È un'ottima idea, ma ora puoi scrivere tu stesso il JOIN nella tua logica.

NoSQL hard verità n. 2: transazioni complicate

Diciamo che sei OK per vivere senza UNIRE ai tavoli perché vuoi la velocità. È un compromesso accettabile e talvolta i DBA SQL denormalizzano le tabelle proprio per questo motivo.

Il problema è che NoSQL rende difficile mantenere coerenti le varie voci. Spesso non ci sono transazioni per assicurarsi che le modifiche a più tabelle vengano apportate insieme. Per questo, sei da solo e un arresto anomalo potrebbe garantire che le tabelle diventino incoerenti.

Le prime implementazioni NoSQL hanno messo il naso a queste transazioni. Offrivano elenchi di dati coerenti, tranne quando non lo erano. In altre parole, hanno cercato i dati di valore più basso in cui gli errori non avrebbero fatto alcuna differenza sostanziale.

Ora alcune implementazioni NoSQL offrono qualcosa che si avvicina a una transazione. Il prodotto NoSQL di Oracle, ad esempio, offre il controllo transazionale sui dati scritti su un nodo e consente di scegliere una quantità flessibile di coerenza tra più nodi. Se vuoi una coerenza perfetta, devi aspettare che ogni scrittura raggiunga tutti i nodi. Diversi altri archivi dati NoSQL stanno sperimentando l'aggiunta di più struttura e protezione come questa.

NoSQL dura verità n. 3: i database possono essere intelligenti

Molti programmatori NoSQL amano vantarsi di come il loro codice leggero e il loro meccanismo semplice funzionino in modo estremamente rapido. Di solito hanno ragione quando le attività sono semplici come le parti interne di NoSQL, ma ciò cambia quando i problemi diventano più difficili.

Considera la vecchia sfida di un JOIN. Una volta che i programmatori NoSQL iniziano a generare i propri comandi JOIN nella loro logica, iniziano a provare a farlo in modo efficiente. Gli sviluppatori SQL hanno trascorso decenni a sviluppare motori sofisticati per gestire i comandi JOIN nel modo più efficiente possibile. Uno sviluppatore SQL mi ha detto che stava cercando di sincronizzare il suo codice con il disco rigido in rotazione in modo da richiedere i dati solo quando la testa era appena sopra il punto giusto. Questo può sembrare estremo, ma gli sviluppatori SQL hanno lavorato per decenni su hack simili.

Non c'è dubbio che i programmatori passano giorni a strapparsi i capelli cercando di strutturare le loro query SQL per sfruttare tutta questa intelligenza latente. Potrebbe non essere semplice toccare, ma quando il programmatore lo capisce, i database possono davvero cantare.

Un linguaggio di query sofisticato come SQL ha sempre il potenziale per eclissare un linguaggio di query non sofisticato come quelli trovati in NoSQL. Potrebbe non avere importanza con risultati semplici, ma quando l'azione diventa complessa, l'SQL viene eseguito sulla macchina proprio accanto ai dati. Ha un piccolo sovraccarico per recuperare i dati e svolgere il lavoro. Un server NoSQL di solito deve spedire i dati dove stanno andando.

NoSQL dura verità n. 4: troppi modelli di accesso

In teoria, SQL dovrebbe essere un linguaggio standard. Se utilizzi SQL per un database, dovresti essere in grado di eseguire la stessa query in un'altra versione conforme. Questa affermazione può funzionare con alcune semplici query, ma ogni DBA sa che possono essere necessari anni per apprendere le peculiarità di SQL per diverse versioni dello stesso database. Le parole chiave vengono ridefinite e le query che hanno funzionato su una versione non funzioneranno con un'altra.

NoSQL è ancora più arcano. È come la Torre di Babele. Fin dall'inizio, gli sviluppatori NoSQL hanno cercato di immaginare il miglior linguaggio possibile, ma hanno un'immaginazione molto diversa. Questo focolaio di sperimentazione è buono, finché non provi a passare da uno strumento all'altro. Una query per CouchDB viene espressa come una coppia di funzioni JavaScript per la mappatura e la riduzione. Le prime versioni di Cassandra utilizzavano un'API grezza di basso livello chiamata Thrift; le versioni più recenti offrono CQL, un linguaggio di query simile a SQL che deve essere analizzato e compreso dal server. Ognuno è diverso a modo suo.

Ogni strumento non ha solo le proprie idiosincrasie, ma mette in mostra una filosofia e un modo completamente diverso di esprimerlo. Non ci sono modi semplici per passare da un archivio dati all'altro e spesso ti viene lasciato scrivere tonnellate di codice collante solo per darti la possibilità di cambiare in futuro. Questo potrebbe non essere troppo difficile quando stai inserendo coppie di chiavi e valori nel sistema, ma può crescere sempre più aggravando la complessità che introduci.

NoSQL verità n. 5: la flessibilità dello schema è un problema che attende di accadere

Una delle grandi idee del modello NoSQL non è richiedere uno schema. In altre parole, i programmatori non hanno bisogno di decidere in anticipo quali colonne saranno disponibili per ogni riga in una tabella. Una voce può avere 20 stringhe allegate, un'altra può avere 12 numeri interi e un'altra potrebbe essere completamente vuota. I programmatori possono prendere la decisione ogni volta che hanno bisogno di memorizzare qualcosa. Non hanno bisogno di chiedere il permesso al DBA e non hanno bisogno di compilare tutti i documenti per aggiungere una nuova colonna.

Tutta quella libertà suona inebriante e nelle mani giuste può accelerare lo sviluppo. Ma è davvero una buona idea per un database che potrebbe vivere attraverso tre team di sviluppatori? È funzionante anche per un database che potrebbe durare oltre i sei mesi?

In altre parole, gli sviluppatori potrebbero volere la libertà di lanciare qualsiasi vecchia coppia in un database, ma vuoi essere il quinto sviluppatore ad arrivare dopo che quattro hanno scelto le proprie chiavi? È facile immaginare una varietà di rappresentazioni di "compleanno", con ogni sviluppatore che sceglie la propria rappresentazione come chiave quando aggiunge il compleanno di un utente a una voce. Un team di sviluppatori potrebbe immaginare quasi tutto: "bday", "b-day", "birthday".

La struttura NoSQL non offre alcun supporto per limitare questo problema, perché ciò significherebbe reinventare lo schema. Non vuole irritare la dolcezza degli sviluppatori assolutamente fantastici. Uno schema si intrometterebbe.

Il fatto è che l'aggiunta di una colonna a una tabella non è un grosso problema e la disciplina potrebbe effettivamente essere buona per lo sviluppatore. Proprio come aiuta a costringere gli sviluppatori a designare tipi di variabili, aiuta anche a costringere gli sviluppatori a designare il tipo di dati allegati a una colonna. Sì, l'amministratore di database può costringere lo sviluppatore a compilare un modulo in triplice copia prima di allegare quella colonna, ma non è così male come gestire una mezza dozzina di chiavi diverse create al volo da un programmatore.

NoSQL dura verità n. 6: nessun extra

Diciamo che non vuoi tutti i dati in tutte le righe e vuoi la somma di una singola colonna. Gli utenti SQL possono eseguire una query con l'operazione SUM e inviarti un numero, solo uno.

Gli utenti NoSQL ricevono tutti i dati restituiti e possono quindi eseguire da soli l'aggiunta. L'aggiunta non è il problema perché ci vuole circa la stessa quantità di tempo per sommare i numeri su qualsiasi macchina. Tuttavia, la spedizione dei dati è lenta e la larghezza di banda richiesta per inviare tutti quei dati può essere costosa.

Ci sono pochi extra nei database NoSQL. Se vuoi fare altro che archiviare e recuperare i dati, probabilmente lo farai da solo. In molti casi, lo farai su una macchina diversa con una copia completa dei dati. Il vero problema è che spesso può essere utile eseguire tutti i calcoli sulla macchina che contiene i dati perché la spedizione dei dati richiede tempo. Ma difficile per te.

Stanno emergendo soluzioni NoSQL. La struttura di query Mappa e riduci di MongoDB ti offre una struttura JavaScript arbitraria per ridurre i dati. Hadoop è un potente meccanismo per distribuire i calcoli in tutto lo stack di macchine che contiene anche i dati. È una struttura in rapida evoluzione che offre strumenti in rapido miglioramento per la costruzione di analisi sofisticate. È molto bello, ma ancora nuovo. E tecnicamente Hadoop è una parola d'ordine completamente diversa da NoSQL, anche se la distinzione tra loro sta svanendo.

NoSQL verità n. 7: meno strumenti

Certo, puoi far funzionare il tuo stack NoSQL sul tuo server. Certo, puoi scrivere il tuo codice personalizzato per eseguire il push e il pull dei dati dallo stack. Ma cosa succede se vuoi fare di più? E se volessi acquistare uno di quei fantasiosi pacchetti di reportistica? O un pacchetto grafico? O per scaricare alcuni strumenti open source per la creazione di grafici?

Spiacenti, la maggior parte degli strumenti sono scritti per database SQL. Se vuoi generare report, creare grafici o fare qualcosa con tutti i dati nel tuo stack NoSQL, dovrai iniziare a scrivere codice. Gli strumenti standard sono pronti per acquisire dati da Oracle, Microsoft SQL, MySQL e Postgres. I tuoi dati sono in NoSQL? Ci stanno lavorando.

E ci lavoreranno per un po '. Anche se saltano attraverso tutti i cerchi per diventare operativi con uno dei database NoSQL, dovranno ricominciare tutto dall'inizio per gestire il sistema successivo. Esistono più di 20 diverse scelte NoSQL, ognuna delle quali sfoggia la propria filosofia e il proprio modo di lavorare con i dati. Era già abbastanza difficile per i produttori di strumenti supportare le idiosincrasie e le incongruenze in SQL, ma è ancora più complicato far funzionare gli strumenti con ogni approccio NoSQL.

Questo è un problema che lentamente andrà via. Gli sviluppatori possono percepire l'eccitazione in NoSQL e modificheranno i loro strumenti per lavorare con questi sistemi, ma ci vorrà tempo. Forse poi inizieranno su MongoDB, il che non ti aiuterà perché stai eseguendo Cassandra. Gli standard aiutano in situazioni come questa e NoSQL non è grande per gli standard.

I difetti di NoSQL in poche parole

Tutte queste carenze di NoSQL possono essere ridotte a una semplice affermazione: NoSQL elimina le funzionalità per la velocità. Se non hai bisogno della funzionalità, starai bene, ma se ne avrai bisogno in futuro, te ne pentirai.

Le rivoluzioni sono endemiche della cultura tecnologica. Arriva un nuovo gruppo e si chiede perché l'ultima generazione abbia costruito qualcosa di così complesso, e si è proposta di abbattere le vecchie istituzioni. Dopo un po ', iniziano a capire perché tutte le vecchie istituzioni erano così complesse e iniziano a implementare le funzionalità ancora una volta.

Lo stiamo vedendo nel mondo NoSQL, poiché alcuni progetti iniziano ad aggiungere cose che sembrano transazioni, schemi e standard. Questa è la natura del progresso. Smontiamo le cose solo per ricostruirle. NoSQL ha terminato la prima fase della rivoluzione e ora è il momento della seconda. Il re è morto. Lunga vita al Re.

Articoli Correlati

  • Elementi distintivi di NoSQL: nuovi database per nuove applicazioni
  • Primo sguardo: database Oracle NoSQL
  • Flexing NoSQL: MongoDB in revisione
  • 10 suggerimenti essenziali sulle prestazioni per MySQL
  • 10 strumenti MySQL essenziali per gli amministratori
  • Padroneggia MySQL nel cloud Amazon
  • Il momento per gli standard NoSQL è adesso

Questa storia, "7 dure verità sulla rivoluzione NoSQL", è stata originariamente pubblicata su .com. Segui gli ultimi sviluppi nella gestione dei dati su .com. Per gli ultimi sviluppi nelle notizie di tecnologia aziendale, segui .com su Twitter.