Със сигурност е изпълнимо по различни методи. Ще разгледам всяка изброена опция, както и някои допълнителни коментари.
1) Ако NGinx може да го направи, оставете го. Правя го с Apache, както и с JBOSS и Tomcat. След това използвам syslog-ng, за да ги събирам централно и да обработвам от там. За този маршрут бих предложил формат на съобщение в дневника с разделители, като разделен с табулатори, тъй като улеснява анализирането и четенето. Не знам за регистрирането на PHP променливи, но със сигурност може да регистрира заглавки и информация за бисквитки. Ако изобщо ще използвате регистриране на NGinx, бих препоръчал този маршрут, ако е възможно - защо да влизате два пъти?
2) Няма „липса на възможност за запитване на датата на по-късна дата“, повече по-долу.
3) Това е опция, но дали е полезна или не зависи от това колко дълго искате да запазите данните и колко изчистване искате да напишете. Повече по-долу.
4) MongoDB със сигурност може да работи. Ще трябва да напишете заявките, а те не са прости SQL команди.
Сега, за съхраняване на данните в redis. В момента записвам нещата с syslog-ng, както е отбелязано и използвам дестинация на програмата, за да анализирам данните и да ги напълня в Redis. В моя случай имам няколко критерия за групиране, като например по vhost и по клъстер, така че моите структури може да са малко по-различни. Въпросът, който първо трябва да адресирате, е „какви данни искам от тези данни“? Част от тях ще бъдат броячи, като например трафик. Част от тях ще бъдат обобщени, а още повече ще са неща като „подредете страниците ми по популярност“.
Ще демонстрирам някои от техниките за лесно въвеждане на това в redis (и по този начин обратно).
Първо, нека разгледаме статистическите данни за трафика във времето. Първо решете детайлността. Искате ли статистики за минута или ще са достатъчни статистики за час? Ето един начин за проследяване на трафика на даден URL адрес:
Съхранявайте данните в сортиран набор, като използвате ключа "traffic-by-url:URL:YYYY-MM-DD" в този сортиран набор ще използвате командата zincrby и ще предоставите члена "HH:MM". например в Python, където "r" е вашата redis връзка:
r.zincrby("traffic-by-url:/foo.html:2011-05-18", "01:04",1)
Този пример увеличава брояча за URL адреса „/foo.html“ на 18 май в 1:04 сутринта.
За да извлечете данни за конкретен ден, можете да извикате zrange на ключа (""traffic-by-url:URL:YYYY-MM-DD"), за да получите сортиран набор от най-малко популярни до най-популярни. За да получите първите 10 , например, ще използвате zrevrange и ще му дадете диапазона. Zrevrange връща обратно сортиране, най-много ударен ще бъде в горната част. Налични са още няколко команди за сортиран набор, които ви позволяват да правите хубави заявки, като например пагинация, да получите диапазон от резултати по минимален резултат и т.н..
Можете просто да промените или разширите името на вашия ключ, за да обработвате различни времеви прозорци. Като комбинирате това с zunionstore, можете автоматично да разширите до по-малко детайлни периоди от време. Например можете да направите обединение на всички ключове за седмица или месец и да съхранявате в нов ключ като "traffic-by-url:monthly:URL:YYYY-MM". Като направите горното за всички URL адреси в даден ден, можете да получавате ежедневно. Разбира се, можете също да имате дневен ключ за общ трафик и да го увеличите. Най-вече зависи от това кога искате данните да бъдат въведени – офлайн чрез импортиране на лог файл или като част от потребителското изживяване.
Бих препоръчал да не правите много по време на действителната потребителска сесия, тъй като това удължава времето, необходимо на вашите потребители да го изпитат (и натоварването на сървъра). В крайна сметка това ще бъде обаждане въз основа на нивата на трафик и ресурси.
Както можете да си представите, горната схема за съхранение може да бъде приложена към всяка базирана на брояч статистика, която искате или определите. Например променете URL адреса на userID и ще имате проследяване на всеки потребител.
Можете също да съхранявате дневници необработени в Redis. Правя това за някои регистрационни файлове, които ги съхраняват като JSON низове (имам ги като двойки ключ-стойност). След това имам втори процес, който ги изтегля и прави неща с данните.
За съхраняване на необработени попадения можете също да използвате сортирани набори, използвайки Epoch Time като ранг и лесно да вземете времеви прозорец с помощта на командите zrange/zrevrange. Или ги съхранявайте в ключ, който се основава на потребителския идентификатор. Наборите биха работили за това, както и сортираните набори.
Друг вариант, който не съм обсъждал, но за някои от вашите данни може да бъде полезен, е съхраняването като хеш. Това може да бъде полезно за съхраняване на подробна информация за дадена сесия например.
Ако наистина искате данните в база данни, опитайте да използвате функцията Pub/Sub на Redis и имайте абонат, който ги анализира в разделен формат и изхвърля във файл. След това направете процес на импортиране, който използва командата за копиране (или еквивалентна за вашата БД) за импортиране на едро. Вашият DB ще ви благодари.
Последният съвет тук (вероятно вече съм отделил достатъчно умствено време) е да използвате разумно и либерално командата expire. Използвайки Redis 2.2 или по-нова версия, можете да зададете изтичане на четни клавиши за брояч. Голямото предимство тук е автоматичното почистване на данните. Представете си, че следвате схема, както очертах по-горе. С помощта на командите за изтичане можете автоматично да изчистите старите данни. Може би искате почасова статистика за до 3 месеца, а след това само дневна статистика; дневна статистика за 6 месеца, след това само месечна статистика. Просто изтечете валидността на вашите почасови ключове след три месеца (86400*90), дневните в 6 (86400*180) и няма да е необходимо да извършвате почистване.
За геомаркиране правя офлайн обработка на IP. Представете си сортиран набор с тази ключова структура:"traffic-by-ip:YYYY-MM-DD", като използвате IP като елемент и с помощта на командата zincryby, отбелязана по-горе, получавате данни за трафик по IP. Сега, във вашия отчет, можете да получите сортирания набор и да направите справки на IP. За да спестите трафик при изготвянето на отчетите, можете да настроите хеш в redis, който съпоставя IP адреса с местоположението, което искате. Например „geo:country“ като ключ и IP като хеш член с код на държавата като съхранена стойност.
Голямо предупреждение, което бих добавил, е, че ако нивото на трафика ви е много високо, може да искате да стартирате две копия на Redis (или повече в зависимост от трафика). Първият би бил екземплярът за запис, няма да има активирана опцията bgsave. Ако трафикът ви е доста висок, винаги ще правите bgsave. За това препоръчвам втората инстанция. Той е роб на първия и записва на диск. Можете също да изпълнявате заявките си срещу подчинения, за да разпределите натоварването.
Надявам се това да ви даде някои идеи и неща, които да опитате. Играйте с различните опции, за да видите кое работи най-добре за вашите специфични нужди. Проследявам много статистически данни на уебсайт с голям трафик (а също и MTA регистрационни данни) в redis и се представя прекрасно - в комбинация с Django и API на Google за визуализация получавам много добре изглеждащи графики.
