9 komentářů k článku Jak Skrz.cz řadí 20K nabídek podle real-time analytiky:

  1. Janci

    rank service
    rozumiem tomu spravne, ze pri kazdom hladani sa na kazdu polozku vysledku zavola rank service? kolko dotazov na rank service ide z jedneho hladania?

  2. Jakub KulhanAutor příspěvku

    Re: rank service
    Ano, Elasticsearch (i native) script má při hledání přístup pouze k jednomu dokumentu naráz, nelze tedy moc dobře batchovat získání ranku pro výsledky hledání. Volání pro získání ranku v proto3 syntaxi vypadá takhle.

    message ItemRankRequest { string type = 1; uint32 id = 2; }
    message ItemRankResponse { double rank = 1; }
    service Rank {
        rpc GetItemRank (ItemRankRequest) returns (ItemRankResponse);
    }
    

    Co se týče počtu dotazů, záleží o jakou stránku zrovna jde – nejvíce trafficu je v top kategoriích jako Pobyty & Cestování; Oblečení, móda a obuv; Nábytek – tam jsou 1500-3000 položek k orankování při jednom načtení stránky -, na homepage je to ještě o řád více.

    Všechny requesty jdou ale přes Guava LoadingCache. Ta umožňuje asynchronní refresh položek, tudíž pokud in-memory rank expiruje, vrátí se stará data a načítání probíhá v jiném threadu. (Cache si navíc hlídá, aby se pro jeden klíč probíhal v jeden okamžik pouze jeden refresh.) Podle nastavení, jak často se má rank refreshovat (s čímž si pořád hrajeme), jde na rank service 250-2000 req/s.

  3. Tomáš

    hezké řešení, líbí se mi jak jste se s problémem vypořádali. Udělali byste to stejně, kdybyste to teď dělali na zeléné louce?

    Jak to vidím takhle zdálky a strašně jednoduše, šel bych jinou cestou. Položek máte málo, uživatelů také, vše se vám vejde do RAM… Například bych vzal velkej hrnec, goučko, zamíchal bych to, přidal krapet shared memory a okořenil to trochou redisu pro persistenci a sync více nodů (nebo klidně na to zneužít replikační protokol elasticu). Za pár dní vaření máte první koláčky…

    Elasticsearch mi v tom připadá až moc těžkopádný, nedělá nic jiného než točí celým strojem, jen aby seřadil pár tisíc položek s rankingem, který si stejně vyzobá externě. V elasticu bych nechal pouze historii, nejspíš jí tam máte, ale live data strčil do paměti a vařil z nich chutné jídlo…

    Jak řešíte ranking a ruční prioritizaci nebo marketing dostal zákaz to ovlivňovat? Výpočet rankingu máte dopředu stanovený podle nějakých vah za jednotlivé akce nebo se snažíte dalekovíce předvídat o co je zájem nebo co zákazník ještě nekoupil nebo co by už mohl znovu koupit?

    PS: nenabíráte?

  4. Jakub KulhanAutor příspěvku

    Re:
    Tomáši, ano, pokud by šlo pouze o řazení, Elasticsearch je tam zbytečný. Dělat si však na vlastní pěst filtrování (kde ES má nejrůznější filter cache), fulltext a distribuci dat v clusteru by bylo velmi na dlouho. Výběr nabídek do marketingu zase řeší jiné „automaty“ podle aktuálních trendů sesbíraných z různých zdrojů – žádný zákaz tam tedy není, ale ani potřeba to ovlivňovat ručně. Ohledně „personalizace“ řazení testujeme různé verze, některé se snaží vidět do budoucna méně, některé více, stejně tak je to s vahami různých signálů.

    PS. Pokud máš zájem, napiš naší Kačce na katka@skrz.cz, ona dohodne vše potřebné.

  5. harrison314

    Radenie
    Viete mi povedat, ake algoritmy pouzivate na vypocet zoradnia produktov a odporucani?
    Kludne aj vo vseobecnosti.

  6. Jakub KulhanAutor příspěvku

    Re: Radenie

    Viete mi povedat, ake algoritmy pouzivate na vypocet zoradnia produktov a odporucani?
    Kludne aj vo vseobecnosti.

    Jak jsem psal do poznámky [1]: „Doporučuji hledat whitepapery s keywords jako ranking, learning to rank, personalization, recommendation system ad.“ Rozšířím to ještě o konkrétnější Netflix prize (ohledně personalizace a recommendations) a AdWords problem (ranking).

  7. karel

    Re:
    Také mi to dělo připadá na vrabce trochu velké,
    já mám než elastic raději sphinxsearch je sním trošku víc trápení, ale výsledek stojí za to.
    Ale vážně těch položek je opravdu docela málo na takovéhle řešení.

  8. Tomáš

    Re:
    Díky za odpověď, já si právě myslím, že to vše lze udělat bez elasticu jednodušeji :) No, spíše vím to, už jsem pár řešení postavil a low latency distribuované aplikace jsou můj pevný bod v tomhle rychlém světě.

    Rozumím vašemu řešení i důvodu proč jste ho použili, nejspíš bych také u něj skončil, ale třeba na co asi musíte narážet je škálování (ten go tcp server bude vždy brzda), vývoj (vývojář nejspíš nebude mít tuhle mašinérii u sebe, ale bude používat sdílený vývojový cluster) a testování (daleko hůře s tímhle lze psát int. testy a automatizaci).

    S personalizací to může být jiná zábava :), já vždy narážel vlastně na to, že neumím segmentovat správně nabídky nebo že jim nerozumím. Pokud si někdo koupí zájezd, těžko mu budu nabízet večeři v Praze, raději bych chtěl v místě zájezdu, stejně tak mu těžko budu nabízet zájezd zase za týden. Máte tohle nějak řešené nebo jste se ještě tak daleko nedostali? Tenhle trh už moc nesleduji.

    PS: díky za nabídku :), neptal jsem se pro sebe, ale mám kolem sebe několik lidí, kteří tápou, tak je pingnu. Na Cirkus jsem koukal, děkuji, možná někdy příště, přednášky mě neberou, ale diskuze může být plodná.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=16045