Z pewnością jest to wykonalne różnymi metodami. Zajmę się każdą z wymienionych opcji, a także dodatkowym komentarzem.
1) Jeśli NGinx to potrafi, to pozwól. Robię to z Apache, JBOSS i Tomcat. Następnie za pomocą syslog-ng zbieram je centralnie i stamtąd przetwarzam. W przypadku tej trasy sugerowałbym format komunikatów dziennika z ogranicznikami, taki jak rozdzielany tabulatorami, ponieważ ułatwia to parsowanie i czytanie. Nie wiem, jak rejestruje zmienne PHP, ale z pewnością może rejestrować nagłówki i informacje o plikach cookie. Jeśli zamierzasz w ogóle korzystać z logowania NGinx, polecam tę trasę, jeśli to możliwe - po co logować się dwa razy?
2) Nie ma „braku możliwości sprawdzenia daty w późniejszym terminie”, więcej poniżej.
3) Jest to opcja, ale to, czy jest użyteczna, zależy od tego, jak długo chcesz przechowywać dane i ile czyszczenia chcesz zapisać. Więcej poniżej.
4) MongoDB z pewnością może działać. Będziesz musiał napisać zapytania i nie są to proste polecenia SQL.
Teraz do przechowywania danych w redis. Obecnie loguję rzeczy za pomocą syslog-ng, jak wspomniano, i używam miejsca docelowego programu do analizowania danych i umieszczania ich w Redis. W moim przypadku mam kilka kryteriów grupowania, takich jak vhost i klaster, więc moje struktury mogą być nieco inne. Pytanie, które musisz najpierw rozwiązać, brzmi „jakich danych chcę z tych danych”? Niektóre z nich będą licznikami, takimi jak stawki ruchu. Niektóre z nich będą zbiorcze, a jeszcze więcej będą takie, jak „uporządkuj moje strony według popularności”.
Zademonstruję niektóre techniki, aby łatwo wprowadzić to do redis (a tym samym się wycofać).
Najpierw rozważmy statystyki ruchu w czasie. Najpierw zdecyduj o szczegółowości. Chcesz statystyki na minutę, czy wystarczą statystyki na godzinę? Oto jeden ze sposobów śledzenia ruchu danego adresu URL:
Przechowuj dane w posortowanym zestawie, używając klucza „traffic-by-url:URL:RRRR-MM-DD” w tym posortowanym zestawie użyjesz polecenia zinrby i podasz element „GG:MM”. na przykład w Pythonie, gdzie "r" jest twoim połączeniem redis:
r.zincrby("traffic-by-url:/foo.html:2011-05-18", "01:04",1)
Ten przykład zwiększa licznik dla adresu url "/foo.html" 18 maja o godzinie 1:04 rano.
Aby pobrać dane na konkretny dzień, możesz zadzwonić zrange na klucz (""traffic-by-url:URL:RRRR-MM-DD"), aby uzyskać posortowany zestaw od najmniej popularnego do najbardziej popularnego. Aby uzyskać top 10 , na przykład użyjesz zrevrange i nadasz mu zakres.Zrevrange zwraca odwrotne sortowanie, najwięcej trafień będzie na górze.Dostępnych jest kilka innych posortowanych poleceń zestawu, które pozwalają wykonywać ładne zapytania, takie jak paginacja, uzyskać zakres wyników według minimalnego wyniku itp.
Możesz po prostu zmienić lub rozszerzyć nazwę klucza, aby obsługiwała różne okna czasowe. Łącząc to z zunionstore, możesz automatycznie wyświetlać mniej szczegółowe okresy. Na przykład możesz połączyć wszystkie klucze w ciągu tygodnia lub miesiąca i zapisać w nowym kluczu, takim jak „ruch-według-url:monthly:URL:RRRR-MM”. Wykonując powyższe na wszystkich adresach URL w danym dniu, możesz uzyskać codziennie. Oczywiście możesz również mieć dzienny klucz całkowitego ruchu i go zwiększać. Zależy to głównie od tego, kiedy chcesz wprowadzić dane - offline przez import pliku dziennika lub jako część doświadczenia użytkownika.
Odradzałbym robienie wielu rzeczy podczas rzeczywistej sesji użytkownika, ponieważ wydłuża to czas potrzebny użytkownikom na to (i obciążenie serwera). Ostatecznie będzie to połączenie oparte na poziomie ruchu i zasobach.
Jak możesz sobie wyobrazić, powyższy schemat przechowywania można zastosować do dowolnej statystyki opartej na liczniku, którą chcesz lub określisz. Na przykład zmień adres URL na identyfikator użytkownika i masz śledzenie na użytkownika.
Możesz także przechowywać surowe dzienniki w Redis. Robię to dla niektórych dzienników przechowujących je jako ciągi JSON (mam je jako pary klucz-wartość). Potem mam drugi proces, który wyciąga je i robi pewne rzeczy z danymi.
Do przechowywania surowych hitów możesz również użyć posortowanych zestawów, używając czasu epoki jako rangi i łatwo przechwycić okno czasowe za pomocą poleceń zrange/zrevrange. Lub przechowuj je w kluczu opartym na identyfikatorze użytkownika. Zestawy sprawdziłyby się w tym przypadku, podobnie jak posortowane zestawy.
Inną opcją, o której nie mówiłem, ale dla niektórych danych może być przydatna, jest przechowywanie jako hash. Może to być przydatne na przykład do przechowywania szczegółowych informacji o danej sesji.
Jeśli naprawdę chcesz mieć dane w bazie danych, spróbuj użyć funkcji Pub/Sub Redis i poproś subskrybenta, który przeanalizuje je w formacie rozdzielanym i zrzuci do pliku. Następnie wykonaj proces importowania, który używa polecenia kopiowania (lub odpowiednika dla Twojej bazy danych) do importu zbiorczego. Twój DB ci podziękuje.
Ostatnia rada tutaj (prawdopodobnie poświęciłem już wystarczająco dużo czasu mentalnego) jest rozsądne i liberalne użycie polecenia wygaśnięcia. Używając Redis 2.2 lub nowszego, możesz ustawić wygaśnięcie na parzystych klawiszach licznika. Dużą zaletą jest tutaj automatyczne czyszczenie danych. Wyobraź sobie, że postępujesz według schematu opisanego powyżej. Używając poleceń wygaśnięcia, możesz automatycznie usuwać stare dane. Być może potrzebujesz statystyk godzinowych przez okres do 3 miesięcy, a potem tylko statystyk dziennych; statystyki dzienne przez 6 miesięcy, a następnie tylko statystyki miesięczne. Po prostu wygaś swoje klucze godzinowe po trzech miesiącach (86400*90), codziennie o 6 (86400*180) i nie będziesz musiał wykonywać czyszczenia.
W przypadku geotagowania wykonuję przetwarzanie adresu IP w trybie offline. Wyobraź sobie posortowany zestaw z następującą strukturą klucza:„traffic-by-ip:RRRR-MM-DD”, używając adresu IP jako elementu i używając polecenia cynkuryby, o którym mowa powyżej, otrzymujesz dane o ruchu dla poszczególnych adresów IP. Teraz w swoim raporcie możesz uzyskać posortowany zestaw i wyszukać adres IP. Aby zaoszczędzić ruch podczas tworzenia raportów, możesz ustawić skrót w redis, który mapuje adres IP na żądaną lokalizację. Na przykład „geo:country” jako klucz i adres IP jako element mieszający z kodem kraju jako przechowywaną wartością.
Dużym zastrzeżeniem, które chciałbym dodać, jest to, że jeśli poziom ruchu jest bardzo wysoki, możesz chcieć uruchomić dwie instancje Redis (lub więcej, w zależności od ruchu). Pierwsza byłaby instancją zapisu, nie miałaby włączonej opcji bgsave. Jeśli ruch jest dość wysoki, zawsze będziesz robił bgsave. Właśnie za to polecam drugą instancję. Jest niewolnikiem pierwszego i robi sejwy na dysk. Możesz również uruchamiać swoje zapytania względem urządzenia podrzędnego, aby rozłożyć obciążenie.
Mam nadzieję, że to da Ci kilka pomysłów i rzeczy do wypróbowania. Pobaw się różnymi opcjami, aby zobaczyć, które najlepiej odpowiadają Twoim potrzebom. Śledzę wiele statystyk na stronie o dużym natężeniu ruchu (a także statystyki dzienników MTA) w redis i działa to pięknie - w połączeniu z Django i Google Visualization API otrzymuję bardzo ładnie wyglądające wykresy.
