Utilizzo di un database relazionale vs oggetti JSON per dati evento / attività

Penso che la tua domanda si riduce davvero a: Quando dovrei usare un approccio NoSQL rispetto a RDBMS? Ti sei sistemato su JSON in anticipo (una decisione NoSQL-ish), forse perché hai Ajax consumatori.

La risposta ovviamente a quando utilizzare gli approcci NoSQL rispetto a RDBMS è fondamentalmente sul tipo di dati con cui si sta lavorando e su quali consumatori si prevede di avere. Se i tuoi dati sono essenzialmente relazionali (gerarchie abbastanza piatte, nessun tipo di dati bizzarri come immagini o audio, relazioni prevedibili tra gli schemi che possono essere facilmente descritti nelle chiavi) e i tuoi consumatori sono previsti per includere alla fine le persone che vogliono fare query di Business Intelligence (query ad hoc), quindi un RDBMS è la strada da percorrere. È abbastanza semplice trasformare una query in una rappresentazione JSON, quindi non appesantisce in modo significativo i consumatori Ajax - aggiunge semplicemente una piccola codifica della trasformazione nei tuoi endpoint (REST / SOAP / qualunque). Al contrario , se i tuoi dati sono molto gerarchici (schemi profondi), contengono strani tipi di dati come immagini, audio, video, ecc., ci sono poche relazioni tra entità e sai che i tuoi utenti finali non fare la BI, quindi NoSQL / archiviare JSON può essere appropriato.

Naturalmente, anche queste linee guida generali non sono solide. Il motivo Google ha sviluppato Google File System, MapReduce (lavoro che è stato utilizzato da Doug Cutting per costruire Hadoop su Yahoo) e più tardi BigQuery (un modo NoSQL orientato [schemi] per gestire i dati su larga scala) era precisamente perché loro aveva molte richieste di BI ad hoc e non potevano ottenere che gli approcci relazionali si estendessero fino alle scale tera / peta / exa / zetta / yotta che stavano cercando di gestire. L'unico approccio pratico è stato quello di ridimensionare, sacrificando parte della facilità d'uso della query ad hoc fornita da un RDBMS e sostituendo un semplice algoritmo (MapReduce) che potrebbe essere codificato abbastanza facilmente per qualsiasi query.

Dato il tuo schema sopra, la mia domanda sarebbe fondamentalmente: perché non tu usi un RDBMS? Non vedo molte ragioni per non farlo. La nostra professione dovrebbe essere orientata all'ingegneria, non alla moda, quindi il nostro istinto dovrebbe essere quello di scegliere la soluzione più semplice che funzioni, giusto? Voglio dire, i tuoi endpoint potrebbero dover fare una piccola traduzione se i tuoi utenti sono Ajaxy, ma i tuoi dati sembrano molto piatti e sembra probabile che gli utenti aziendali vorranno fare tutti i tipi di query ad hoc su cose come eventi musicali (Quali l'evento è stato più frequentato entro 50 miglia dalla nostra capitale l'anno scorso?)

'Non rivolgerti agli elfi per un consiglio, perché diranno sia no che sì.' - Frodo

Credo che qui ci siano più considerazioni che potresti non cercare. Ci sono due grandi preoccupazioni qui:

• archiviazione
• Cerca e recupera

archiviazione

Ci sono molte opinioni sul perché utilizzare no-sql o RDBMS per i tuoi dati. Uno degli elementi più importanti che abbiamo ritenuto utile è che possiamo facilmente definire e archiviare oggetti json nello storage senza doverci preoccupare di definire la sua struttura completa o la relazione tra diversi tipi di oggetti. Alcuni degli altri motivi per utilizzare un db NoSql sarebbero la capacità di eseguire il shard automatico dei dati, ricerche basate sulla localizzazione e una facile manutenzione. Ci sono molti buoni database NoSql là fuori, la mia preferenza personale è MongoDB. Tuttavia, se non hai mai usato il database NoSql in precedenza, c'è una curva di apprendimento definita mentre impari a ri-collegare la tua mente. La maggior parte di noi usa RDBMS da un po 'di tempo e ci vuole uno sforzo cosciente per uscire da quell'abitudine. Inoltre, ti ritroverai a voler ripetere il tuo modello di dati mentre procedi con i tuoi sforzi e hai una migliore comprensione dei concetti. Se la capacità di refactoring o di rimodellamento non è un'opzione per il tuo progetto, suggerirei di attenersi a ciò che già conosci meglio.

ricerca

Se intendi fornire qualsiasi tipo di ricerca utilizzabile, ti suggerisco caldamente di utilizzare un motore di ricerca di testo dedicato come SOLR per eseguire le tue ricerche. Le ricerche di testo sono lente e se hai più frammenti, allora anche più lentamente. SOLR supporta ricerche di testo veloci e brillanti, tra cui parametri di ricerca ponderati, ricerche basate sulla posizione e molto altro. SOLR tuttavia non è adatto come archivio primario dei dati. Ciò significa che dovrai creare meccanismi per il doppio inserimento e l'aggiornamento sia al tuo database principale che al tuo livello SOLR quando aggiungi o aggiorni eventi. Inoltre dovrai tenere aggiornato SOLR in seguito rimuovendo eventuali eventi obsoleti / conclusi.

Anche se sembra molto lavoro extra, ti ringrazierai per la lungimiranza di utilizzare un motore di ricerca full-text in seguito. Nessuno dei database NoSql o RDBMS si avvicina alle prestazioni e all'agilità di SOLR / Lucene.

Innanzitutto, se stai provando a Store di dati JSON in qualsiasi spazio di archiviazione, ma non in un database NoSQL , sicuramente ti scoraggeremo dall'utilizzare JSON. Il motivo è che se ad esempio si archiviano i dati come file JSON, sarà estremamente lento aprirlo, analizzarlo, passarlo in loop, ecc.

Detto questo, posso restringere la tua domanda a: Quali sono i pro e i contro di NoSQL e RDBMS ? Ed è stato ho già risposto mille volte sulla 'rete.

Rigenerando il tuo progetto, puoi ovviamente usare NoSQL o RDBMS ; Tuttavia, quello che posso generalmente raccomandarti è di pensare fuori dagli schemi e cercare gli altri fattori meno visibili che potrebbero aiutarti a decidere tra le due opzioni. Prova a vedere quale opzione potrebbe accelerare lo sviluppo? Che è più adatto per gli altri membri del team - se non sei un unico sviluppatore. Se stai vendendo questo, quale è più economico, facile e generalmente più adatto ai tuoi clienti non sviluppatori?

In questo modo puoi finalmente decidere quale strada prendere, altrimenti sarà davvero difficile decidere in base alle informazioni fornite poiché entrambe le opzioni potrebbero andare bene.

Nella maggior parte delle applicazioni ci sono dei requisiti per

1. Immettere dati, eseguire alcune elaborazioni, salvare i dati, recuperare i dati e interrogare i dati. Potrebbe anche esserci un obbligo di generare report sui dati.
2. Scambia dati tra diverse parti del sistema o con sistemi esterni

Per raggiungere i requisiti per l'articolo 1 è necessario un metodo di dati persistenti. In genere, se il volume dei dati è molto piccolo e il tipo di dati è semplice e non richiede funzionalità di ricerca estese, è possibile utilizzare una semplice struttura di file. Man mano che i dati diventano più complessi, è possibile utilizzare una struttura XML (o anche JSON) con i dati ancora archiviati nei file. La ricerca però diventa più problematica. Con l'aumentare del volume di dati e la complessità delle ricerche, viene normalmente selezionato un database che fornisce metodi standard di settore per la persistenza dei dati, le query ecc. I database possono essere progettati per gestire grandi volumi di dati e archiviare, recuperare e ricercare i dati in modo rapido ed efficiente .

Per raggiungere i requisiti per l'Articolo 2 ci sono vari metodi per consentire lo scambio di dati tra sistemi, inclusi XML, JSON ecc.

Questi metodi consentono la definizione della struttura dei dati da parte di un utente e sono indipendenti dalla lingua e consentono a sistemi diversi di scambiare dati.

Nel tuo caso specifico stai usando correttamente JSON sta descrivendo un insieme di eventi musicali. Mentre puoi archiviare i dati in formato JSON cercando questi dati, il numero di eventi musicali crescenti sarà lento e inefficiente.

Utilizzando un approccio di separazione delle preoccupazioni, l'approccio migliore consiste nel raccogliere i dati, archiviarli in un database, eseguire la query in base all'input dell'utente nel database e restituire i risultati in formato JSON sul lato client per visualizzare i dati.

Un ulteriore problema con l'approccio JSON è una struttura di dati mutevole. Attualmente la tua struttura è relativamente semplice. È possibile utilizzare questa struttura per diversi mesi e quindi viene identificato un campo aggiuntivo. Cosa fai allora con tutti i tuoi oggetti JSON esistenti? L'aggiornamento di questi sarebbe problematico.

Se hai usato un database, l'aggiunta di un campo aggiuntivo è relativamente semplice e solo il tuo codice per generare il JSON dovrebbe essere modificato in un unico posto, dandoti così tutto il nuovo JSON con il nuovo campo.

In breve utilizza ogni componente tecnologico per ciò che è stato progettato per JSON per lo scambio di dati e un database per la persistenza dei dati.

Penso che con NoSQL avresti avuto maggiore successo rispetto a SQL per la memorizzazione di questi dati, a causa delle query che devi eseguire.

Anche perché alcuni dati sono puramente relazionali non significa più, deve essere persistito in alcuni RDBMS (SQL). I dati relazionali IMO si tradurrebbero meglio in database di grafici.

Ovviamente puoi anche scrivere le query in SQL ma le prestazioni saranno terribili a causa del numero di join necessari (considerando che i tuoi dati saranno in qualche modo normalizzati e non tutti in una sola tabella degli eventi).

Ma in conclusione avrai più libertà usando NoSQL (quindi JSON o qualche altro formato supportato dal database) considerando che puoi modificare lo schema in futuro senza tenere conto dei dati già persistenti.

Considerando NoSQL puoi anche cercare nei database di grafi se prevedi di usare query molto complesse, dato che ti daranno dei vantaggi nel crearli facilmente, e anche eseguirli molto velocemente.

Penso che dovresti usare entrambi e non lo vedo come una decisione "contro".

Un database relazionale ha senso per l'archiviazione e il recupero rapido ed efficiente di dati con proprietà relazionali.

JSON è un formato di dati eccezionale perché è semplice, leggero e ideale per passare i dati grezzi in un formato molto semplice con una sintassi adatta per archiviare e scambiare informazioni di testo. È ottimo per trasmettere piccole quantità di dati tra un browser e un server. Non è in un formato così semplice da utilizzare per le query sui dati di tipo relazionale.

Quindi consiglierei SQL per l'archiviazione dei dati e JSON per il formato di trasporto dei dati.

È vero che non ci sono opzioni valore-chiave noSq come Mongo, Redis, ecc. Avrebbero il vantaggio di una mappatura forse più semplice al formato JSON, ma sono generalmente un po 'più difficili da usare per le query. L'ostacolo principale con loro è poco conosciuto dalla comunità IT generale, soprattutto se confrontato con SQL che è così noto e ha una vasta gamma di risorse e conoscenze disponibili per quasi tutte le situazioni immaginabili.