Come scegliere il database giusto per la tua applicazione

La scelta del database "giusto" può spesso essere fondamentale per il successo di un'applicazione. Piuttosto che seguire i consigli dei fornitori o utilizzare un database perché già lo possiedi, è utile considerare lo scopo ei requisiti fondamentali dell'archivio dati.

Queste sono le domande più importanti da porre quando scegli un database:

  • Quanti dati prevedi di archiviare quando l'applicazione è matura?
  • Quanti utenti prevedi di gestire contemporaneamente al picco di carico?
  • Di quali disponibilità, scalabilità, latenza, velocità effettiva e coerenza dei dati ha bisogno la tua applicazione?
  • Con che frequenza cambieranno gli schemi del database?
  • Qual è la distribuzione geografica della tua popolazione di utenti?
  • Qual è la "forma" naturale dei tuoi dati?
  • La tua applicazione richiede l'elaborazione delle transazioni online (OLTP), le query analitiche (OLAP) o entrambe?
  • Che rapporto tra letture e scritture ti aspetti dalla produzione?
  • Hai bisogno di query geografiche e / o query full-text?
  • Quali sono i tuoi linguaggi di programmazione preferiti?
  • Hai un budget? In caso affermativo, coprirà licenze e contratti di supporto?
  • Esistono restrizioni legali sulla memorizzazione dei dati?

Espandiamo queste domande e le loro implicazioni.

Quanti dati memorizzerai?

Se la tua stima è in gigabyte o meno, quasi tutti i database gestiranno i tuoi dati e i database in memoria sono completamente fattibili. Esistono ancora molte opzioni di database per gestire i dati nell'intervallo di terabyte (migliaia di gigabyte).

Se la tua risposta è in petabyte (milioni di gigabyte) o più, solo pochi database ti serviranno bene e devi essere preparato per costi di archiviazione dei dati significativi, sia in spese in conto capitale per l'archiviazione in loco che in spese operative per archiviazione cloud. A quella scala potresti volere uno storage a livelli in modo che le query sui dati "live" possano essere eseguite in memoria o su SSD locali per la velocità, mentre l'intero set di dati risiede su dischi rotanti per motivi economici.

Quanti utenti simultanei?

La stima del carico di molti utenti simultanei viene spesso considerata come un esercizio di dimensionamento del server da eseguire appena prima di installare il database di produzione. Sfortunatamente, molti database non sono in grado di gestire migliaia di utenti che eseguono query in terabyte o petabyte di dati, a causa di problemi di ridimensionamento.

La stima degli utenti simultanei è molto più semplice per un database utilizzato dai dipendenti che per un database pubblico. Per quest'ultimo, potrebbe essere necessario avere la possibilità di eseguire la scalabilità orizzontale su più server per caricamenti imprevisti o stagionali. Sfortunatamente, non tutti i database supportano il ridimensionamento orizzontale senza il dispendioso partizionamento orizzontale manuale delle tabelle di grandi dimensioni.

Quali sono i tuoi requisiti di "abilità"?

In questa categoria includo disponibilità, scalabilità, latenza, velocità effettiva e coerenza dei dati, anche se non tutti i termini terminano con "-ility".

La disponibilità è spesso un criterio chiave per i database transazionali. Sebbene non tutte le applicazioni debbano essere eseguite 24 ore su 24, 7 giorni su 7 con una disponibilità del 99,999%, alcune lo fanno. Alcuni database cloud offrono una disponibilità "cinque nove", a condizione che vengano eseguiti in più zone di disponibilità. I database locali possono in genere essere configurati per la disponibilità elevata al di fuori dei periodi di manutenzione pianificata, soprattutto se ci si può permettere di configurare una coppia di server attivo-attivo.

La scalabilità, in particolare la scalabilità orizzontale, è stata storicamente migliore per i database NoSQL rispetto ai database SQL, ma diversi database SQL stanno recuperando terreno. La scalabilità dinamica è molto più facile da realizzare nel cloud. I database con una buona scalabilità possono gestire molti utenti simultanei aumentando o riducendo la velocità fino a quando la velocità effettiva non è sufficiente per il carico.

La latenza si riferisce sia al tempo di risposta del database che al tempo di risposta end-to-end dell'applicazione. Idealmente ogni azione dell'utente avrà un tempo di risposta inferiore al secondo; questo spesso si traduce nella necessità che il database risponda in meno di 100 millisecondi per ogni semplice transazione. Le query analitiche possono spesso richiedere secondi o minuti. Le applicazioni possono preservare il tempo di risposta eseguendo query complicate in background.

La velocità effettiva per un database OLTP viene generalmente misurata in transazioni al secondo. I database con velocità effettiva elevata possono supportare molti utenti simultanei.

La coerenza dei dati è generalmente "forte" per i database SQL, il che significa che tutte le letture restituiscono i dati più recenti. La coerenza dei dati può variare da "finale" a "forte" per i database NoSQL. La coerenza finale offre una latenza inferiore, a rischio di leggere dati non aggiornati.

La coerenza è la "C" nelle proprietà ACID richieste per la validità in caso di errori, partizioni di rete e interruzioni di corrente. Le quattro proprietà ACID sono Atomicità, Consistenza, Isolamento e Durata.

I tuoi schemi di database sono stabili?

Se è improbabile che gli schemi del database cambino in modo significativo nel tempo e desideri che la maggior parte dei campi abbia tipi coerenti da record a record, i database SQL sarebbero una buona scelta per te. Altrimenti, i database NoSQL, alcuni dei quali non supportano nemmeno gli schemi, potrebbero essere migliori per la tua applicazione. Esistono tuttavia delle eccezioni. Ad esempio, Rockset consente query SQL senza imporre uno schema fisso o tipi coerenti sui dati che importa.

Distribuzione geografica degli utenti

Quando gli utenti del database si trovano in tutto il mondo, la velocità della luce impone un limite inferiore alla latenza del database per gli utenti remoti a meno che non si forniscano server aggiuntivi nelle loro regioni. Alcuni database consentono server di lettura / scrittura distribuiti; altri offrono server di sola lettura distribuiti, con tutte le scritture obbligate a passare attraverso un unico server master. La distribuzione geografica rende ancora più difficile il compromesso tra coerenza e latenza.

La maggior parte dei database che supportano nodi distribuiti a livello globale e una forte coerenza utilizzano gruppi di consenso per accelerare le scritture senza compromettere seriamente la coerenza, in genere utilizzando gli algoritmi Paxos (Lamport, 1990) o Raft (Ongaro e Ousterhout, 2013). I database NoSQL distribuiti che alla fine sono coerenti utilizzano in genere la replica peer-to-peer senza consenso, che può portare a conflitti quando due repliche ricevono scritture simultanee sullo stesso record, conflitti che di solito vengono risolti euristicamente.

Forma dei dati

I database SQL archiviano in modo classico dati fortemente tipizzati in tabelle rettangolari con righe e colonne. Si basano su relazioni definite tra tabelle, utilizzano indici per velocizzare le query selezionate e utilizzano JOINS per interrogare più tabelle contemporaneamente. I database dei documenti in genere memorizzano JSON di tipo debole che può includere array e documenti nidificati. I database di grafici memorizzano vertici e bordi, o triple o quadruple. Altre categorie di database NoSQL includono archivi di valori-chiave e colonne.

A volte i dati vengono generati in una forma che funzionerà anche per l'analisi; a volte non lo è e sarà necessaria una trasformazione. A volte un tipo di database è costruito su un altro. Ad esempio, gli archivi di valori-chiave possono essere alla base di quasi tutti i tipi di database.

OLTP, OLAP o HTAP?

Per decodificare gli acronimi sopra, la domanda è se la tua applicazione necessita di un database per transazioni, analisi o entrambi. La necessità di transazioni veloci implica una velocità di scrittura veloce e indici minimi. La necessità di analisi implica un'elevata velocità di lettura e molti indici. I sistemi ibridi utilizzano vari trucchi per supportare entrambi i requisiti, inclusa la disponibilità di un archivio transazionale primario che alimenta un archivio di analisi secondario tramite la replica.

Rapporto lettura / scrittura

Alcuni database sono più veloci nelle letture e nelle query e altri sono più veloci nelle scritture. Il mix di letture e scritture che ti aspetti dalla tua applicazione è un numero utile da includere nei criteri di selezione del database e può guidare i tuoi sforzi di benchmarking. La scelta ottimale del tipo di indice differisce tra applicazioni pesanti in lettura (di solito un albero B) e applicazioni pesanti in scrittura (spesso un albero merge strutturato in log, noto anche come albero LSM).

Indici e query geospaziali

Se si dispone di dati geografici o geometrici e si desidera eseguire query efficienti per trovare oggetti all'interno di un confine o oggetti entro una determinata distanza da una posizione, sono necessari indici diversi da quelli che si farebbero per i dati relazionali tipici. Un R-tree è spesso la scelta preferita per gli indici geospaziali, ma ci sono più di una dozzina di altre possibili strutture dati di indice geospaziale. Ci sono un paio di dozzine di database che supportano i dati spaziali; la maggior parte supporta alcuni o tutti gli standard Open Geospatial Consortium.

Indici e query full-text

Allo stesso modo, una ricerca full-text efficiente dei campi di testo richiede indici diversi rispetto ai dati relazionali o geospaziali. In genere, crei un indice di elenco invertito di parole tokenizzate e lo cerchi per evitare di eseguire una costosa scansione della tabella.

Linguaggi di programmazione preferiti

Sebbene la maggior parte dei database supporti le API per molti linguaggi di programmazione, il linguaggio di programmazione preferito nell'applicazione a volte può influenzare la scelta del database. Ad esempio, JSON è il formato dati naturale per JavaScript, quindi potresti scegliere un database che supporti il ​​tipo di dati JSON per un'applicazione JavaScript. Quando utilizzi un linguaggio di programmazione fortemente tipizzato, potresti voler scegliere un database fortemente tipizzato.

Vincoli di bilancio

I prezzi dei database variano da gratuiti a molto costosi. Molti database hanno sia versioni gratuite che a pagamento e talvolta hanno più di un livello di offerta a pagamento, ad esempio offrendo una versione Enterprise e diversi tempi di risposta del servizio. Inoltre, alcuni database sono disponibili nel cloud a condizioni di pagamento in base al consumo.

Se scegli un database gratuito e open source, potresti dover rinunciare al supporto del fornitore. Finché hai competenze interne, potrebbe andare bene. D'altra parte, potrebbe essere più produttivo per i tuoi dipendenti concentrarsi sull'applicazione e lasciare l'amministrazione e la manutenzione del database a fornitori o provider di cloud.

Restrizioni legali

Esistono molte leggi sulla sicurezza dei dati e sulla privacy. Nell'UE, il GDPR ha implicazioni di ampio respiro per la privacy, la protezione dei dati e l'ubicazione dei dati. Negli Stati Uniti, HIPAA regola le informazioni mediche e GLBA regola il modo in cui le istituzioni finanziarie gestiscono le informazioni private dei clienti. In California, il nuovo CCPA migliora i diritti alla privacy e la protezione dei consumatori.

Alcuni database sono in grado di gestire i dati in modo conforme ad alcune o tutte queste normative, purché si seguano le migliori pratiche. Altri database hanno difetti che rendono molto difficile utilizzarli per informazioni di identificazione personale, indipendentemente da quanto tu sia attento.

Onestamente, quello era un lungo elenco di fattori da considerare quando si sceglie un database, probabilmente più di quanto si preferirebbe considerare. Tuttavia, vale la pena provare a rispondere a tutte le domande al meglio delle capacità del tuo team prima di rischiare di affidare il tuo progetto a quello che risulta essere un database inadeguato o eccessivamente costoso.