2016-03-31 14 views
5

Cassandra domanda per principianti. Sto raccogliendo alcuni dati da un sito di social network usando le chiamate REST. Così finisco con i dati che tornano in formato JSON. Il JSON è solo una delle colonne nel mio tavolo. Sto cercando di capire quale sia la "migliore pratica" per memorizzare la stringa JSON. Per prima cosa ho pensato di utilizzare il tipo della mappa, ma il JSON contiene un mix di stringhe, tipi numerici, ecc. Non mi sembra possibile dichiarare tipi di caratteri jolly per la chiave/il valore della mappa. La stringa JSON può essere abbastanza grande, probabilmente con dimensioni superiori a 10 KB. Potrei potenzialmente memorizzarlo come una stringa, ma sembra che sarebbe inefficiente. Suppongo che questo sia un compito comune, quindi sono sicuro che ci sono alcune linee guida generali su come farlo. So che Cassandra ha il supporto nativo per JSON, ma da quello che capisco, è usato principalmente quando l'intera mappa JSON corrisponde a 1-1 con lo schema del database. Non è il mio caso. Lo schema ha un mucchio di colonne e la stringa JSON è solo una sorta di "payload". È meglio memorizzare la stringa JSON come un blob o come "testo"? A proposito, la versione di Cassandra è 2.1.5. Ogni suggerimento è apprezzato. Grazie in anticipo.Modo efficiente per memorizzare una stringa JSON in una colonna Cassandra?

risposta

6

Il motore di Cassandra bagagli non c'è davvero una grande differenza tra un blob e un testo, dal momento che Cassandra memorizza il testo come blob in sostanza. E sì, il supporto JSON "nativo" di cui parli riguarda solo quando il tuo modello di dati corrisponde al tuo modello JSON, ed è solo in Cassandra 2.2+.

Lo memorizzerei come tipo di testo e non dovresti dover implementare nulla per comprimere i tuoi dati JSON quando invii i dati (o gestisci la decompressione). Dal momento che il protocollo binario di Cassandra supporta l'esecuzione di transport compression. Assicurati inoltre che la tua tabella stia memorizzando lo data compressed con lo stesso algoritmo di compressione (ti suggerisco di usare LZ4 dato che è il metodo algo più veloce impiantato) per risparmiare sulla compressione per ogni richiesta di lettura. Pertanto, se si configura la memorizzazione dei dati compressi e si utilizza la compressione di trasporto, non è nemmeno necessario implementarli.

Non hai detto quale driver client stai usando, ma ecco la documentazione su come impostare Transport Compression per Datastax Java Client Driver.

+0

Grazie per la risposta.Sto usando Spring Data Cassandra, 1.3.4.RELEASE, che mi obbliga a stare con una versione di Cassandra Driver 2.X. Sto usando 2.1.9 come versione del driver. Spring fornisce un bean factory per creare l'istanza Cluster e sembra che non supportino solo la compressione, o Snappy. Il metodo per specificare ciò richiede un Enum come unico argomento e l'Enum ha solo queste due opzioni. Non so perché. Credo che proverò con Snappy per ora dal momento che è supportato. O posso lasciare Spring Data Cassandra e solo istanziare manualmente il Cluster. – user2337270

+1

Non sono un fan dei dati primaverili per Cassandra, dal momento che la sua API è stata progettata per database relazionali che hanno portato a decisioni di implementazione scarse. Gli esempi includono: CassandraOperations.insert (elenca gli oggetti ) eseguirà un'istruzione BATCH per tutti gli inserti, che è un anti-pattern. Se si implementano dati Pagable, verrà eseguito un conteggio (*) e, per impostazione predefinita, non verrà utilizzato l'autopagamento dei dati (è necessario optare per l'opzione tramite Pagable Slices). Come tale, consiglio vivamente di utilizzare il driver Datastax, ma otterrete un controllo e funzionalità migliori per lo sviluppo contro Cassandra. – fromanator

+0

Buono a sapersi @fromanator. Un'altra limitazione a cui mi sono imbattuto recentemente è che Spring Data Cassandra non supporta i driver 3.X di DataStax, quindi per il momento sono bloccato su 2.X. – user2337270

2

Dipende da come si desidera interrogare il proprio JSON. Ci sono 3 possibili strategie:

  1. negozio come una stringa
  2. Store come un blob compresso
  3. Store come un blob

Opzione 1 ha il vantaggio di essere leggibile quando interrogare il dati sulla riga di comando con cqlsh o se si desidera eseguire il debug dei dati direttamente dal vivo. Lo svantaggio è la dimensione di questa colonna JSON (10k)

L'opzione 2 ha il vantaggio di mantenere il payload JSON piccolo perché gli elementi di testo hanno una razione di compressione abbastanza decente. Gli svantaggi sono: a. è necessario occuparsi del lato client di compressione/decompressione eb. non è leggibile direttamente

Opzione 3 ha svantaggi di opzione 1 (size) e 2 (non leggibile)

+0

Dovresti essere in grado di utilizzare la compressione a livello di tabella insieme alla compressione di trasporto binario in modo da non dover gestire autonomamente la compressione. In questo modo è possibile archiviarlo come un tipo di dati testuali, comprimerlo quando viene salvato e inviato via cavo alla propria applicazione, oltre ad essere facilmente leggibile dall'uomo (dal momento che il driver del client o anche cqlsh lo presenterà in modalità non -forma compressa). – fromanator

+0

Sì, ci sono anche opzioni di compressione di compressione e di compressione della tabella, +1 – doanduyhai

Problemi correlati