логин: 
<< предыдущая заметкаследующая заметка >>
15 февраля 2011
Нужен совет. Изучал статистику, много думал.

Медленно, но верно я борюсь со структурами, продвигая движок к многопользовательскому режиму и рождению Биноника. Сегодня собрал трансферилку старых баз unic в новую, экономичную.

Но вот случайно кинул взгляд, и офигел: оказывается, вовсе не unic жрет основные ресурсы, а вот эта дивная таблица dnevnik_posetil:

Таблица эта фиксирует посещения: некий посетитель unic (int 20) посещает некую страницу сайта url (int 10). Время посещения записывается в data, повторные посещения, если есть, не записываются никак — представляет интерес лишь уникальное посещение. Такая у нас система. Потом по ней вычисляется число посетителей или даже поименная конкретика.

Индекс ключа я строил по двум сразу: unic+url. Потом еще добавил отдельный ключ url, чтобы выбирать по нему всех посетивших страницу для показа подробной статистики. Индекс unic я добавил только что — просто, чтобы понять их число.

Но блин, база немеряная! Это накопилось за год (с 03.02.2010). Что посоветуете? Варианты:

1. Ничего страшного, копейки на самом-то деле.

2. Надо поколдовать с индексами, оптимизировать таблицу.

3. Надо по крону чистить таблицу: удалять записи о посещениях безымянных unic старше месяца, а у каждой страницы завести отдельный счетчик, в который прибавлять количество удаленных из таблицы посещений. Сумма этого счетчика и числа посетителей, взятого из таблицы, и будет реальным числом посещений.

4. Другое.


PS: Зато теперь, кстати, я знаю, что за год мой дневник (все страницы) посещает 5.5 млн человек, не считая роботов, людей с отключенными куками и тех, кто зашел в мой дневник первый раз (учитываются лишь те посетители, кто предъявляет при заходе свою номерную куку). То есть 15000 человек в сутки, 450 тыс в месяц. Это плохо, мне много. Надо их как-то разгонять и отваживать.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
Страницы, которые привлекли мое внимание за последние дни, рекомендую:
2017-11-22 В июне 1982
архив ссылок
Оставить комментарий
[грустно]

А может, всё же не надо?.. О_О
Linux Firefox
 Москва
0
0
Что не надо?
Windows Firefox
1
0
Не надо разгонять и отваживать
Windows Firefox
0
0
Ага, именно разгонять и отваживать... :o|

Эх,вот теперь сиди и фильтруй несколько недель инфу... :)
Windows Firefox
0
0
Уф, после отправки коммента в огнелисе задумался: система поставида его выше по столбику, чем коммент от АММО.

Правда, после перегрузки страницы (F5 т.е.) все стало логично.

Конечно, это всё не страшно, но вдруг по каким-то причинам важно?
Windows Safari Chrome
0
0
Sling (#627706)
Ну, для баз с большим количеством данных нормальная практика периодически сбрасывать данные в сводную таблицу со статистикой.
А в целом, пока записей меньше чем 10-100 млн вопросы производительности без проблем решаются индексами (да и если больше вобщемто тоже, хотя всё зависит от конкретного случая). Так что чистить по-моему имеет смысл только если очень уж хочеться уменьшить размер базы.
Я бы на вашем месте оставил как есть.
Windows Firefox
0
0
1) "Ничего страшного, копейки на самом-то деле." Да уж, для платного хостинга с ограничением места на сервере - кошмарные цифры. :(

4) Нужен ли вообще учет безымянных? Ну зашли, отметились лишней единичкой на счетчике просмотра странички, ушли себе. Зачем их в базу-то?
Linux Firefox
 Москва
0
0
Учет нужен, потому что без этого они зайдут снова, снова и снова - сколько раз зайдут, столько счетчик и накрутят.
Windows Opera
0
0
Вип (#402199)
ну и пусть куки это помнят
Linux Firefox
 Москва
0
0
1000 посещенных страниц дневника? При проектировании системы надо очень четко понимать, где информация серверная, а где пользовательская.
Windows
1
0
lesha (#406942)
...минус некоторые, которые ходят с разных компов/мобилок под разными unic потому что пароль вспомнить не могут ;) ну или не хотят регистрироваться.

А зачем bigint для unic? Если сделать INT UNSIGNED то это от 0 до 4.294.967.295. Разве мало?

А вот unixtime переполнится в 2038м году вроде. Хотя еще далеко до этого.

Для отдельно стоящего блога - можно оставить как есть. Для многопользовательского - настройки в конфиге как часто суммировать данные. Это будет максимальный период. Например если это 1 год - "за год нас уникально посетило ХХ" при этом уже за 2 года сколько уникально сказать будет нельзя. Да и не надо.

А точно нужно дату сохранять? Можно же без нее, зато несколько таблиц, одна чистится раз в год, вторая раз в 6 месяцев, третья раз в месяц, четвертая раз в сутки. Т.е посещения пишутся только в ту что за сутки, а потом при очистке переносятся в следующую по времени. Этакий мега-счетчик с накоплением и переполнением :)
Зато экономится одна колонка.

Ну зависит от того зачем нужны данные и с какой точностью их хранить.

Еще, возможно, не нужно время посещения, а достаточно даты посещения - тоже можно меньше байт отвести. Или сохранять не unixtime, а время, прошедшее с начала года (с пред идущего обрезания) - тогда можно и двумя байтами обойтись.

Этим становится менее удобно пользоваться, зато меньше места занимать будет :)

А страниц сколько? Может там тоже какой-то SMALLINT или MEDIUMINT поставить?
Windows
1
0
lesha (#406942)
Можно в редакторе сделать - только начинаешь писать кому-то "вы наверное не читали мою запись URL" как движек тут же говорит - "А человек, которому вы отвечаете, читал этот URL такого-то числа" :))
Windows Firefox
0
0
[email protected] (oreolek.ru)
Считать пользователей на уровне сервера. Он прекрасно может справиться с этой задачей. Это можно выполнить при помощи Webalizer (анализатор логов, http://www.mrunix.net/webalizer/download.html) или при помощи модулей самого сервера (mod_status для Апача, в первую очередь). Конечно, подсчёт уникальности пользователей придётся выбросить (либо, например, использовать вычурный формат логов и собственный анализатор их же), но вот быстродействие возрастёт в разы. На статистику вы смотрите не больше — допустим — раза в неделю, зачем бегать к базе данных при каждом обращении?
Nokia-E90 Safari
 Москва
0
0
Leonid Kaganov
Концепция движка не предполагает установку серверного софта и дополнительное конфигурирование апача. Движок должен ставиться на любой хостинг.
Windows Safari Chrome
0
0
Ну, тогда три пути.
1. Google Analytics (работает через Javascript, не считает уникальных, статистика ОЧЕНЬ подробная) и подобные сервисы счётчиков. Переложить проблему на других.
2. Чистить таблицу (так как обращаться к данным месячной давности большого смысла нет, интересует только количество посещений), оптимизировать индексы, ругать забывчивых посетителей, которые забывают логиниться.
3. Предоставить админу выбрать самому. Если у него на сервере настроена статистика, он может отключить учёт в движке. И подключить Google Analytics. Либо написать что-то своё. А может, ему просто не нравится это пожирание ресурсов.
Windows Firefox
0
0
Вариант с Google Analytic тоже хотел предложить, но, читая до этого гневные отповеди автора о менеджерах, которые используют уже готовое и творцах, которые делают все сами, решил, что не стоит. ;)

Хотя вариант практичный.
Linux Firefox
 Москва
0
0
Вариант абсолютно неприемлем, потому что Гугль-аналитик заточен под всяческое менеджерское "изучение динамики заходов".

Он никогда не сможет ответить на конкретный вопрос блогера Васи Пупкина, прочла уже девочка Светочка его новый постик или еще нет.
Windows IE
0
0
alexeybobkov
По поводу пункта 3: а какова доля безымянных unic?
Linux Firefox
 Москва
0
0
98%
Windows Safari Chrome
0
0
1)
Тогда получается, что зарегистрированных посетителей 716534 * 2% ~= 14330.
Честно говоря, я движок еще не смотрел, но очевидно, что анонимов и для зарегистрированных пользователей хранится разный набор данных, причем набор полей для анонимов является строгим подмножеством набора полей зарегистрированных пользователей. Для примера, пусть для анонимов хранится его кука, дата его первого появления, дата последнего посещения, общее количество посещений. Для зарегистрированных пользователей дополнительно хранится его имя, логин, хэш пароля, и т. д.
Получается, что зарегистрированных пользователей можно выделить в отдельную таблицу, где будут храниться ТОЛЬКО поля, специфичные для зарегистрированного пользователя. Если тебе нужно просто узнать, когда был пользователь последний раз, или сколько раз всего был, то обращаешься к таблице UNIQ, если информацию по зарегистрированному пользователю, то SELECT BLA_BLA_BLA FROM UNIQ U LEFT JOIN UNIQ_REG R ON U.ID = R.ID (UNIQ_REG - это новая таблица данных зарегистрированных пользователей)
Фишка заключается в том, что поле UNIQ_REG.ID делается типа MEDIUMINT UNSIGNED, который занимает 3 байта вместо 8 байтов BIGINT и позволяет хранить до ~ 16 c чем-то миллионов зарегистрированных пользователей (надеюсь пока хватит, а впоследствии можно и на INT безболезненно заменить). При этом, в таблице DNEVNIK_POSETITEL поле UNIQ делается тоже MEDIUMINT UNSIGNED, а не BIGINT (за счет чего и достигается экономия), и в ней хранятся только посещения зарегистрированных пользователей.
Чтобы узнать общее количество посещений конкретной страницы, можно либо просто инкрементировать счетчик прямо в таблице страниц (аналогично твоему пункту 3. И в нем дата, конечно, не нужна - только количество), причем только в том случае, если дата последнего посещения текущего анонима меньше текущей даты на какой-то интервал (скажем 5 дней), чтобы почти исключить повторные посещения анонимов. Либо анонимы записываются в новую таблицу DNEVNIK_ANONIM, полностью аналогичную таблице DNEVNIK_POSETITEL но с полем UNIQ расширенным до BIGINT (эту таблицу будет в SQL-запросе потом легко объединить сDNEVNIK_POSETITEL через UNION), и по крону раз в два месяца ночью удалять записи тех посетителей, у которых в таблице UNIQ указано время последнего посещения было ранее, чем месяц назад, добавляя их количество к вышеупомянутому счетчику страницы.
Когда идет обращение от нового пользователя (без куки или с ненайденой кукой), то ему назначается и возвращается новая кука, и он автоматом включается в таблицу UNIQ, но ID ему присваивается, скажем, начиная с 17000000 (меньше зарегистрированных пользователей). Если впоследствии он регистрируется, то его ID в таблице UNIQ меняется на следующий свободный ID в таблице UNIQ_REG, и в таблице UNIQ_REG заводится новая запись с уже с расширенной информацией. При этом, в дальнейшем его посещения записываются в таблицу DNEVNIK_POSETITEL а не DNEVNIK_ANONIM. Старые записи из DNEVNIK_ANONIM переносятся в DNEVNIK_POSETITEL за два SQL-запроса. (А если DNEVNIK_ANONIM не использовать, то можно ничего не делать).
Затея может оказаться несколько сложнее описанного, если кроме таблицы
DNEVNIK_POSETITEL, на анонимных пользователей ссылается еще много разных таблиц.
2)
Как я уже писал раньше, из таблицы UNIQ можно периодически грохать некоторые записи по условию, например, WHERE ID > 17000 AND 5 > количество_посещений AND SUB_DATE(CURDATE(),INTERVAL 366 DAY)) > дата_последнего_посещения .
3)
Про уменьшение размеров полей UNIQ, DATE, и URL уже lesha написал. В самом деле, если у тебя всего 1600 страниц, зачем INT? Вполне хватит SMALLINT! А в многоблоговом варианте, наверное будет отдельное поле, идентифицирующее конкретный блог.
4)
Отдельный индекс по полю UNIQ точно не нужен. Скорее уж добавить индекс по полю DATE, чтобы смотреть, кто из зарегистрированных пользователей в конкретный день впервые зашел на страницу.
5)
А вообще, конечно, 255 мб за год - это фигня. Так что можно ничего не трогать ;-)
Linux Firefox
 Москва
0
0
В движке необходима единая сквозная нумерация для всех посетителей, без различий, кто зарегистрированный, кто нет. Иначе оставлять комментарии, голосовать, ставить плюсики и т.п. смогут только зарегистрированные, а это фашизм.

И по некоторым архитектурным причинам я пришел в выводу, что нумерация должна быть BIGING.
Windows Safari Chrome
0
0
Ну если размеры полей менять нельзя, то удалить лишний индекс и пункт 3, хотя пока и это даже на мой взгляд не обязательно, если не приводит к торможению.
Хотя, я не понял, почему нельзя им будет будет ставить плюсики? И нумерация вполне себе сквозная остается от 1 до MAX(BIGINT). Просто до 17 лямов идут зарегистрированные пользователи, а больше - анонимусы.
Кстати! Не понятно, зачем оставлять такие длинные куки у пользователей, а не просто его ID? Единственную причину могу предположить, чтобы нельзя было понять "кто первее" зарегистрирован, но ID вполне можно посмотреть прямо в заголовке карточки в интерфейсе. Зачем выдавать в куке хеш чегото-там?
Windows Safari Chrome
0
0
Кстати, и без дополнительной таблицы UNIC_REG можно обойтись, если лень. Просто в момент регистрации меняется первичный ключ (ID) пользователя в таблице UNIC, чтобы он влазил в MEDIUMINT. Куки и все данные пользователя при этом, конечно, остаются в неприкосновенности.
Как я уже говорил, возможно, если на код пользователя еще что-то завязан, надо будет обновить его код и в других таблицах.
Windows Safari Chrome
0
0
О, если интересно, у меня "majax error: Error" сейчас два раза был. Но оба раза каммент отправился
Windows Firefox
1
1
lleo.me/[email protected]Андрей
> Надо их как-то разгонять и отваживать.
Ледонид, в качестве одного из шагов предлагаю в RSS отдавать все содержимое поста дневника. Тогда не будет необходимости переходить на сайт, чтобы прочитать пост.
Linux Firefox
 Москва
0
1
Я хотел бы уменьшить число читателей, а вы предлагаете его увеличить. Нелогично.
Windows
0
0
lesha (#406942)
Загадывать логические загадки для допуска к прочтению :)))
Роботов точно отсеет
Windows Firefox
1
0
lleo.me/[email protected]Андрей
Я предлагаю уменьшить количество посетителей сайта путем публикации полного поста в RSS. Конечно, количество читаталей это не уменьшит, но посетителей - точно.
А насчет уменьшения количества читаталей - давайте посмотрим правде в глаза: пишете вы хорошо и интересно. Это автоматически означает, что количество читатателей у вас будет увеличиваться, как и у всякого интересного блогера, вне зависимости от вашего желания. И ограничить этот список фактически можно только двумя путями: или начав писать всякие глупости, или ограничив разными способами круг лиц, допущенных читать ваши посты. Что, конечно, будет печально.
Nokia-E90 Safari
 Москва
2
1
Leonid Kaganov
Вы предлагаете уменьшить количество тараканов путем выключения света на кухне.
Windows Firefox
0
0
jabacrack
при нажатии кнопочки "unic2uni3"
на открывшейся странице вылазит вот такая ошибка
"SQL error: Table 'sepulka_blog.dnevnik_posetil_2' doesn't exist
Warning: Invalid argument supplied for foreach() in /var/www/sepulka/data/www/sepulka.org.ua/-blog/module/upgrade/unic2uni_2.php on line 15"

и счетчик, кажется, бежит бесконечно
Nokia-E90 Safari
0
0
Leonid Kaganov
Это пока не нажимайте - оно в процессе разработки.

всего комментариев: 32

<< предыдущая заметка следующая заметка >>