Sunteți pe pagina 1din 16

ONLINE EVENT

PROCESSING
Atinge consistenta acolo unde
tranzactiile distribuite au esuat
ACID
Atomicitatea - bazat pe conceptul
“totul sau nimic”

Consistenta - consistenta bazei


de date

Independenta - previne interferenta


tranzactiilor

Durabilitatea - toate modificarile


comise de o tranzactie nu vor fi
pierdute in caz de esec
Log-uri de events = OLEP
(online event processing)
PERSISTENTA POLYGLOT

➜ = Combinatie de tehnologii de stocare


• Ex: full-text search, data warehousing, stream
processing, application-level caching

➜ Tehnologiile de stocare folosite nu sunt total


independente
BUILDING UPON EVENT LOGS

➜ Tranzactii eterogene distribuite =>


atomicitatea scrierii intre 2 sisteme

➜ Majoritatea serverelor de cautare nu suporta


tranzactiile distribuite => 2 probleme
• Scriere non-atomica
• Ordinea diferite a scrierilor

➜ Solutia = adaugare de update event intr-un log


ABSTRACTIZAREA LOG-URILOR

➜ Ex: Apache Kafka, CORFU de la Microsoft,


LogDevice de la Facebook

➜ Proprietati comune implementarilor


● Durabilitatea
● Append-only
● Citire secventiala
● Toleranta la erori
● Partitionarea
SEMANTICA ‘EXACTLY-ONCE’

➜ Daca un event a fost procesat de mai multe ori


=> efectul procesarilor e de fiecare data acelasi

➜ Daca un consumator de log-uri scrie in sisteme


de stocare externe, semanticele exactly-once
nu pot fi asigurate

➜ Idempotenta - baza framework-urilor cu


semantica exactly once pentru a asigura
eliminarea efectelor unei procesari multiple
Atomicitatea si impunerea constrangerilor
Modalitate de functionare
1. Utilizatorul adauga un eveniment de cerere de
plata la logul contului sursa
2. Un proces executant al platii subscrie la log-ul
contului sursa
3. Comunicarea cu baza de date locala si
adaugarea evenimentele la diferite log-uri.
4. Evenimentul de plata de iesire se intoarce inapoi
la procesul executant care a subscris acestuia.
5. Restul celorlalte evenimente sunt procesate intr-
un mod similar si idempotent
6. Posibilitatea serverului de a subscrie la log-ul
contului sursa pentru a fi notificat in legatura cu
plata (poate esua)
Procesarea multipartiție

➜ Fiecare cont are un log separat care se poate


stoca pe un nod diferit
➜ Procesul executant subscrie doar la
evenimentele unui singur cont.
➜ Impartirea tranzactiei intr-un pipeline de
procese pe etape multiple permite fiecarei etape
sa progreseze doar pe baza datelor locale =>
partitiile nu sunt niciodata blocate si ofera
scalabilitate sistemelor OLEP.
Avantajele procesarii de eveniment

➜ Vizualizari derivate noi, servicii bazate pe log-


uri de eveniment usor.
➜ Subscriberii se pot programa asa incat sa
ignore evenimente gresite
➜ Debugging-ul este mult mai usor
➜ Facilitate crescuta in privinta modelarii datelor
➜ Log-ul unui eveniment este mult mai valoros
pentru un analist de date
➜ La un log cu subscriberi multipli, fiecare nod
progreseaza independent.
Dezavantajele abordarii OLEP

▪ Nu exista o limita de timp pentru procesarea


evenimentelor prin OLEP => inconsistente in
randul valorilor citite
Studiu de caz : THE NEW YORK
TIMES

➜ infiintat in 1852, pastreaza tot continutul


text intr-o singura partitie log in Apache
Kafka

➜ de fiecare data cand un nou continut


(asset) este publicat sau actualizat, se
adauga un eveniment la log, la care
subscriu mai multe servere.
Concluzie

✔ OLEP este folosita din ce in ce mai


mult datorita performantei superioare,
a consistentei puternice pe care o
poate garanta, fiind si linear scalabila.
Multumim!
Bodea Alexandru
& Bud Denisa