Quando l'SQL non basta

I sistemi di gestione dei database relazionali(RBDMS) che utilizzano SQL sono stati utilizzati per archiviare le informazioni delle applicazioni per decenni. Il modello relazionale, che consiste nell'organizzare i dati in tabelle con una chiave identificativa per ogni riga, ha dimostrato di essere affidabile ed efficiente. I moderni database SQL, tra cui MySQL e PostgreSQL rimangono tra i più diffusi database in uso oggi. Ma quando SQL non è sufficiente?

L'ascesa dei database NoSQL(NotOnlySQL) alla fine degli anni 2000 ha coinciso con molti altri progressi. Mentre i processori multicore e la virtualizzazione diventavano comuni, il cloud stava decollando e milioni di utenti in tutto il mondo andavano online per la prima volta con gli smartphone. Tutto aveva bisogno di crescere e il modo più pratico per ottenere questa scala necessaria è il la scalabilità orizzontale. Spesso vediamo che la contrapposizione tra SQL e NoSQL si riduce a "SQL può scalare verticalmente e NoSQL può scalare orizzontalmente", ma questo è incompleto e scorretto.

Scala orizzontale

Quando si parla di scalare orizzontalmente, si intende far crescere l'ambiente aggiungendo altri nodi o macchine. Mentre i database SQL possono scalare verticalmente con relativa facilità aggiungendo più RAM e calcolo a un singolo nodo, distribuire il dataset su più nodi è più impegnativo. Questo può essere fatto con una tecnica chiamata sharding. Quando si lavora con grandi insiemi di dati e un elevato throughput, lo sharding aiuta a ridurre il carico su un singolo server e consente di scalare aggiungendo o rimuovendo server, a seconda delle esigenze.

Sharding e limitazioni di MySQL

I database SQL possono scalare orizzontalmente tramite sharding. Il metodo e le funzionalità supportate variano in modo significativo da un database all'altro, ma è necessario tenere conto di alcune avvertenze. Concentriamoci su uno degli esempi più comuni: MySQL che utilizza il motore di archiviazione NDB. MySQL supporta i cluster NDB che possono dividere una singola tabella di grandi dimensioni in più tabelle più piccole. Il processo di suddivisione di una tabella viene definito partizionamento. Quando vengono archiviate su più server, queste tabelle più piccole costituiscono gli shard. I database del cluster memorizzano ciascuno uno degli shard. Insieme, i database del cluster costituiscono il set di dati completo. 

L'uso dello sharding nei database SQL può offrire un'elevata scalabilità delle dimensioni del set di dati, ma può anche rendere più complessa la logica dell'applicazione. È necessario configurare con attenzione il modo in cui i dati vengono partizionati in più shard, perché questa decisione influisce sulle prestazioni complessive del database. Oltre alla complessità e all'elevato tempo richiesto, ci sono ostacoli tecnici da considerare. Per ovviare a una limitazione comunemente dichiarata, MySQL può essere configurato per eseguire operazioni di join su più shard, ma con un costo per le prestazioni su scale maggiori. Ciò può rendere impraticabili le funzioni analitiche in questi ambienti.

Entrare in NoSQL

Molti tipi diversi di database NoSQL sono esplosi nell'uso dalla loro nascita alla fine degli anni 2000. Per questo esempio, ci concentreremo sul database NoSQL più popolare, MongoDB. MongoDB (che deriva dalla parola "humongous") è orientato ai documenti. I dati sono memorizzati in documenti simili a oggetti JSON e ogni documento contiene coppie di campi e valori. Questo è in contrasto con i database SQL che utilizzano tabelle e righe per formattare i dati. Forse avete letto che i database NoSQL come MongoDB sono in genere più adatti alla scalabilità orizzontale, ma vediamo perché è così.

Si noti che MongoDB utilizza specificamente un formato chiamato BSON, derivato da JSON, ma questo varia a seconda del database.

Schemi e frammenti

MongoDB è senza schema (o schema-free), cioè non richiede una struttura organizzativa definita a livello di database. Lo schema è invece incorporato nel codice a livello di applicazione e questo ci dà molta flessibilità nel cambiare la struttura in seguito, preservando i nostri dati. Pur non avendo la coerenza rigidamente imposta dai database SQL conformi alla normativa ACID, MongoDB e altri database NoSQL eccellono per disponibilità e tolleranza alle partizioni.

Quando abbiamo analizzato la scalabilità orizzontale dei database SQL, abbiamo esaminato il processo di suddivisione di una tabella in frammenti. Pur essendo possibile, questa soluzione comporta una serie di limitazioni dovute alla struttura rigida del database. MongoDB e altri database NoSQL, invece, sono progettati per accogliere lo sharding a livello strutturale. Uno shard è un sottoinsieme di dati e MongoDB ci permette di scalare orizzontalmente distribuendo gli shard come set di repliche. I set di replica sono cluster di almeno tre nodi con copie ridondanti degli stessi dati. Forniscono disponibilità e ridondanza quando sono distribuiti in ambienti di grandi dimensioni e non sono limitati da uno schema predeterminato.

Da ciò si evincono immediatamente le concessioni che i database NoSQL fanno per essere scalabili. I database NoSQL spesso utilizzano una quantità di storage significativamente maggiore rispetto ai database SQL, a causa della quantità di dati ridondanti necessari per ottenere la disponibilità in grandi distribuzioni orizzontali. La velocità di scrittura dei database NoSQL tende a superare quella dei database SQL, ma le query sono più lente. Mancando di una struttura definita, i database NoSQL non sono intrinsecamente conformi ad ACID, il che li rende meno pratici per le applicazioni che gestiscono elevati volumi di transazioni finanziarie. In alternativa, possiamo configurare cluster NoSQL massicci e distribuiti che mantengono inalterate le prestazioni, rendendoli candidati ideali per i Big Data e l'analisi. 

Quando l'SQL non è sufficiente? Come prevedibile, la risposta non è semplice, ma ci sono alcune linee guida generali che possiamo prendere in considerazione quando progettiamo le nostre applicazioni. Cosa deve fare la nostra applicazione e quanto deve essere grande? Da qui possiamo decidere la nostra priorità numero uno. Dire che "SQL scala verticalmente e NoSQL scala orizzontalmente" non è vero, ma possiamo dire che "la maggior parte dei database SQL è stata progettata tenendo conto della coerenza, mentre la maggior parte dei database NoSQL è stata progettata per adattarsi allo scaling".  

Ci saranno sempre dei contrappunti a questa linea guida generale. È possibile scalare MySQL orizzontalmente e MongoDB ha iniziato a supportare le transazioni ACID multi-documento. Più comprendiamo come sono stati progettati questi database, più acquisiamo la capacità di scegliere lo strumento migliore per il nostro lavoro.

Distribuzione dei database su Linode

Per saperne di più sui database gestiti da Linode o iscriversi per ricevere aggiornamenti sul motore di database preferito. È inoltre possibile distribuire sistemi gestiti di database come MongoDB da Linode Marketplace o seguire le nostre guide per installare un database su una varietà di distro Linux, come Installare MongoDB su CentOS 7.