Стоит задача посчитать статистику сайта. Нужно знать сколько человек на какой странице были. Желательно учитывать уникальность клиента. Как это лучше сделать?
Ограничения:
нельзя использовать сторонние сервисы;
сайт работает на одной машине (не кластер).
Реалии.
1) 50 000 уникальных посетителей в день;
2) MySql :( {требование руководства}.
3) При попытке собрать статистику за день после трех дней работы база висит.
Варианты:
1) Есть вариант вести отдельно статистику за текущий день (создавать новую табличку, базу), но это не решает проблему. (Умный гору подорвет.)
2) Есть вариант "ф топку MySql" и попробовать Postgres. Но боюсь, что вернемся все равно к 1.
3)* Мне самому почему-то кажется, что имеет смысл смотреть в сторону NoSql (Redis, например). Но обосновать свое мировоззрение я не могу.
4)** Написать свой модуль на чистых сях, с прямой записью на диск. Использовать Б-дерево. И в итоге написать собственную БД под свою задачу.
4)*** Свой вариант.
Кто-то сталкивался с проблемой?
Материал для размышления
http://stackoverflow.com/questions/2510627/is-nosql-ideal-to-store-stats
http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analy...
О_О Скрипт покажи! Ты там что-то неправильно делаешь. 50К уников для дедика должно быть не много. Может БД не настроена?
А смысл в этом решении? 50К уников * 10 страниц/уник = 500К записей. И это максимум.
Так и будет.
Не вижу смысла. В данной задаче нет никаких оснований уходить от парадигмы Sql, т.к. нигде не натыкаемся на её ограничения.
Долго и бессмысленно.
Во-первых, я бы тоже усомнился, что скрипт оптимизирован. 50 тыс уников — это, конечно, солидно, но для дедика вполне по силам. Например, в Друпале используются очень тяжелые конструкции для обработки статистики, с соединениями, но ничего не падает. Я бы первым делом поковырял бы логи MySQL на предмет медленных запросов, потом подкрутить скрипт, потом можно поэкспериментировать с настройками.
Во-вторых, можно обрабатывать статистику не за день, а за небольшой промежуток, например, за несколько часов и промежуточные запросы хранить в отдельных таблицах. Что-то типа кэширования.
В-третьих, а зачем вообще использовать MySQL? Можно напрямую обрабатывать апачевские логи. Есть даже готовые решения вроде Вебалайзера и т.п.
Решение с NoSQL интересное, но интересно оно именно в плане экспериментаторства. Не знаю насколько для этого подходит ресурс с 50к униками. :)
Спасибо,
> MySQL
Требование начальства. Не очень, правда, понимаю пока чем обосновано.
На тему вебалайзера --- опят же от нас хотят велосипедное решение. Все равно, потом что-то придется модифицировать, и прикручивать свое. С вебалайзером это будет сложнее.
---
А вот на тему оптимальности скрипта, я бы действительно, подумал.
А чем сложнее? Это ж СПО.
Втыкать в чужой код сложнее, чем в свой.
По Вебалайзеру:
Самое страшное ограничение, в том что проблемой занимаюсь не я. Хотя, очень хочется. Начинаю подозревать, что не до конца саму проблему понял. Возможно, привел заниженные численные данные. Во общем отпишусь, когда что-то прояснится.
В оптимальности скрипта сомнения минимальные.
Запустите профилирование. Узнайте в чем именно "бутылочное горлышко". По отношению к MySQL только один раз заметил неладное — получилась глупая ненужная рекурсия, которую можно было на несколько порядков оптимизировать.
В общем, запускайте профилирование. :)
Отправить комментарий