Utilizzo di Cassandra come archivio eventi

Question

Voglio sperimentare l'utilizzo di Cassandra come archivio eventi in un'applicazione di approvvigionamento eventi. I miei requisiti per un negozio di eventi sono abbastanza semplici. L'evento 'schema' sarebbe qualcosa di simile a questo:

• id: l'id di un'entità di radice di aggregazione
• dati: i dati relativi agli eventi serializzati (ad esempio JSON)
• timestamp: quando l'evento si è verificato
• sequence_number: la versione unica della manifestazione

Sono completamente nuovo a Cassandra quindi perdonami per la mia ignoranza in ciò che sto per scrivere. Ho solo due query che vorrei mai eseguire su questi dati.

1. Dammi tutti gli eventi per un dato id radice aggregato
2. Dammi tutti gli eventi per una data radice globale se dove numero progressivo è> x

La mia idea è quella di creare una tabella di Cassandra in CQL come questo:

CREATE TABLE events (
    id uuid, 
    seq_num int, 
    data text, 
    timestamp timestamp, 
    PRIMARY KEY (id, seq_num)); 

Questo sembra un modo ragionevole per modellare il problema? E, cosa importante, l'uso di una chiave primaria composta mi consente di eseguire in modo efficiente le query che ho specificato? Ricorda che, dato il caso d'uso, potrebbe esserci un grande numero di eventi (con un diverso seq_num) per lo stesso id radice aggregato.

mia specifica preoccupazione è che la seconda query sta per essere inefficiente in qualche modo (sto pensando di indici secondari qui ...)

Answer 1

Il vostro disegno sembra essere ben modellata in "termini Cassandra". Le query necessarie sono effettivamente supportate nelle tabelle "chiave composita", avresti qualcosa di simile:

• query 1: select * from events where id = 'id_event';
• query 2: select * from events where id = 'id_event' and seq_num > NUMBER;

Non credo che la seconda query sta per essere inefficiente, ma può restituire un sacco di elementi ... se questo è il caso si potrebbe impostare un "limite" di eventi da restituire. Se ciò è possibile, è possibile utilizzare la parola chiave limit.

L'uso di tasti compositi sembra una buona corrispondenza per le vostre esigenze specifiche. L'uso di "indici secondari" non sembra portare molto in tavola ... a meno che non mi sfugga qualcosa nella tua progettazione/requisiti.

HTH.

Answer 2

Io non sono agrre con il tuo progetto per salvare aggregateroot su eventstore.you si potrebbe salvare domainevent per la flessibilità. Spiega eventdomain è il più gran numero di dati che rendono la modifica dello stato di application.aggregateroot non corrisponde a eventstore è per lo scambio di dati o boundedcontext. quando si utilizza l'evento di dominio è possibile ricostruire i dati anche con aggregazione di dati con la modellazione di plolygot.è possibile gestire il modello per le esigenze del cliente e i vincoli. Quindi modellare il grafico per i collegamenti tra domainobject e successivamente utilizzare neo4j, oltre al modello di aggregazione del modello e utilizzare documentdatabase. Significo che si ha l'opportunità di modificare il modello e usa il comodo motore di persistenza. È una differenza tra i dati di polygot e la persistenza di polygot. nella tua strategia capisco in due modi: se hai bisogno di eventi per la tua modellazione su database domainevent e cassandra. se hai bisogno di dati aggregati o di modelli e non di eventi, si utilizza un database documentato e si possono riattivare le due query.

si potrebbe eliminare la confusione sulla progettazione guidata da domini.

Answer 3

Quello che hai è buono, tranne nel caso di molti eventi per un particolare aggregato. Una cosa che potresti fare è creare una colonna statica per contenere "next" e "max_sequence". L'idea è che le colonne statiche mantengano la sequenza massima corrente per questa partizione e l'"ID artificiale" per la partizione successiva. È quindi possibile, ad esempio, memorizzare 100 o 1000 eventi per partizione. In pratica, ciò che hai fatto in pratica è il bucket degli eventi per un aggregato in più partizioni. Ciò significherebbe un sovraccarico aggiuntivo per l'interrogazione e l'archiviazione, ma allo stesso tempo proteggere da una crescita illimitata. Si potrebbe anche creare una ricerca di partizioni per un aggregato. Dipende davvero dal tuo caso d'uso e da quanto "intelligente" vuoi che sia.

Answer 4

Sto usando Cassandra per uno scenario molto simile (con 100k + colonne per riga) e terminato con un modello vicino al tuo. Sono anche d'accordo con emgsilva sul fatto che un indice secondario probabilmente non porterà molto.

Ci sono tre cose che si sono rivelate significative per le buone prestazioni per il nostro negozio di eventi: Utilizzo di colonne composte, assicurandosi che le colonne siano in un ordine ben ordinabile (Cassandra ordina i dati in righe per colonne) e utilizzando il compatto conservazione se possibile.

Nota che la memoria compatta significa che puoi avere solo una colonna di valori. Quindi, è necessario rendere tutte le altre colonne parte della chiave.

Per voi, lo schema sarebbe:

CREATE TABLE events (
    id uuid, 
    seq_num int, 
    timestamp timestamp, 
    data text, 
    PRIMARY KEY (id, seq_num, timestamp)) 
    WITH COMPACT STORAGE; 

Answer 5

tua chiave di partizione è troppo granulari, è necessario creare una chiave di partizione composito o modificarlo per ottenere prestazioni migliori per modelli di serie storiche. Per esempio

CREATE TABLE events (
    event_date int, 
    id timeuuid, 
    seq_num int, 
    data text, 
    PRIMARY KEY (event_date, id)); 

questo modo il tuo ID diventerà una colonna di clustering solo per garantire unicqueness evento e la tua chiave di partizione (es. 20.160.922) possibile raggruppare tutti gli eventi al giorno. Puoi cambiarlo anche al mese. Evita di usare uuid timeuuid, invece, memorizza già le informazioni di timestamp.