Golang

ScyllaDB izmantošana pirms ražotāja ir antipattern. Kā pareizi organizēt dublēšanas novēršanu?

Kāpēc mums ir nepieciešams glabāt neapstrādātus datus S3 glabātuvē? Vai ir pareizi izmantot TTL Redis 5 minūtes, vai labāk glabāt ilgāk — 24 stundas, un izmantot ScyllaDB kā datu pārbaudes avotu?

Pieņemsim, ka mēs esam liels reklāmas tīkls. Mēs izvietojam banerus partneru vietnēs visā pasaulē. Mums jāizstrādā reāllaika notikumu vākšanas un apstrādes sistēma. Šie dati ir kritiski svarīgi diviem mērķiem: Rēķināšana: naudas atskaitīšana no reklāmdevējiem par klikšķiem. Analītika: pašreizējās kampaņu efektivitātes (CTR, rādījumi) rādīšana personīgajā panelī. Ievades dati (slodzes aprēķināšanai) Jums jānovērtē nepieciešamās jaudas (RPS, trafiks, glabāšana), balstoties uz šīm metriku: Partneru tīkls: 500 000 aktīvu vietņu. Trafiks: Vidēji katra vietne saņem 2 lapu apskatus sekundē. Reklāmas blokiem: Katru lapu vienlaikus tiek rādīti 3 baneri. Konversija: Vidējais CTR (Click-Through Rate) ir 1%. Nepareizs: Pīķa slodze (vakara stundās) ir 4 reizes augstāka nekā vidēji. Notikuma lielums: Notikuma objekts (Banera ID, Vietnes ID, UserID, Timestamp, notikuma tips) sver apmēram 500 baitus. Tehniskās prasības Near Real-Time: Dati analītiskajā interfeisā jāparādās ne vēlāk kā 10 sekundēs. Uzticamība: Kliku zudums nav pieņemams (tas tieši nozīmē naudas zaudēšanu). Rādījumu zudums (impressions) ir pieņemams līdz 0,01%. Mērogojamība: Sistēma jābūt viegli paplašināmai, pieaugot platformu skaitam.