Golang

Korišćenje ScyllaDB pre proizvođača je antipattern. Kako pravilno organizovati deduplikaciju?

Pretpostavimo da smo velika mreža za oglašavanje. Postavljamo banere na partnerskim sajtovima širom sveta. Moramo da dizajniramo sistem za prikupljanje i obradu događaja u realnom vremenu. Ovi podaci su kritični za dva cilja: Fakturisanje: Oduzimanje novca od oglašivača za klikove. Analitika: Prikaz trenutne efikasnosti kampanja (CTR, prikazi) u ličnom panelu. Ulazni podaci (za računanje opterećenja) Morate sami proceniti potrebne kapacitete (RPS, saobraćaj, skladište), na osnovu sledećih metrika: Partner mreža: 500.000 aktivnih sajtova. Saobraćaj: U proseku, svaki sajt prima 2 prikaza stranica po sekundi. Reklamni blokovi: Na svakoj stranici se istovremeno prikazuju 3 banera. Konverzija: Prosečan CTR (Click-Through Rate) je 1%. Nepravilnost: Pikovno opterećenje (večernji sati) je 4 puta više od proseka. Veličina događaja: Objekat događaja (ID banera, ID sajta, UserID, Timestamp, tip događaja) teži otprilike 500 bajtova. Tehnički zahtevi Near Real-Time: Podaci u analitičkom interfejsu treba da se pojavljuju sa zakašnjenjem ne većim od 10 sekundi. Pouzdanost: Gubitak klikova nije prihvatljiv (ovo znači direktan gubitak novca). Gubitak prikaza (impressions) je prihvatljiv do 0,01%. Skalabilnost: Sistem treba lako da se proširuje sa rastom broja platformi.

Zašto nam je potrebno skladištiti sirove podatke u S3? Je li ispravno koristiti TTL od 5 minuta na Redis-u ili je bolje čuvati duže, na primer 24 sata, i koristiti ScyllaDB kao izvor provere podataka?