Лучший способ хранить представления / статистику в MySQL

Question

Я не работаю на сайте, который хранит отдельные просмотры страниц в таблице 'views':

CREATE TABLE `views` (
  `view_id` bigint(16) NOT NULL auto_increment,
  `user_id` int(10) NOT NULL,
  `user_ip` varchar(15) NOT NULL,
  `view_url` varchar(255) NOT NULL,
  `view_referrer` varchar(255) NOT NULL,
  `view_date` date NOT NULL,
  `view_created` int(10) NOT NULL,
  PRIMARY KEY  (`view_id`),
  KEY `view_url` (`view_url`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Это довольно просто, хранит user_id (идентификатор пользователя на сайте), их IP-адрес,URL-адрес (без домена, чтобы немного уменьшить размер таблицы), URL-адрес реферала (который на самом деле не используется сейчас и может от него избавиться), дата (конечно, в формате ГГГГ-ММ-ДД) иотметка времени unix, когда происходило представление.

Таблица, конечно, становится довольно большой (4 миллиона строк на данный момент, и это довольно молодой сайт), и запросы к ней выполняются медленно.

Для некоторой базовой оптимизации я сейчас создал таблицу 'views_archive':

CREATE TABLE `views_archive` (
  `archive_id` bigint(16) NOT NULL auto_increment,
  `view_url` varchar(255) NOT NULL,
  `view_count` smallint(5) NOT NULL,
  `view_date` date NOT NULL,
  PRIMARY KEY  (`archive_id`),
  KEY `view_url` (`view_url`),
  KEY `view_date` (`view_date`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Это игнорирует информацию о пользователе (и URL-адрес реферала) и сохраняет, сколько раз URL-адрес просматривался в день.Вероятно, именно так мы обычно хотим использовать данные (сколько раз страница просматривалась за день), поэтому следует сделать запросы довольно быстрыми, но даже если я использую их в основном для замены таблицы 'views' (справа)теперь я представляю, что могу показать количество просмотров страниц по часам за последнюю неделю / месяц или около того, а затем показать ежедневные просмотры сверх этого, и поэтому мне понадобится только таблица «просмотров», которая будет содержать данные за последнюю неделю / месяц), но она все еще большаяТаблица.

В любом случае, короче говоря, мне интересно, если вы можете дать мне какие-либо советы о том, как лучше всего обрабатывать хранение статистики / просмотров страниц на сайте MySQL, цель состоит в том, чтобы сохранить размертаблиц в БД как можно меньше, и при этом можно будет легко (и, по крайней мере, относительно быстро) запрашивать информацию.Я немного посмотрел на секционированные таблицы, но на сайте не установлен MySQL 5.1.Буду признателен за любые другие советы или мысли, которые вы можете предложить.

Answer 1

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

Answer 2

Предполагая, что ваше приложение - это блог, и вы хотите отслеживать просмотры ваших сообщений в блоге, вероятно, у вас будет таблица с именем blog_posts.В этой таблице я предлагаю вам создать столбец с именем "views", а в этом столбце вы будете хранить статическое значение количества просмотров этого сообщения.Вы по-прежнему будете использовать таблицу views, но она будет использоваться только для отслеживания всех представлений (и для проверки, являются ли они «уникальными» или нет).

В основном, когда пользователь посещаетпост в блоге, он проверит таблицу views, чтобы увидеть, нужно ли ее добавить.Если это так, он также увеличит поле «views» в соответствующей строке для записи в блоге в blog_posts.Таким образом, вы можете просто обратиться к полю «Представления» для каждого сообщения, чтобы быстро взглянуть на количество просмотров.Вы можете сделать этот шаг дальше и добавить избыточность, настроив задание CRON для повторного подсчета и проверки всех представлений и обновления каждой строки blog_posts соответственно в конце дня.Или, если вы предпочитаете, вы также можете выполнить пересчет каждого обновления, если точность до секунды равна ключ .

Это решение хорошо работает, если ваш сайт интенсивно читается, и вам постоянно приходится подсчитывать количество просмотров каждого поста в блоге (опять же, при условии, что это ваше приложение: -))

Answer 3

Механизм хранения архивов MySQL

http://dev.mysql.com/tech-resources/articles/storage-engine.html

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