2009-08-15 11 views
8

Chcę zaimplementować licznik widoku skierowany do użytkownika (podobny do tego, jaki SO ma dla widoków pytań), który śledzi liczbę unikalnych widoków na stronie. Jest kilka pytań na temat similar, ale wydaje się, że nie odpowiadają one całkowicie na moje pytanie.Zaimplementuj unikalny licznik wyświetleń strony?

Jaka byłaby najlepsza konfiguracja (pod względem tabel bazy danych itp.)? Czy byłoby dobrze dodać kolumnę "widoki" do tabeli "pytania" i po prostu zwiększyć ją przy każdym wyświetleniu strony? A jeśli chcę, aby widoki były unikatowe, myślę, że mógłbym mieć kolejną tabelę z pytaniami i adresami IP i tylko zwiększać kolumnę "widok", jeśli nie ma już wpisu z bieżącym adresem IP. Jednak ta tabela "widok-ip" bardzo szybko stałaby się ogromna ... Głównie martwię się koniecznością przechowywania każdego widoku strony i każdego adresu IP w tabeli.

W jaki sposób można to zoptymalizować, aby nie stało się wąskim gardłem wydajności? Czy istnieje lepsze podejście niż to, co opisałem? Zwróć uwagę, że bardzo ważne jest dla mnie, że policzone są tylko unikalne widoki.

Aktualizacja: oprócz sugerując sposoby realizacji, Chciałbym również, aby lepiej zrozumieć, gdzie problemy z wydajnością wchodzić w grę przy założeniu, że naiwne podejście po prostu sprawdzenie, czy istnieje IP i aktualizacji „view” kolumny na każdy widok strony. Czy głównym problemem jest ogromna liczba wstawień (zakładając duży ruch) lub czy jest to większy rozmiar tabeli mapowania obiektów do IP (która może być ogromna, ponieważ dla każdego nowego unikalnego gościa zostanie wstawiony nowy wiersz dla każdego pytania). Czy warunki wyścigu powinny być brane pod uwagę (po prostu założyłem, że instrukcja update/increment sql była atomowa)? Przepraszam za wszystkie pytania, ale jestem po prostu zagubiony, jak powinienem podejść do tego.

+0

Sprawdź moją odpowiedź tutaj, być może: http://stackoverflow.com/questions/1269968/incremented-db-field/1269973#1269973 –

Odpowiedz

0

Wydaje się, że istnieje rewolucyjne podejście (nad głową), którego sam nie jestem jeszcze pewien, czy jest skalowalny, czy raczej wykonalny.

Jeśli naprawdę chcesz przechowywać IP w DB i chcesz uniknąć zapchania DB, powinieneś pomyśleć o przechowywaniu ich w hierarchicznej kolejności.

<ID, IP_PART, LEVEL, PARENT_PART, VIEWS> 

więc, gdy użytkownik odwiedza stronę internetową z ur IP 212.121.139.54, wiersze w tabeli ur byłoby:

< 1, 212, 1, 0, 0> < 2, 121, 2, 1, 0> < 3, 139, 3, 2, 0> < 4, 54, 4, 3, 1>

wskazuje na Uwaga:

  1. Tylko wiersze z LEVEL val = 4 będą miały liczbę wyświetleń.
  2. Aby uniknąć nadmiarowości przechowywania VIEWS val = 0, dla LEVEL val = 1,2,3; możesz myśleć o przechowywaniu ich w innej tabeli.
  3. Pomysł, jak się spodziewał, nie wydaje się odpowiedni dla małego zestawu adresów IP.
  4. Chociaż mogło to zaniedbać fakt, że publiczny serwer proxy IP znajduje się przed prywatną siecią, która uzyskuje dostęp do strony internetowej z więcej niż jednego pola. Ale to chyba nie jest pytanie. zgaduję.

tak, chao, daj mi znać, co wprowadziłeś?

6

Jeśli chcesz śledzić unikalne widoki, prawdopodobnie istnieją dwa sposoby, aby to zrobić ... chyba że pracujesz z użytkownikami wewnętrznymi, których możesz zidentyfikować. Teraz, aby to zrobić, musisz śledzić każdego użytkownika, który odwiedził stronę.

Śledzenie można wykonać po stronie serwera lub po stronie klienta.

Po stronie serwera będą to adresy IP, chyba że masz do czynienia z użytkownikami wewnętrznymi, których możesz zidentyfikować. I zawsze, gdy masz do czynienia z adresami IP, wszystkie zwykłe zastrzeżenia dotyczące korzystania z nich w celu identyfikacji osób stosują się (może być wielu użytkowników na jeden adres IP lub wiele adresów IP na użytkownika) i nie możesz nic z tym zrobić.

Należy również wziąć pod uwagę, że "ogromna tablica IP śmierci" nie jest tak źle z rozwiązania. Wydajność stanie się problemem tylko wtedy, gdy masz setki tysięcy użytkowników ... oczywiście zakładając, że jest właściwie indeksowana.

Strona klienta po stronie klienta prawdopodobnie wiąże się z opuszczeniem "Odwiedziłem!" ciastko. Jeśli plik cookie NIE jest obecny, zwiększ liczbę użytkowników. Jeśli nie można utworzyć pliku cookie, musisz żyć z zawyżonym widokiem użytkownika. A wszystkie zastrzeżenia dotyczące obchodzenia się z ciasteczkami mają zastosowanie ... co oznacza, że ​​ostatecznie zepsują się i znikną.