Golang

Używanie ScyllaDB przed producentem to antywzorzec. Jak poprawnie zorganizować deduplikację?

Dlaczego musimy przechowywać surowe dane w magazynie S3? Czy poprawne jest używanie TTL na Redisie 5 minut, czy lepiej przechowywać je dłużej — 24 godziny, i używać ScyllaDB jako źródła weryfikacji danych?

Załóżmy, że jesteśmy dużą siecią reklamową. Umieszczamy banery na stronach partnerskich na całym świecie. Musimy zaprojektować system zbierania i przetwarzania zdarzeń w czasie rzeczywistym. Te dane są krytyczne dla dwóch celów: Rozliczenia: Odliczanie pieniędzy od reklamodawców za kliknięcia. Analiza: Wyświetlanie aktualnej skuteczności kampanii (CTR, wyświetlenia) w panelu użytkownika. Dane wejściowe (do obliczenia obciążenia) Musisz sam ocenić wymagane moce (RPS, ruch, przechowywanie), opierając się na następujących metrykach: Sieć partnerska: 500 000 aktywnych stron. Ruch: Średnio na każdej stronie dochodzi do 2 wyświetleń stron na sekundę. Bloki reklamowe: Na każdej stronie wyświetlane są jednocześnie 3 banery. Konwersja: Średni CTR (Click-Through Rate) wynosi 1%. Nierównomierność: Szczytowe obciążenie (wieczorne godziny) jest 4 razy wyższe od średniej. Rozmiar zdarzenia: Obiekt zdarzenia (ID banera, ID strony, UserID, Timestamp, typ zdarzenia) waży około 500 bajtów. Wymagania techniczne Near Real-Time: Dane w interfejsie analitycznym powinny pojawiać się z opóźnieniem nie większym niż 10 sekund. Niezawodność: Utrata kliknięć jest niedopuszczalna (to bezpośrednia utrata pieniędzy). Utrata wyświetleń (impressions) jest dopuszczalna w granicach 0,01%. Skalowalność: System powinien łatwo się rozbudowywać przy wzroście liczby platform.