Implementacja źródła zdarzeń - czy będzie skalować?

Question

Sytuacja:

Jestem obecnie projektowaniu systemu podawania na stronie społecznej przy czym każdy użytkownik ma paszy działalności swoich przyjaciół. Mam dwie możliwe metody generowania kanałów i chciałbym zapytać, która z nich jest najlepsza pod względem możliwości skalowania.

Zdarzenia od wszystkich użytkowników są gromadzone w jednej centralnej tabeli bazy danych, event_log. Użytkownicy są sparowani jako znajomi w tabeli friends. RDBMS, którego używamy, to MySQL.

metoda: Gdy użytkownik żąda ich stronie kanałów, system generuje paszy przez wewnętrzne połączenie event_log z friends. Wynik jest następnie buforowany i ustawiony na timeout po 5 minutach. Skalowanie uzyskuje się przez zmianę tego czasu oczekiwania. Metoda

hipotezę: Zadanie działa w tle i dla każdego nowego, nieprzetworzonego towaru w event_log tworzy wpisy w tabeli bazy danych user_feed Parowanie to wydarzenie ze wszystkimi użytkownikami, którzy są przyjaciółmi z użytkownikiem, który zainicjował wydarzenie. Jeden wiersz tabeli łączy jedno zdarzenie z jednym użytkownikiem.

Problemy z metodą standardową są dobrze znane - a jeśli wiele pamięci podręcznych osób wygaśnie w tym samym czasie? Rozwiązanie również nie jest skalowalne - w skrócie, aby aktualizacje były aktualizowane jak najbliżej czasu rzeczywistego.

Hipotezne rozwiązanie w moich oczach wydaje się znacznie lepsze; Całe przetwarzanie odbywa się w trybie offline, więc żaden użytkownik nie oczekuje na wygenerowanie strony i nie ma połączeń, dzięki czemu tabele bazy danych mogą zostać odrzucone na fizycznych maszynach. Jeśli jednak użytkownik ma 100 000 przyjaciół i tworzy 20 zdarzeń w jednej sesji, powoduje to wstawienie 2 000 000 wierszy do bazy danych.

Pytanie:

Pytanie sprowadza się do dwóch punktów:

• Jest to najgorszy scenariusz wymienione powyżej problemy, czyli ma wielkość stołu mieć wpływ na wydajność MySQL i czy są jakieś problemy z tym masowym wstawianiem danych dla każdego zdarzenia?
• Czy jest coś jeszcze, co przegapiłem?

Answer 1

Myślę, że twój system hipotezy generuje zbyt dużo danych; po pierwsze w skali globalnej wymagania dotyczące przechowywania i indeksowania na stronie user_feed wydają się eskalować w postępie geometrycznym, gdy baza użytkowników staje się większa i bardziej wzajemnie połączona (oba prawdopodobnie są pożądane w przypadku sieci społecznościowej); po drugie rozważ, czy w ciągu minuty po 1000 użytkowników każdy wprowadził nową wiadomość, a każdy z nich miał 100 znajomych - wtedy twój wątek tła ma 100 000 wstawek do wykonania i może szybko zostać z tyłu.

Zastanawiam się, czy uda się ułożyć kompromis między dwoma proponowanymi rozwiązaniami, w których wątek w tle aktualizuje tabelę last_user_feed_update, która zawiera pojedynczy wiersz dla każdego użytkownika, oraz znacznik czasu po ostatniej zmianie podawania danych przez użytkowników.

Następnie, mimo że pełne odesłanie i zapytanie będą wymagane do odświeżenia kanału, szybkie zapytanie do tabeli last_user_feed wyświetli informację, czy wymagane jest odświeżenie, czy nie.Wydaje się to łagodzić największe problemy ze standardową metodą, a także unikać problemów związanych z rozmiarem pamięci, ale wątek w tle nadal wymaga wiele pracy.

Answer 2

Metoda hipotetyczna działa lepiej, gdy ogranicza się maksymalną liczbę znajomych. Wiele stron ustawia bezpieczną górną granicę, w tym Facebook iirc. Ogranicza "czkawkę", gdy użytkownik 100K znajomych generuje aktywność.

Innym problemem z hipotetycznym modelem jest to, że niektórzy z znajomych, którzy w zasadzie generują wstępne generowanie pamięci podręcznej, mogą się zarejestrować i prawie nigdy się nie logują. Jest to dość powszechna sytuacja w przypadku darmowych witryn, a możesz chcieć ograniczyć obciążenie, że te nieaktywne użytkownicy będą cię kosztować.

Wiele razy myślałem o tym problemie - to nie problem MySQL będzie dobry w rozwiązywaniu. Zastanawiałem się, w jaki sposób mogę użyć memcached, a każdy użytkownik przesyła informacje o tym, co ich ostatnie elementy statusu mają do "swojego klucza" (oraz w czytaniu pliku danych, które pobierasz i zbierają wszystkie klucze twojego znajomego) ... ale ja nie testowałem to. Nie jestem jeszcze pewien wszystkich zalet/wad.