Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > PHP: Общие вопросы > Проектирование системы статистики |
Автор: Alix36 5.10.2012, 08:06 |
Задумался о том, как правильно логировать действия пользователей. Данные бывают трех типов 1) Уникальные для пользователя(каждый пользователь может сгенерить такое событие только 1 раз. (Регистрация, первый платеж) 2) Уникальные для пользователя и объекта(Каждый пользователь может сгенерить такое событие только 1 раз по отношению к одному и тому-же объекту. (Например - записываем дату первого посещения каждой из страниц проекта) 3) Не уникальное. (Регулярные события, типа повторных посещений страниц). Конечно можно не заморачиваться с этими ограничениями в момент записи логов, записывая все события как не уникальные, однако в таком случае мы не сможем сделать реалтайм отчеты по данным, поскольку обработка может занять довольно большое время. Если же будем добиваться уникальности - делаем таблицу в которую пишем Time, ObjectID, UserID, ActionID, UniKey. Делаем уникальный индекс по UniKey и пишем туда хэш от 2-3-4 параметров, в зависимости от "режима уникальности" Собственно вопрос 1: Допускается ли запись логов в базу? Вопрос 2: Можно ли писать в таблицу с индексом? не будет ли это слишком сильно тормозить? Вопрос 3: Какие альтернативные структуры возможны для поставленной задачи? |
Автор: mark2009 5.10.2012, 09:57 | ||
Я бы сделал так:
таким образом у вас в основной таблице будут один цифры и слишком большой нагрузки создаваться не будет. А по вопросам: 1. Да, допускается. 2. А какая нафиг разница, есть у таблицы индекс или нет?? Индексы предназначены для ускорения операций поиска.... 3. Альтернативную? NoSQL ))))))) |
Автор: Alix36 5.10.2012, 11:30 | ||||||||
мм... а можно комменты к коду? Что в первой таблице? тупо справочник или уник-кей? Во 2ой таблице что предполагалось сделать с `log_action_id`? Разве какая-то бд умеет 2 автоинкремента в одной таблице?
2) Огромная. при больших индексах и большом кол-ве записей начинает тормозить добавление. А у нас наибольшую производительность нужно показать как раз на операциях добавления записей. 3) Ну с пеленок как-бы учили файлы для логов использовать. только как тут контролировать уникальность.... NoSQL знаком только с mongoDB и она не сильна на запись по скорости... пока у меня так выглядит основная таблица.
Таблица с объектами
работаем с этим так
|
Автор: ksnk 5.10.2012, 11:36 |
Для нагруженного проекта могут быть такие соображения: -- логирование действий - не очень нужное в повседневном быту действие, оно нужно только администратору в каких-то аварийных случаях. -- само логирование - напряженный и расходный процесс, так что ускорить его максимально - жизненно необходимо. Так что лог создается в таблице без индексов. Индексируется, возможно, только поле даты, хотя это нужно отдельно проверять. в самой системе есть такие задачи -- запись строчки лога -- автомаическая чистка лога для записей старше (к примеру) недели. в админке (части, расположенной на сервере) системы есть задачи -- удаление строчек, до какой-то даты -- сброс (download) дампа таблицы. После успешной загрузки дампа на компьютер администратора лог, скорее всего чистится. На администраторской машине это дамп вставляется в таблицу с индексами и не нагружая сервер анализируется. |
Автор: Alix36 5.10.2012, 11:43 | ||
тут скорее менеджерские логи, посему и появляются сложные условия...
Ну тогда проще на проде писать файлы с логами, рваные по минутам. На машине-хранилище раз в минуту -стягиваем свежие логи с прода, их парсим, обрабатываем и заливаем в полноценную бд с индексами. |
Автор: mark2009 5.10.2012, 12:26 |
Alix36, В первой таблице справочник того, что вообще можно делать. Вторая таблица логов. Извините, описался (ударение на 3 слог).... конечно нет 2 автоинкрементных поля. Почему у вас в таблице tThreshold нет primary key - непонятно вообще. Из каких соображений? Экономить сотые доли секунды? ![]() В третьем вопросе ТС я просто шутил ))) естественно, какие в наше время альтернативные методы лога кроме БД? Файл??! Ну так.... 1000000 пользователей и файл охрененного размера.... разве непонятно? А мой пост скорее всего следствие желания всё и вся нормализовать, поскольку именно этому упорно учат в универе ![]() |
Автор: Alix36 5.10.2012, 13:10 | ||
меня тоже упорно учат... файл рвем раз в минуту и получаем файл маленького размера, хоть каждый запрос в свой файл пиши.
Есть по полю UniKey |
Автор: Sanchezzz 5.10.2012, 18:59 |
Вам нужно искать решение которое не будет тормозить всю систему Все логи вставлять как INSERT DELAYED если будите использовать Mysql, Sqlite ( придется отключить системное легирование еще увеличит скороть работы вставки упдейта ) ksnk, написали выше отличный план реализации системы. |