Event sourcing - penalizzazione delle prestazioni? [chiuso]

3

Sto cercando di convincere le persone della mia azienda che dovremmo passare al sourcing di eventi. Il nostro software è un prodotto costituito da molti moduli, come un modulo per wiki, blog, documenti, ecc. Vorrei utilizzare il sourcing di eventi anche per consentire una facile collaborazione sugli artefatti (come i blog), per avere una cronologia delle modifiche, per ridurre al minimo i problemi di modifica simultanea e così via.

C'è anche una funzione di staging - dove i moduli possono essere messi offline, così le persone possono lavorarci sopra; e poi applicato online una volta quando le modifiche sono finite.

Una delle ragioni per cui nessuno vuole andare in questa direzione è la quantità di eventi da perseguire. Gli eventi dovevano essere molto granulari, a causa della varietà di azioni che gli utenti possono fare. Ma non c'è altra operazione sugli eventi: 1) aggiungendoli 2) leggendoli da un punto all'altro nel tempo. Più oltre, possiamo avere il concetto di eventi "applicati"; alcuni moduli non hanno bisogno di tenere traccia della cronologia completa, solo quelli più recenti.

Quindi mi chiedo se c'è qualche esperienza su come gli eventi persistenti possono influenzare le prestazioni del sistema?

    
posta lawpert 10.11.2014 - 09:27
fonte

1 risposta

9

Potrei essere in grado di fornire un po 'di intuizione (distorta) (che non dovresti prendere per il valore nominale) dal momento che di recente ho avuto il piacere di fare una dimostrazione di concept nell'implementazione di eventi per uno dei miei prodotti aziendali. Prima di questo POC avevamo un sistema "classico" con un RDBMS in fondo che non salvava alcun evento, la prova del concetto era di sostituire l'intero livello di servizio con un'architettura CQRS che utilizzava GetEventStore per eventourcing e Raven come modello di lettura.

Alla fine, non ci sono state grosse modifiche alle prestazioni che i nostri utenti potrebbero individuare (a volte più veloci, a volte più lenti) rispetto alla classica implementazione RDBMS. Perché? Soprattutto perché sul lato della lettura si sta salvando tutto denormalizzato "pronto all'uso" che rende l'interrogazione davvero molto veloce e semplice. Anche la scrittura è stata piuttosto veloce, anche se abbiamo fatto l'ingenuo "leggi tutti gli eventi da un flusso e applicali" - approccio. Ma dal momento che avevamo fatto la dovuta diligenza nella progettazione del dominio, dovevamo solo leggere un singolo flusso e spesso un flusso sufficiente per un singolo aggregato non aveva molti eventi così rispetto all'unione e al raggruppamento e alle cose che abbiamo fatto nel classico RDBMS in questo modo non è stata molto diversa. E se avessimo avuto abbastanza eventi in un flusso, avremmo potuto utilizzare le istantanee per non dover rileggere ogni singolo evento da uno streaming. Ma in genere non è necessario eseguire anticipatamente tali ottimizzazioni: rimarrai sorpreso dalla rapidità con cui possono essere letti e applicati gli eventi.

Alla fine però, questo è stato più lento (ASPETTA! Non ho appena detto che era più veloce prima?) Dannazione, hai visto le mie bugie!: D) visto che siamo andati anche a un'architettura CQRS dove avevamo diversi server che comunicano tramite messaggistica e quindi anche consistenza BASE. Semanticamente rispetto alla classica versione RDBMS questo era più lento poiché per avere una consistenza completa bisognava aspettare fino a quando l'evento non ha raggiunto il livello di lettura. Tuttavia, gli utenti raramente hanno notato questo rallentamento aggiunto - e anche quando lo hanno fatto è stato del tutto accettabile. E in molti casi ci siamo resi conto che gli utenti non avevano alcun uso per un modello di consistenza completa e non avevamo bisogno di aspettare che l'evento attraversasse l'intero sistema. Gli utenti potrebbero continuare a lavorare comunque. Questa è stata una sorta di realizzazione "dura" che ha richiesto molto tempo ai nostri uomini d'affari per accettare, ma è la verità: la coerenza in un sistema distribuito è comunque un mito, non appena mostri qualcuno sullo schermo è molto probabile comunque vecchio e obsoleto.

In base alla mia esperienza, il principale colpo di performance che prendi da eventi non è il salvataggio dei tuoi dati come un flusso di eventi, è piuttosto veloce e se ottieni flussi giganteschi - inizia a scattare istantanee. L'hit principale della tua performance è quello che scegli tu stesso quando devi attendere gli eventi che attraversano l'intero sistema.

In generale, non direi che "performance" è una buona ragione per non utilizzare l'eventourcing. Purtroppo, alla fine, non abbiamo scelto di andare nella direzione degli eventi nella mia azienda. Anche se questo non è stato a causa delle prestazioni o di una ragione del genere - è stato solo perché avevamo troppe persone che hanno avuto troppo paura di buttare fuori l'RDBMS. : (

    
risposta data 10.11.2014 - 13:19
fonte

Leggi altre domande sui tag