3 года назад

База данных для счётчика хостов

Пишу небольшой сервис (пока для личного пользования), суть которого состоит в возможности подсчёта просмотров (да, картинкою, как top.(mail|amble|etc)), встраиваться это будет во блоги, подписи/посты в форумы, разные сообщества и комментарии. Раздумываю над способом хранения визитов, для последующего определения уникальности хоста/посетителя. Что лучше использовать: RDBMS (PostgeSQL), NoSQL (mogo), Plai text? Счётчиков может быть великое множество (от нескольких тысяч), количество просмотров на один от одного в сутки до, вероятно, 4-5 в секунду.Напоминаю, задача БД - определить уникальность хоста/посетителя для конкретного счётчика. Для хранения значений каждого отдельного счётчика выбрал i-memoy DB с возможностью сохранения снапшотов на диск.
idex0h, да примерно так и делаю (про edis, но пока переносить данные в sql/osql не думал), но вы меня немного не поняли.> Напоминаю, задача БД - определить уникальность хоста/посетителя для конкретного счётчика. Переформулирую вопрос: при каждом уникальном запросе в базу будет добавляться запись вида coute_id:IP. Поскольку нужно вычислить уникальность хоста/посетителя за всё время существования счётчика (очистка базы отпадает), то таких записей может накопиться по несколько тысяч на один счётчик, что может (ох, как я на это надеюсь) означать, что записей будут миллионы. Вопрос: смогут ли справиться реляционные технологии с такой задачей? Опыта у меня в этом нет (если не считать написание простых бложиков да другой ереси), потому и интересуюсь, может подскажет кто.P.S.: поскольку мне не нужны, в данном случае (логи, по сути), реляционные технологии, то чашу, пока что, переклоняют osql db. Сейчас читаю маны и активно гуглю. Посмотрим, что получится.
Тоска. Я им об арахисе, а они мне о малине. Я не спрашивал, каким образом идентифицировать уникальность хоста/посетителя (видите, везде пишу "хоста/посетителя", значит, понимаю, что это разные понятия) или как рисовать картинку. Я спрашиваю, есть ли смысл хранить логи, используя релиционную СУБД, NoSQL решение или обычные текстовые файлы.В любом случае, спасибо за ответы и потраченное время.P.S.: конкретной цели нет, главное - получить некий опыт.

RyuusukE (Гость) Статистика
3

Статистика: База данных для счётчика хостов

9 месяцев назад вопрос по счётчикам на сайтах

Мудрые гугловоды!На некоторых сайтах внизу страничек установлены счётчики лайвинетрнета с тремя рядами цирф.на сайте есть ещё счётчик Splog, но он тоже статистики не даёт. Поскольку статистика "доступна по паролю", а больше данные о сайте взять неоткуда. подскажите, как эти цифры понимать.Спасибо отписавшимся!

Mariqa (Гость) Нет ответов
3
Ответы (3)
r o f f o (Гость) 3 года назад
3

1) Считать IP - это все равно что считать красные машины и не замечать зеленые. Есть много случаев, когда с одного IP приходят разные посетители. Есть много случаев когда один посетитель приходит с разных IP. Есть простое решение проблемы - генерировать случайное число и сохранять его в куках браузера. Тогда отслеживаться будет конкретный браузер, независимо с какого IP он пришел.
2) Реляционные технологии справятся и с десятками миллионов записей. Вопрос справится ли хостинг? Какая нагрузка будет на сервер? Стоит ли красивая картинка около записи лишних 100$ в месяц на хостинг?
3) Какова цель этих подсчетов? Если красивая картинка - то ответ выше, Если знать действительную посещаемость и статистику, то для этого существуют другие приемы.

Пожаловаться
AnHel (Гость) 3 года назад
3

я бы на вашем месте сделал следующее:
Если поток пользователей большой количество сначала кэшировал в redis, дальше передавал данные в MySQL, или в PostgreSQL. При этом ночью в период минимальной активности генерировал изображения счетчика на приблизительную активность на следующий день. Т.е. например в день 1к пользователей:
имеем в redis текущее количество просмотров, 1 раз в час синхронизируем это значение с MySQL, ночью генерируем 1к изображений на перед и дальше при каждом заходе отображаем изображение со смещением в redis на перед. Сами изображения рекомендую хранить в файловой системе, потому что тот же gridfs (mongo) будет жрать лишние ресурсы, хотя смысла в этом мало (данные быстро устаревают и нет необходимости их просто так хранить)

Если ресурсов сервера не будет хватать на генерацию изображений на день вперед - разбейте этот процесс на несколько итераций. Дело в том, что если этого не делать при большом количестве параллельных запросов ваш сервер может не потянуть нагрузки, а если просто отдавать уже готовую статику, проблем быть не должно.

Пожаловаться
Анастасия Голосевич (Гость) 3 года назад
3

Полностью уникальность юзверя определить увы нереально, так как данные отправляет пользователь, а он может врать)). Можно конечно в кукисы прописать хэш: ip+soult. А дальше, если он еще раз зашел - проверят этот хеш: хэш правильный - не уник., неправильный - уник. Обращаю внимание для каждого уникального запроса добавлять свой хэш.

В redis создаешь тоже хэш:
counter[ip] \u003d [count]

Пожаловаться
База данных для счётчика хостов (Статистика) - вопросы и ответы на все случаи жизни - справочник Статистика i-vopros.ru