Ukladani dat o aktivite uzivatelu rubrika: Programování: PHP

5 PetrJirasek
položil/-a 5.2.2016
 
upravil/-a 5.2.2016

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!

odkaz Vyřešeno
4 Jakub Kulhan
odpověděl/-a 5.2.2016

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.

Komentáře

  • harrison314 : Po pozreti viacerich prednasok o Skrz.cz (v suvislosti s ich performace), tak som zistil, ze nakodili starsiu prasacinu, precom nemali ani sajn co vlastne robia. Kazdopadne im to funguje,ale je to hek (este dost nefektivny) na ElasticSerach. Skor sa odporucam pozriet na to ako to robi Mall.cz . 5.2.2016
  • Jakub Kulhan : @harrison314 Můžeš dát odkaz na nějaký článek / přednášku, jak to dělá Mall.cz? 6.2.2016
  • harrison314 : Nensiel som ju, ale skusim este pohladat. No pouzili CQRS, RabbitMQ, s tym, ze komand handlery, okrem domenoveho modelu updatoval aj cache pre query. A vsteko co sa dalo slo asnchronne cez MQ teda aj maily, aj trakovanie pouzivatelov. 6.2.2016
  • Jakub Kulhan : @harrison314: Elasticsearch a real-time řazení nabídek je pouze jedno z koleček v celém soukolí, Skrz také používá CQRS a má oddělené čtení dat od zápisu. (Kvůli legacy aplikacím nejde vše modelovat jako commandy, které by updatovaly primary DB a zároveň všechny query cache - nejdříve se tedy updatuje primary DB a pak se vyšle synchronizační event, který updatuje cache čtením z primary DB.) Co se týče té "neefektivní prasečiny na Elasticsearch", zkus si spočítat, kolik by stálo implementovat filtrování a vyhledávání nad custom řazením vs. custom řazení zaintegrovat do Elasticsearch. Navíc, pokud vím, nikdo pořádně real-time personalizované řazení nedělá, všichni mají přinejlepším často updatované statické řazení s boostováním a přefiltrováváním v query time per uživatel. 6.2.2016
  • harrison314 : To som cital, aj som pozreal nejake dve prezentacie od nich. Tou nefektivnou prasacinou som myslel PHP cast kodu, nie Elastic Search, aj ked robit dopyt pri kazdom kroku radenia ... treba cachce. Ja som s tych prednasok mal pocit, ze objavili veci, ktore by sa mal kazdy SW inzinier ucit na skole a vyhlasuju to za uzasnu a objavnuvec. Cele mi to prislo ako len plno ad-hoc rieni ktore su nalepene na seba. 7.2.2016

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.