NoSQL o MySQL? [chiuso]

Non è un problema avere i dati "non coerenti su tutte le righe" in un database relazionale. Questo è esattamente ciò per cui sono progettati i database relazionali! Si crea una tabella per i dati che è comune a tutte le attività e quindi si creano tabelle separate per dati specifici per tipo di attività. Per esempio. un tavolo da calcio con una colonna punteggio, un tavolo da ciclismo con una colonna della distanza, entrambi collegati alla tabella delle attività con chiavi esterne.

Quindi sono scettico sul fatto che "non tutti i dati possono essere organizzati in un tradizionale database basato su righe / colonne". Puoi sempre farlo, a meno che tu non abbia dati molto particolari. Ci sono alcuni casi in cui potrebbe essere sconveniente (ad esempio, hai alcuni dati strutturati specifici dell'applicazione che non hai mai bisogno di interrogare o aggiornare - potrebbe essere più semplice semplicemente serializzare in un singolo campo), ma questo dipende dai tuoi particolari casi d'uso.

Nella tua domanda non c'è nulla che indichi perché un database relazionale non andrebbe bene.

Dai un'occhiata a PostgreSQL. Puoi memorizzare JSON in esso in un modo sicuro dal tipo. Supporta l'indicizzazione così puoi combinare i dati relazionali con i documenti JSON abbastanza bene . È anche veloce, ci sono molti benchmark.

Inoltre, se non hai mai usato NoSQL prima, leggi questo: Perché non dovresti mai usare MongoDB (non preoccuparti del titolo, l'articolo è piuttosto costruttivo)

Per quanto riguarda MySQL, non suggerirei al mio peggior nemico di usarlo. Ha così tanti bug che non è nemmeno divertente. Funziona più o meno in un cluster (a causa di bug alcune funzionalità diventano inutilizzabili e ci sono 1001 "soluzioni alternative" che lo rendono irraggiungibile), per prima cosa, quindi non è una soluzione scalabile.

Quindi, scegli tra PostgreSQL e NoSQL almeno. Sicuramente consiglierei PostgreSQL.

Modifica

Ho deciso di menzionare alcuni dei bug di MySQL che mi è capitato di affrontare per chiarire che non si tratta solo di incitamento all'odio:

• Supporto XA incompleto ( "Per XA START, il Le clausole JOIN e RESUME non sono supportate. Per XA END la clausola SUSPEND [FOR MIGRATE] non è supportata. ") + bug nel driver Java ufficiale ( questo bug potrebbe essere in MySQL stesso, non sono sicuro) causa (NUM_CORES * 100)% carico della CPU sul server DB, nel qual caso è necessario riavviarlo.

  Soluzione temporanea: unione di tutti i database che partecipano alle transazioni distribuite in uno o non utilizzando transazioni distribuite . Ho partecipato alla fusione di solo 2 DB, ed è stato brutale.

• Deadlock su inserimenti simultanei . Succede quando inserisci 4 valori in 2 transazioni, 2 ciascuno, in 2 spazi vuoti in un campo indicizzato.

  Soluzione temporanea: serializzazione degli inserti . Significa che praticamente puoi inserire solo con un thread, quindi nessuna scalabilità per la tua applicazione.

• Trigger e replicazione non vanno insieme. Ci sono alcuni bug, come il Bug # 45677 relativo a AUTO_INCREMENT

  Soluzione: non utilizzare i trigger o non utilizzare la replica . Ci sono soluzioni alternative meno brutali per ogni bug, ma alla fine della giornata è proprio quello che ho detto: scegli i trigger o la replica, non entrambi.

Questi non sono nemmeno la metà della mia lista, ma voglio sottolineare che MySQL è brutto quando hai bisogno di più di un singolo database senza replica. Ed è particolarmente importante in quanto la scalabilità è uno degli argomenti più forti per l'utilizzo di soluzioni NoSQL e hai menzionato che potresti avere molti dati.