структура click counter бд

berkut

Новичок
структура click counter бд

как оптимальнее создать структуру бд для подсчёта кликов по ссылкам? все ссылки на сайте автоматом подсвечиваются и отдаются с подсчётом кликов. т.е. запрос будет типа:
Код:
UPDATE clicks WHERE url = ?
как вариант я думаю о такой структуре:
Код:
CREATE TABLE `clicks` (
  `host` varbinary(255) NOT NULL default '',
  `uri` varbinary(255) NOT NULL default '',
  `clicks` mediumint(9) unsigned NOT NULL default '0',
  UNIQUE KEY `host` (`host`,`uri`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

UPDATE clicks WHERE host = ? AND uri = ?
смущает длина ключа, не скажется-ли это серъёзно на производительности? имеет-ли смысл в дополнительном поле хэш?
Код:
CREATE TABLE `clicks` (
  `hash` varbinary(32) NOT NULL default '',
  `host` varbinary(255) NOT NULL default '',
  `uri` varbinary(255) NOT NULL default '',
  `clicks` mediumint(9) unsigned NOT NULL default '0',
  UNIQUE KEY `host` (`hash`, `host`,`uri`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
и тогда запрос будет таким:
Код:
UPDATE clicks WHERE hask = ? AND host = ? AND uri = ?
 

Gas

может по одной?
1. зачем при добавлении поля с хешем всё равно в условии host и uri ?
2. для такой задачи лучше innodb engine, а не myisam
 

berkut

Новичок
зачем при добавлении поля с хешем всё равно в условии host и uri ?
ну типа чтобы гарантировать, что это требуемый урл. ведь 2 разных url адреса могут дать одинаковый хэш.

за innodb спасибо, как-то не подумал
 

das6745

Новичок
berkut
а в какой, к примеру, ситуации два одинаковых хэша будет? и где можно прочитать про такое явление как два одинаковых хэша в одной таблице?

-~{}~ 06.11.07 17:37:

ps: я из манов поня что такое невозможно .. ну или оччч маловероятно.. ткните носом кто-нить
 

berkut

Новичок
как два одинаковых хэша в одной таблице
а при чём тут таблица??? гугл - коллизия. по идее это и ежу должно быть ясно, что грубо говоря url может быть длинной от 5 до 255(или больше) символов, а мд5 только 32. урл может состоять из набора большего кол-ва символов.
логично прикинуть, что кол-во всевозможных вариантов url строк во много раз больше кол-ва возможных хэш строк
 

das6745

Новичок
berkut
ну да... таблица не причем. я просто посчитал что разумно было бы по host и uri сделать хэш индекс, они очч шустрые на оператор "=", а пихать свой мд5 - не есть гут


про мд5, я сначало про хеш индекс начал, невнимательно прочел структуру таблицы. на таблице эва одинаковых - невозможно. а для строк разной длинны мд5 будет разным, есть только одна ситуация когд у двух строк один хэш: MD5(X1||S) = MD5(X2||S) если MD5(X1) = MD5(X2) смотри http://ru.wikipedia.org/wiki/MD5#.D0.A3.D1.8F.D0.B7.D0.B2.D0.B8.D0.BC.D0.BE.D1.81.D1.82.D0.B8
 

Gas

может по одной?
я просто посчитал что разумно было бы по host и uri сделать хэш индекс, они очч шустрые на оператор "=", а пихать свой мд5 - не есть гут
поток сознания...

berkut
я бы всё таки искал только по хешу.

ну пара вопросов, может привлекут народ в тему :)
1. ожидаемое количество уникальных урлов?
2. ожидаемое количество хитов на обновление и выборку счётчиков в секунду?
 

berkut

Новичок
Gas да всё скромно. урлов порядка 10000, добавляться будут относительно редко. с хитами на обновление вообще даже примерно не предпологаю. выборка - не вопрос, доступна только 3 человекам, но с возможностью поиска и группировки по host.
вопрос скорее теоретический: что быстрее для поиска:
UNIQUE KEY `host` (`host`,`uri`) или UNIQUE KEY `host` (`hash`, `host`,`uri`) + where hash and host and uri.
пологаться только на хэш не хочется, это ведь явная ошибка в системе
 

Gas

может по одной?
вопрос скорее теоретический: что быстрее для поиска:
чем меньше индекс, тем быстрее :)
Если всё равно хочешь сравнивать `host`+`uri`, то хеш тебе не нужен вообще.

пологаться только на хэш не хочется, это ведь явная ошибка в системе
дело твоё, но это ж не финансовые операции, а вероятность 10000 к 2^128 (md5) или 2^160 (sha-1) вообще ничтожна.
 

berkut

Новичок
Gas а mysql не будет искать сначала по хэшу, и только в случае успеха, по host & uri? скорее всего есть разница, сравнивать строки по 255 символов или по 32. это я к тому, что если убрать хэш, то в базе есть полно урл, отличающихся только последним параметром - т.е. при поиске базе придётся сравнивать:
domain.ru/veryLongPath?page=1
domain.ru/veryLongPath?page=2
и таких строк может быть полно.
Я вот не знаю, как в муське производиться сравнение строк, в том числе и в составном индексе, но возможно всё таки с хэшем будет быстрее?

-~{}~ 06.11.07 20:56:

это чисто теоретический интерес, на будущее. в данном случае вообще было-бы целесообразней завести отдельную таблицу и туда insert всех url, а по крону и при попытке просмотра статистики, считать эту таблицу, обновлять данные в основной и чистить эту временную
 

Mols

Новичок
Думаю так
1. Неуникальный ключ по хешу. Хеш бинарный - 16 байт.
2. условие WHERE my_hash=.... AND my_url=...
Так как вероятность того, что хеш повторится - действительно крайне мала, то всё очень даже шустро будет работать... юзается короткий индекс(фактически он будет уникальный) Практически никогда не возникнет ситуации когда под условие my_hash=... попадёт больше одного значения в вашей таблице, а значит и AND my_url=... будет проверятся только для одной записи.

В общем получается, что использовать такую структуру выгоднее, чем повесить просто уникальный ключ на УРЛ. Поле 16 байт и индекс по нему займут меньше места, чем индекс по УРЛ. Ну и при поиске лучше

Но вот насколько это выгоднее... сложно оценить.
Ну и следить за уникальносью записей прийдется... но это просто в принципе.
 

zerkms

TDD infected
Команда форума
а для строк разной длинны мд5 будет разным, есть только одна ситуация когд у двух строк один хэш: MD5(X1||S) = MD5(X2||S) если MD5(X1) = MD5(X2)
из md5(x1) = md5(x2) не следует что x1==x2
 
Сверху