Ukladani dat o aktivite uzivatelu rubrika: Programování: PHP
Ahoj,
rad bych otevrel debatu nad tim, jak idealne ukladat data o aktivite uzivatele. Obecne, dnes velka rada aplikaci, ktere nejak pracuji s uzivateli, o nich ukladaji casto velke mnozstvi dat. Eshopy si zpravidla ukladaji informace o tom, jaky uzivatel si prohledl jaky produkt, kdy se uzivatel treba prihlasil na web, jaky email si uzivatel kdy otevrel nebo pres jaky email proklikl apod.
To vse u vetsi aplikace muze zacit generovat dost zaznamu v databazi, pokud si predstavime, ze kazdy ten event bude zaznam v tabulce, kde zaznam krome primarniho klice bude obsahovat typicky referenci na entitu, ke ktere se event vztahuje a pak cas vyvolani eventu.
Zajima me, jak se vam nejlepe osvedcilo ukladat tato data, ktera se pak casto pouzivaji treba k personalizaci, cileni apod. Zajima me to z nekolika pohledu a to:
- Pokud kazdy zaznam eventu obsahuje primarni klic, jaka strategie generovani se vam osvedcila? Pres auto increment nebo uuid nebo jinak?
- Pak taky premyslim, zda neni vhodne tato data ukladat mimo primarni databazi, kde ma aplikace (treba ten eshop) ty uzivatelske profily, produkty a objednavky. Ve vysledku pak u vetsich aplikaci databaze s temito event daty muze byt klidne na jinem stroji.
A obecne ocenim podeleni se o jakekoliv zkusenosti v teto oblasti, co se vam osvedcilo ve vasi praxi, protoze predpokladam, ze ty data ukladate prave tak, aby se vam dale dobre vyuzivala.
Diky za komentare!
Pokud umíš s relační datábází, použij relační databázi - pokud produkt míří pouze na český/slovenský trh, pro tenhle use case nenarazíš na výkonové problémy, přinejhorším se bude do stroje přihazovat více RAM / výkonnější CPU / rychlejší SSD. Dám konkrétní příklad - na Skrz.cz přes den uživatelé generují tisíce event za sekundu. Data se pushují do RabbitMQ, odkud je jeden consumer batchově ukládá do MySQL. (Když se toho sbíralo míň a eventy byly v řádech stovek, ani nešly přes RabbitMQ a rovnou se insertovaly do MySQL.) Tam se nad nimi dělají různé online analýzy a agregace. Po 30 dnech se eventy přelijí do nějakého hloupějšího úložiště - do S3. Odtamtud se na nich dají dělat hloubkové analýzy a sledovat trendy.
Jako ID event se používá 64bitový integer, kdy horních 40 bitů je UNIX timestamp a dolních 24 je increment sekvence, kterou si drží každý worker, který eventy ukládá v paměti. ID by určitě nemělo být generované náhodně, ale mělo by postupně stoupat (funguje pak lépe kešování stránek DB) - UUID by tedy šlo použít, ale musíš zvolit tu variantu, co je založena na timestampu. Nicméně 128 bitů UUID je zbytečnost a neexistuje na to pořádná podpora v databázích/jazycích, 64 bitů musí stačit. (Např. způsob generování popsaný výše má hard limit 16 milionů event za sekundu a nějakých 17 tisíc let - to by mohlo stačit pro většinu použití).
Eventy jde oddělit na jiný stroj, ale oddaluj to, dokud to půjde. Možnost si v relační DB data propojovat a dělat jednoduše agregace je neocenitelná.
Co doporučuji, hned ze začátku začít cpát eventy přes nějakou message queue, např. ten RabbitMQ. Dají se s tím pak dělat různé skopičiny.
Pro zobrazení všech 5 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře