Určitě je to proveditelné různými metodami. Budu se zabývat každou uvedenou možností a také nějakým dalším komentářem.
1) Pokud to NGinx umí, nechte to. Dělám to s Apache stejně jako JBOSS a Tomcat. Poté je pomocí syslog-ng centrálně shromáždím a zpracuji odtud. Pro tuto cestu bych navrhoval formát zpráv s oddělovači, jako je například oddělený tabulátory, protože usnadňuje analýzu a čtení. Nevím o protokolování proměnných PHP, ale určitě může protokolovat hlavičky a informace o souborech cookie. Pokud vůbec budete používat protokolování NGinx, doporučil bych pokud možno tuto cestu – proč se protokolovat dvakrát?
2) Neexistuje žádná "nedostatečná možnost dotazu na datum později", více níže.
3) Toto je možnost, ale zda je nebo není užitečná, závisí na tom, jak dlouho chcete data uchovat a kolik vyčištění chcete zapsat. Více níže.
4) MongoDB by jistě mohl fungovat. Budete muset napsat dotazy a nejsou to jednoduché příkazy SQL.
Nyní k ukládání dat v redis. V současné době protokoluji věci pomocí syslog-ng, jak je uvedeno, a používám cíl programu k analýze dat a jejich uložení do Redis. V mém případě mám několik kritérií pro seskupování, například podle vhost a podle clusteru, takže moje struktury mohou být trochu odlišné. Otázka, kterou musíte nejprve vyřešit, je „jaká data z těchto dat chci“? Část z toho budou čítače, jako jsou dopravní sazby. Něco z toho budou agregáty a ještě více to budou věci jako „seřadit mé stránky podle oblíbenosti“.
Předvedu některé techniky, jak to snadno dostat do redis (a tedy zpět).
Nejprve se podívejme na statistiky návštěvnosti v průběhu času. Nejprve se rozhodněte o granularitě. Chcete statistiky za minutu nebo budou stačit statistiky za hodinu? Zde je jeden způsob, jak sledovat provoz dané adresy URL:
Uložte data do seřazené sady pomocí klíče "traffic-by-url:URL:YYYY-MM-DD" v této tříděné sadě použijete příkaz zincrby a dodáte člen "HH:MM". například v Pythonu, kde "r" je vaše připojení redis:
r.zincrby("traffic-by-url:/foo.html:2011-05-18", "01:04",1)
Tento příklad zvyšuje počítadlo pro adresu URL "/foo.html" 18. května v 1:04 ráno.
Chcete-li načíst data pro konkrétní den, můžete zavolat zrange na klíč (""traffic-by-url:URL:YYYY-MM-DD") a získat seřazenou sadu od nejméně oblíbených po nejoblíbenější. Chcete-li získat 10 nejlepších , například byste použili zrvrange a přiřadili mu rozsah. Zrevrange vrátí zpětné řazení, nejvíce zásahů bude nahoře. K dispozici je několik dalších seřazených příkazů sady, které vám umožní provádět pěkné dotazy, jako je stránkování, získat rozsah výsledků podle minimálního skóre atd..
Název klíče můžete jednoduše změnit nebo rozšířit tak, aby zpracovával různá časová okna. Když to zkombinujete se zunionstore, můžete automaticky shrnout méně podrobná časová období. Můžete například provést sjednocení všech klíčů za týden nebo měsíc a uložit je do nového klíče, jako je „traffic-by-url:monthly:URL:YYYY-MM“. Provedením výše uvedeného na všech adresách URL v daný den můžete získat denně. Samozřejmě můžete mít také klíč celkové návštěvnosti za den a zvýšit jej. Většinou záleží na tom, kdy chcete data zadávat – offline prostřednictvím importu souboru protokolu nebo jako součást uživatelské zkušenosti.
Nedoporučoval bych dělat mnoho během skutečné uživatelské relace, protože to prodlužuje dobu, kterou vaši uživatelé zažijí (a zatížení serveru). Nakonec to bude volání založené na úrovních provozu a zdrojích.
Jak si dokážete představit, výše uvedené schéma úložiště lze použít na jakoukoli statistiku založenou na čítači, kterou chcete nebo kterou určíte. Například změňte URL na userID a budete mít sledování podle jednotlivých uživatelů.
Logy můžete také ukládat raw v Redis. Dělám to pro některé protokoly, které je ukládají jako řetězce JSON (mám je jako páry klíč-hodnota). Pak mám druhý proces, který je vytáhne a udělá věci s daty.
Pro ukládání nezpracovaných zásahů můžete také použít seřazené sady s použitím Epoch Time jako hodnosti a snadno uchopit časové okno pomocí příkazů zrange/zrevrange. Nebo je uložte do klíče, který je založen na ID uživatele. Na to by fungovaly sady, stejně jako tříděné sady.
Další možností, o které jsem nemluvil, ale pro některá vaše data může být užitečná, je uložení jako hash. To může být užitečné například pro ukládání podrobných informací o dané relaci.
Pokud opravdu chcete data v databázi, zkuste použít funkci Pub/Sub Redis a mít předplatitele, který je analyzuje do formátu s oddělovači a vypíše do souboru. Poté zaveďte proces importu, který k hromadnému importu používá příkaz copy (nebo ekvivalent pro vaši databázi). Vaše DB vám poděkuje.
Poslední malou radou (pravděpodobně jsem si už dal dost času v duchu) je, abyste příkaz expire používali uvážlivě a liberálně. Pomocí Redis 2.2 nebo novějšího můžete nastavit expiraci na sudých klíčích počítadla. Velkou výhodou je zde automatické čištění dat. Představte si, že postupujete podle schématu, které jsem nastínil výše. Pomocí příkazů pro vypršení platnosti můžete automaticky vymazat stará data. Možná chcete hodinové statistiky po dobu až 3 měsíců, pak pouze denní statistiky; denní statistiky za 6 měsíců, poté pouze měsíční statistiky. Jednoduše vyprší platnost vašich hodinových klíčů po třech měsících (86400*90), denně v 6 (86400*180) a nebudete muset provádět čištění.
Pro geotagging provádím offline zpracování IP. Představte si setříděnou sadu s touto klíčovou strukturou:„traffic-by-ip:YYYY-MM-DD“ s použitím IP jako prvku a pomocí výše uvedeného příkazu zincryby získáte data o provozu na IP. Nyní můžete ve své zprávě získat seřazenou sadu a vyhledávat IP. Chcete-li ušetřit provoz při vytváření přehledů, můžete v redis nastavit hash, který mapuje IP na požadované místo. Například „geo:country“ jako klíč a IP jako člen hash s kódem země jako uloženou hodnotou.
Velkou výhradu, kterou bych dodal, je, že pokud je vaše úroveň provozu velmi vysoká, možná budete chtít spustit dvě instance Redis (nebo více v závislosti na provozu). První by byla instance zápisu, neměla by povolenou volbu bgsave. Pokud je váš provoz dost vysoký, vždy budete provádět bgsave. K tomu doporučuji druhou instanci. Je otrokem prvního a ukládá na disk. Můžete také spustit své dotazy proti slave, abyste rozložili zátěž.
Doufám, že vám to dá nějaké nápady a věci k vyzkoušení. Pohrajte si s různými možnostmi, abyste viděli, co nejlépe vyhovuje vašim konkrétním potřebám. Sleduji spoustu statistik na webu s vysokou návštěvností (a také statistiky MTA log stats) v redis a funguje to krásně - v kombinaci s Django a Google Visualization API dostávám velmi pěkně vypadající grafy.