Jak skutecznie liczyć sumy dla opcji filtrów

Question

Pracuję nad aplikacją typu sklepu internetowego. Jedną z funkcji, którą często widzę na innych stronach internetowych, jest podział opcji filtrowania, a następnie łączna liczba wyników filtrowania. Często można to zobaczyć na stronach internetowych (np. Newegg) lub używanych witrynach samochodowych. Przykład:

CPU: 
    * AMD (315) 
    * Intel (455) 

Video card: 
    * ATI (378) 
    * Nvidia (402) 

Jak mogę skutecznie obliczyć te sumy? Strona, nad którą pracuję, będzie miała wiele różnych produktów (10.000+) z wieloma różnymi opcjami. Co gorsza, produkty ciągle się zmieniają.

Próba wstępnego obliczenia wszystkich różnych sum filtrowania wydaje się nie do przyjęcia. Jeśli mam 5 różnych filtrów po 4 opcje, liczba opcji będzie wynosić 20 * 16 * 12 * 8 * 4 = 122880. Obliczenie tego zajęłoby dużo czasu.

Inną opcją byłoby zapytanie na żądanie i buforowanie wyników (np. W Redis). Ale jak mogę efektywnie zarządzać pamięcią podręczną, jeśli produkty są dodawane i usuwane? Pamięć podręczna często jest nieaktualna. Obawiam się, że musiałbym mikro-zarządzać unieważnieniem pamięci podręcznej, prowadząc do bardzo złożonej i kruchej implementacji. Alternatywą byłoby unieważnienie szerokiej sekcji pamięci podręcznej. Ale zaraz po unieważnieniu, moja baza danych zostałaby rzucona przez hunderdany zapytań od aktywnych użytkowników, którzy potrzebują ponownie przeliczyć te liczby.

Czy jest to miły i elegancki sposób na poradzenie sobie z tym?

Answer 1

Nie widzę problemu z wyświetlaniem danych na żywo dla Twojej sprawy. Nie zniechęcaj się w żaden sposób, ale produkty 10K to niewiele, jeśli chodzi o wydajność. Z drugiej strony jest kilka milionów.

Czy naprawdę próbowałeś to wdrożyć w ten sposób i okazało się, że działa wolno, lub po prostu jesteś zbyt świadomy swojej teoretycznej wydajności? Proponuję przeprowadzić testy warunków skrajnych w twoim systemie tak, jak jest, i sprawdzić, czy warto je ulepszyć. Mimo to, oto kilka pomysłów, które sprawiają, że szybciej:

1. Nie liczy się zapełnić wszystkie na raz, tylko jeśli jest specyficzna kategoria rozszerzony/kliknął. Więc zawsze kończy się to pojedynczym zapytaniem SELECT cat_name, COUNT(*) GROUP BY cat_name, które nie powinno zająć dużo czasu. Pojedyncze i względnie lekkie zapytanie takie jak na kliknięcie użytkownika brzmi dla mnie rozsądnie.

2. Pozwól silnikowi bazy danych zarządzać buforowaniem dla ciebie. Jeśli często wykonujesz podobne zapytania, aparat bazy danych powinien automatycznie optymalizować bazową pamięć masową (np. Przenieść całą tabelę do pamięci lub podobną). Musisz tylko upewnić się, że instancja ma wystarczającą ilość pamięci.

3. Zaktualizuj sprzęt serwera, jeśli to konieczne. Jeśli ilość danych zwiększy się, użytkownik może nie mieć wystarczającej ilości pamięci do przechowywania wszystkiego. Nie wpadaj w panikę, nadal możesz umieścić dysk SSD lub zainstalować 12-rdzeniowy procesor Xeon na serwerze, w zależności od tego, gdzie występuje wąskie gardło.

Answer 2

A co powiesz na myślenie z othey sposób i zachowanie numerów w bazie danych? Prawdopodobnie możesz użyć wyzwalaczy do automatycznego zwiększania/zmniejszania liczników w przypadku, gdy produkt zostanie dodany do/usunięty z danego kategorii (jeśli nie, może być nadal obsługiwany jawnie przez okno dialogowe, które pozwala menedżerowi sklepu dodawać/usuwać produkty w sprzedaży) .

Wydaje się, że to dobre rozwiązanie, ponieważ a) Przypuszczam, że nazwy kategorii są przechowywane w bazie danych już teraz, tak więc liczby te są bardzo niewielkie, i b) mimo że produkty ciągle się zmieniają, są one najbardziej prawdopodobnie zmienia się z dużo niższą częstotliwością niż częstotliwość żądań (która wciąż się utrzymuje, nawet jeśli sami użytkownicy mogą dodawać/usuwać produkty). I wreszcie c) nie ma skomplikowanego schematu buforowania, liczniki są zarządzane w jednym miejscu, przez pojedynczą część kodu. Powinien być łatwy do utrzymania bezbłędny.