NoSQL: che cosa sono i dati non strutturati?

stiamo attualmente lavorando al limite delle risorse con la nostra soluzione basata su server mssql.

Ora abbiamo molte opzioni tradizionali per quanto riguarda la prossima mossa per affrontare il carico:

• acquistare CPU e IO più veloci
• dividere alcuni clienti in un server separato
• sposta db nel cluster

Tutti sono costosi in termini di licenze e hardware o tempo. Quindi, voglio aggiungere un'altra opzione spostando l'intero sistema in una soluzione scalabile che promette cassandra nosql engine.

Tuttavia, non sono sicuro e non ho esperienza con i database noSQL, quindi ho bisogno di capire la struttura dei dati "non strutturati".

Nella nostra applicazione, in sostanza archiviamo i dati inseriti dagli utenti in vari modi come elenchi di "valori-chiave". C'è una tabella padre, che contiene l'elemento head (come un Ordine) e c'è una tabella figlio con le coppie chiave-valore che comprendono il contenuto dell'ordine (come Order_Lines).

Per quanto riguarda il business, Order e OrderLines sono un'unità. Ma a causa dell'RDBMS, sono memorizzati in tabelle e devono essere uniti continuamente.

Durante le operazioni, a volte scegliamo di caricare solo la parte superiore, ma la maggior parte delle volte cariciamo la riga principale + alcuni KVP per visualizzare alcune informazioni utili.

Ad esempio, in un elenco di riepilogo, mostriamo l'identificatore head + alcuni valori in nelle colonne per ogni riga.

AGGIORNAMENTO: memorizziamo forme di qualsiasi tipo. Quindi, in sostanza archiviamo "documenti". Tuttavia, dobbiamo preparare e cercare questi moduli in base a qualsiasi valore, ordinamento, ecc. Il controllo dell'accesso ai dati aggiunge un altro livello di complicità al database.

Come puoi immaginare, la quantità e la disponibilità di alcuni KVP variano da oggetto a oggetto. Non esiste una possibilità valida per creare singole tabelle per ogni tipo di oggetto poiché dovremmo creare migliaia di tabelle per le diverse combinazioni di dati.

Questo tipo di "dizionario" come i set di dati sarebbe meglio archiviato in un database noSQL? E avremo benefici prestazionali da questo? Cassandra modellerebbe questi head + KVP come un unico set di dati? Guardando la pagina Web Cassandra e alcuni tutorial, ho l'impressione che non ci sia molta differenza tra il nostro RDBMS e Cassandra in termini di organizzazione dei dati - lasciandoci con la stessa enorme quantità di join se si desidera selezionare 5 KVP per un elenco per ogni riga.

L'illuminazione è benvenuta, anche i riferimenti ai documenti che spiegano i problemi sono ok.

Ci sono un paio di concetti che devono essere distinti. Uno riguarda la struttura e l'altro lo schema.

I dati strutturati sono quelli in cui l'applicazione conosce in anticipo il significato di ogni byte che riceve. Un buon esempio sono le misurazioni da un sensore. Al contrario, uno stream di Twitter non è strutturato. Lo schema riguarda la quantità di struttura comunicata al DBMS e il modo in cui viene richiesto di imporlo. Controlla quanto il DBMS analizza i dati archiviati. Un DBMS richiesto dallo schema come SQL Server può archiviare dati non analizzati (varbinary) o dati facoltativamente analizzati (xml) e dati completamente analizzati (colonne).

I DBMS NoSQL si trovano su uno spettro senza analisi (archivi di valori-chiave) verso l'alto. Cassandra offre funzionalità riccamente ricche in questo senso. Il punto in cui differiscono notevolmente dai negozi relazionali è nell'uniformità dei dati. Una volta definita una tabella, possono essere conservati solo i dati che corrispondono a tale definizione. In Cassandra, tuttavia, anche se sono definite colonne e famiglie, non è necessario che due righe nella stessa tabella siano simili tra loro. Spetta al progettista dell'applicazione decidere quanto va in una singola riga (indicato anche come documento) e cosa viene tenuto separatamente, collegato da puntatori. In effetti, quanta denormalizzazione vuoi.

Il vantaggio è che puoi recuperare un set completo di dati con una singola lettura sequenziale. Questo è veloce Un aspetto negativo è che tu, il programmatore dell'applicazione, ora sei il solo responsabile di tutti i problemi di integrità dei dati e di compatibilità con le versioni precedenti, per sempre, per ogni bit di codice che tocchi mai questo archivio di dati. Questo può essere difficile da ottenere. Inoltre, sei bloccato in un punto di vista sui dati. Se si digitano le righe per numero di ordine, come si fa a riferire sulla vendita di un particolare prodotto, regione o cliente?

Nonostante il mainstream dei database noSQL IMHO, la decisione sull'adozione di tale tecnologia dovrebbe essere presa in base ai risultati necessari in base alle informazioni memorizzate, non solo per partecipare alle prestazioni attualmente in corso. Ciò significa che forse l'opzione migliore è attenersi al database SQL e migliorare il proprio hardware.

Ma ho anche letto qualcosa nella tua domanda che mi ha fatto riflettere. Non c'è molto sullo stato attuale del tuo database ma la tua frase "fondamentalmente memorizziamo i dati inseriti dagli utenti in vari modi come elenchi di" valori-chiave "" mi fa pensare se il problema non sarebbe un modello di dati scadente piuttosto che la mancanza di risorse fisiche. Ho gestito tabelle molto grandi (+10 miliardi di righe) con prestazioni incredibili nei database SQL "tradizionali".

Non sto dicendo che è sbagliato, solo, dal momento che ovviamente non posso valutarti nel modello di dati giusto con così poche informazioni sulla tua soluzione attuale, ma pensa solo a rivisitare il tuo modello di dati come opzione aggiuntiva insieme al resto poiché tu potrebbe trovare qualche indizio graffiare lì.

Di solito gli elenchi di valori-chiave vanno bene come compromesso quando non è possibile implementare il modello nel suo stato finale perché non si conoscono le diverse chiavi che si dovranno affrontare o quando saranno necessari i valori di uno dei possibili chiavi per un determinato elemento. Ma una volta implementato, di solito mi piace ripensare tali decisioni dopo un po 'quando hai raccolto una quantità sufficiente di informazioni per identificare il caso d'uso comune e decidere se la decisione del modello di dati è la migliore. Se sai che avrai un certo numero di chiavi, prova a fare alcuni benchmark con un design di una tabella normale in modo tradizionale

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... e aggiungendo gli indici corrispondenti. Provalo e misura i piani di esecuzione con entrambi gli approcci. Potresti essere sorpreso specialmente se raccogli più di una chiave alla volta, poiché, tra gli altri vantaggi, la dimensione del blocco dati dovrebbe essere ridotta e quindi le prestazioni sarebbero migliorate.

Spero che questo aiuti, o almeno allarghi le possibilità e apra una nuova linea per le indagini.