![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 496 Pomógł: 2 Dołączył: 15.07.2011 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
Witam,
Zrobiłem sobie pewien algorytm rekomendacyjny, który wyświetla dane na podstawie podobieństwa użytkowników. Najpierw za pomocą pewnej metryki oblicza dla kazdego użytkownika wyniki, następnie sortuje wyniki na podstawie uzyskanych wyników i na końcu wybiera 5ciu użytkowników z nawiększymi wynikami , którzy są w tym momencie najbardziej podobnymi do użytkownika zalogowanego. Mając taką grupę 5ciu użytkowników wybierane są dane, które wybierali wcześniej oni, natomiast nie wybierał ich wcześniej zalogowany użytkownik. I tak jeśli w bazie znajduje się 476 użytkowników to wyniki w toolbarze mam następujące: DB Queries: 956 Query time: 218,98 ms Invalid entities: 10 Czy ilość zapytań : 956 , przy tylu użytkownikach, przy takim algorytmie jest normalna ? Proszę o podpowiedź co w toolbarze znaczy: Invalid entities 10 . Co mogę mieć źle ? dzięki |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 623 Pomógł: 144 Dołączył: 22.12.2010 Ostrzeżenie: (0%) ![]() ![]() |
Za każdym razem przy odświeżeniu uruchamiasz przeliczanie? Jeśli tak, to może rozważ przeniesienie tego do command dla każdego użytkownika i uruchamianie co kilka/kilkanaście godzin. Albo wrzucenie wyniku raz wykonanego zapytania do cache'a (rozwiązanie bardziej sensowne)
A co do invalid entities to console doctrine:schema:validate (albo jakoś tak to szło ![]() Ten post edytował ohm 3.08.2013, 09:52:45 |
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
Cytat Czy ilość zapytań : 956 , przy tylu użytkownikach, przy takim algorytmie jest normalna ? Problem w tym, że żadnego algorytmu nie widzimy. Ale liczba zapytań jest bardzo duża.
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 350 Pomógł: 31 Dołączył: 23.05.2010 Ostrzeżenie: (0%) ![]() ![]() |
Nie lepiej tych 5 najlepiej pasujących użytkowników trzymać w oddzielnej tabeli o strukturze: id, user_id, podobny_user_id, prawdopodobienstwo_level
i podczas ewentualnego oceniania (np. filmu) sprawdzać czy dalej gusta oceniającego + user_id (z tabeli powyżej) pasują do siebie - jeśli nie, to znaleźć tylko JEDNEGO użytkownika na zastępstwo. |
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 496 Pomógł: 2 Dołączył: 15.07.2011 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat Za każdym razem przy odświeżeniu uruchamiasz przeliczanie? Jeśli tak, to może rozważ przeniesienie tego do command dla każdego użytkownika i uruchamianie co kilka/kilkanaście godzin. Tak za każdym razem przy odświeżeniu strony uruchamiam przeliczanie. Dlaczego proponujesz uruchamiać to co kilka/kilkanaście godzin ? Ja te wyniki muszę przeliczać ciągle ponieważ ciągle coś w systemie się będzie zmieniać (przybywać danych) i na tej podstawie muszę od nowa liczyć i wyświetlać "aktualnie" najlepsze wyniki. Apropo tego rozwiązania : Cytat Albo wrzucenie wyniku raz wykonanego zapytania do cache'a (rozwiązanie bardziej sensowne) Jak to się robi w Symfony ? Nie robiłem tego jeszcze a faktycznie to pewnie będzie dobre rozwiązanie. Tylko czy aby sprawdzi się to wobec tego co napisałem powyżej ? |
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
1. Symfony nie ma tutaj absolutnie nic do rzeczy. To jest temat bardziej ogólnikowy.
2. Dopóki nie podasz nam co dokładnie tam przeliczasz, na podstawie jakich danych itp. itd. nie będziemy wstanie poradzić Ci nic konkretnego. Po prostu nie wiemy jakie rozwiązania mogą się sprawdzić w takim przypadku. |
|
|
![]()
Post
#7
|
|
![]() Grupa: Zarejestrowani Postów: 915 Pomógł: 210 Dołączył: 8.09.2009 Skąd: Tomaszów Lubelski/Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Liczba zapytań jest bardzo duża, nie widzę kodu ani algorytmu, ale prawodpodobnie da się ją zmniejszyć o rząd wielkości.
Przykład: Doctrine standardowo używana tzw. lazy loading, więc załóżmy że Twoi użytkownicy mają jakąś relację z inną encją X. Pobierając normalnie 10 użytkowników i wyświetlając ich dane razem z danymi z encji X zostanie wykonanych tak naprawdę 11 zapytań (1 do pobrania użytkowników i po 1 na użytkownika do pobrania danych X). Rozwiązaniem zmniejszającym ilość zapytań jest dopisanie własnej metody do repozytorium korzystającej z query buildera (w powyższym przypadku trzeba samemu zjoinować tabele). Ten post edytował redeemer 3.08.2013, 10:18:40 -------------------- |
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 496 Pomógł: 2 Dołączył: 15.07.2011 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
OK, Crozin . Udało mi się zmniejszyć o połowę, a następnie do 10
![]() ale punkt dostaje "redeemer" ponieważ dał oczywiste rozwiązanie, o którym wiedziałem i stosowałem je wcześniej jednak nie zastosowałem w tym algorytmie ponieważ robiłem to ileś tam dni wcześniej na szybko. Teraz poprawiłem i jest pięknie. Jeszcze dzisiaj rano miałem 956 zapytań a teraz mam zaledwie 10 ![]() Trzeba myśleć niestety ![]() Pozdrawiam ![]() Ten post edytował damianooo 3.08.2013, 13:57:40 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 19.08.2025 - 19:58 |