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