La scelta del database giusto dipende principalmente dalle esigenze dell’applicazione. Ci sono molti fattori da considerare nella scelta del database. In questo articolo, confrontiamo le proprietà ACID, gli attributi CAP e altre funzionalità dei database Cassandra, MongoDB e MySQL per aiutarti a scegliere il database giusto per le tue applicazioni.
Che cos’è ACID?
ACID è l’acronimo di Atomic, Consistent, Isolated, Durable.
ACID indica le proprietà logiche che devono avere le transazioni, una qualunque sequenza di operazioni lecite che, se eseguita in modo corretto, produce una variazione nello stato di una base di dati. Generalmente, la maggior parte dei database relazionali supporta tutte le proprietà ACID. Tuttavia, i database NoSQL hanno vari livelli di supporto per ACID.
Atomic – Atomicità
Ogni transazione è considerata come un’unità indivisibile e viene eseguita fino al completamento o non eseguita affatto. Non sono ammesse esecuzioni parziali. Comprende due operazioni: Abort: se una transazione si interrompe, le modifiche apportate al database non sono visibili; Commit: se una transazione viene confermata, le modifiche apportate sono visibili. Se questa proprietà viene rispettata, allora il database non può rimanere in uno stato intermedio inconsistente. L’atomicità è anche nota come “regola del tutto o niente”.
Per chiarire meglio, consideriamo una transazione T costituito da due operazioni op1 e op2 che rappresenti un trasferimento di 100 € dal conto X all’account Y. L’operazione op1 non fa altro che sottrarre una somma di 100€ dal conto X, mentre l’operazione op2 aggiungere tali 100€ al conto Y. Se l’operazione op1 venisse eseguita, ma non venisse completata l’operazione op2, allora la somma di 100€ verrebbe sottratta dal conto X, ma non verrebbe aggiunta al conto Y. Il database si troverebbe in uno stato incoerente. L’atomicità serve appunto ad evitare questi problemi.
Consistent – Consistenza
Significa che i vincoli di integrità devono essere mantenuti in modo che il database sia coerente prima e dopo la transazione. In questo modo si garantiscono informazioni corrette. Prendendo spunto dall’esempio precedente: il vincolo di integrità delle informazioni è costituito dall’importo totale dei due conti. Se ad esempio il conto X contiene 500€ e il conto Y contiene 300€, qualunque sia l’importo trasferito tra i due conti, il totale deve essere sempre 800€. Nel caso in cui l’operazione op1 oppure op2 fallisca, il database sarà in uno stato incongruente, poichè la somma dei totale dei conti non sarà 800€.
Isolated – Isolamento
Questa proprietà garantisce che possano verificarsi più transazioni contemporaneamente senza causare incoerenze nello stato del database. Le transazioni avvengono in modo indipendente senza interferenze. Le modifiche che si verificano in una determinata transazione non saranno visibili a qualsiasi altra transazione fino a quando quella particolare modifica in quella transazione non viene scritta nella memoria o non è stata impegnata.
Esempio: prendiamo in esame i due conti correnti di cui sopra e consideriamo due transazioni T e T”. Supponiamo adesso che T sia stato eseguito a “metà” cioè che sia stata completata l’operazione op1 ma non la op2. A questo punto T” si avvia. Di conseguenza, ha luogo un interleaving delle operazioni dovuto al fatto che T” legge il valore corretto di X ma il valore errato di Y e la somma calcolata ai fini della verifica dell’integrità delle informazioni da un valore errato.
Durable – Durabilità
Questa proprietà garantisce che, una volta completata la transazione, gli aggiornamenti e le modifiche al database vengano archiviati e scritti sul disco e persistano anche se si verifica un errore del sistema. Questi aggiornamenti diventano permanenti e archiviati nella memoria non volatile. Gli effetti della transazione, quindi, non vengono mai persi.
Caratteristiche ACID dei principali DB
Cassandra e MongoDB sono database NoSQL mentre MySQL è un database SQL.
| Database | Tipo | Atomic | Consistent | Isolated | Durable |
| Cassandra | NoSQL | Atomicità supportata a livello di partizione | Eventuale / Sintonizzabile | Livello di riga | Le scritture sono durevoli |
| MongoDB | NoSQL | Atomicità supportata a livello di documento singolo | Supporto | Regolabile | Supporta più opzioni di durabilità |
| MySQL | SQL | Atomicità delle transazioni supportata del motore InnoDB | InnoDB utilizza una tecnica di flush dei file chiamata doublewrite | Offre diversi livelli di isolamento | Può essere sintonizzato utilizzando parametri configurabili |
Scegliere il DB in base al CAP Theorem
Ne abbiamo già parlato in questo articolo. Il teorema afferma che è impossibile per un sistema distribuito garantire simultaneamente le tre caratteristiche CAP (coerenza, disponibilità e tolleranza della partizione) e deve per forza “scendere” a compromessi.
Alcuni database fanno uno sforzo per supportare tutti e tre, ma continuano a privilegiarne due caratteristiche, ognuno in un certo modo. Ad esempio, Cassandra offre elevata disponibilità e tolleranza alle partizioni e supporta la coerenza in maniera inferiore alle prime due. Se invece stai cercando alta disponibilità e coerenza, allora MySQL potrebbe essere la scelta giusta. MongoDB supporta la tolleranza e la coerenza delle partizioni, ma supporta pure la disponibilità in una certa misura.
Altri attributi rilevanti:
| Proprietà | Cassandra | MongoDB | MySQL |
| Rollback della transazione | No | sì | sì |
| Scritture più veloci | sì | sì | No |
| Meccanismo di bloccaggio | No | sì | sì |
| Join Table | No | No | sì |
| Master Less Architecture | sì | No | No |
L’importante è capire le esigenze della tua applicazione. Quindi, verifica quale database è strettamente corrispondente alle tue esigenze. A volte, potresti non essere in grado di trovare un database completo in grado di supportare tutte le tue esigenze. In tal caso, potresti dover cercare il giusto compromesso per soddisfare le priorità della tua applicazione.
