Помогите создать оптимальную структуру таблиц

[Омск]

Помогите создать оптимальную структуру таблиц

Здраствуйте, нужно как то разместить в таблице данные. Данные по статистике сайта.

Ид сайта.
Хосты для сайта
Хиты для сайта
В топ Из топа
Онлайн максимальный
Разные юзер агенты (Около 30)
Ип
день

Все не так просто.
Статистику надо выводить еще и по нагрузке за час. То есть на выводе страницы должно быть так:

c 0.00-1.00
Хостов было столько
Хитов было столько
В топ Из топа было столько
Онлайн максимальный был такой то
Было:
29 браузеров опера
100 IE
40 Мозила
20 неизвестно.

c 1.00-2.00
Хостов было столько
Хитов было столько
В топ Из топа было столько
Онлайн максимальный был такой то
Было:
29 браузеров опера
100 IE
40 Мозила
20 неизвестно.

и так далее.

Тоже самое Надо будет выводить и по дням.

Есть вариант складывать в базу просто
Время обрашения
Юзер агент
Ип

И уже при выводе статистики надо считать. Но так не подходит так как данных много, большая нагрузка на базу. Лучше UPDATE +1 при внесении данных в базу. В итоге как лучше спроектировать структуру таблиц, чтобы вводить данные insert если строки еще нет. UPDATE если строка уже есть?

 

[baev]

вводить данные insert если строки еще нет. UPDATE если строка уже есть?

— это от структуры не зависит.
Это от чтения документации зависит.

http://dev.mysql.com/doc/refman/4.1/en/insert-on-duplicate.html

 

[Омск]

Это я знаю. Спасибо. Видимо не так выразился.
Мне нужна именно структура.

Чтобы не вносить одним запросом. (Время обрашения, Юзер агент, Ип) И потом все это разбирать.

 

[vonica]

все в одну таблицу,

плюс дополнительные/дополнительная таблица для хранения таких данных, как за прошедший день, неделю, месяц и так далее, для того чтобы не пересчитывать постоянно

 

[Омск]

Автор оригинала: vonica
все в одну таблицу

И это разве оптимально?

тогда 1 строка из таблицы будет содержать около 70 полей!!!!

-~{}~ 13.03.08 21:18:

над этим я уже думал. Максимум время хранения данных 90 дней. Пишем данные поочереди в 2 таблице. Каждый день меняем таблицу. После смены добавляем данные в таблицу истории

-~{}~ 13.03.08 21:19:

и очишаем таблицу.

 

[vonica]

Ну и пусть 70 полей, а что разве будет быстрее вставить данные в несколько таблиц чем в одну

Можно через крон статистику считать каждый час, и хранить в таблице истории,

 

[Омск]

Хм. День уже думаю над структурой) Ларчик просто открывался) vonica спасибо

 

[Mr_Max]

Омск
Какие данные ты будешь хранить - это дело второстепенное.

Я думаю, гораздо важнее алгоритм "обновления" твоих таблиц.
Например, я не вижу ничего хорошего в твоих

Лучше UPDATE +1

Так-же как и в "прямых" инсертах

В любом случае я бы работал со временной таблицей.
В которую бы тупо все инсертил.
И периодчески, насколько тебе это критично, обновлял бы основную таблицу с предварительное ее(осн. таблици) блокировкой

Или сохранял новые данные в файл и так-же периодически делал LOAD DATA INFILE

-~{}~ 13.03.08 20:32:

Скорость выполнения запросов:
http://spivak.kiev.ua/mysql/query-speed.html

 

[Омск]

Нужна ОН-ЛАЙН статистика. Mr-Max спасибо. Но мне кажеться что через каждую минуту блокировать таблицу, нестоит. Проше UPDATE

 

[Mr_Max]

Нужна ОН-ЛАЙН статистика

Ты ж все сам знаешь.
Что ты с нас хотел?
Зачем вопрос задавал?

-~{}~ 13.03.08 21:04:

З.Ы.
Способ твой тормознутый.
И при приличной посещаемости то и дело будут постоянно будут обновляться индексы.
Что, в принцыпе, нафик кому нужно.
Тебе в том числе.
А твоему серваку и подавно.

 

[berkut]

надо по крону обрабатывать лог апача, который соответствующим образом настроить. перед подсчётом, делать rename лога, чтобы ничего не упустить. иначе жопа.

 

[Омск]

Поэтому я и интересуюсь. Хранить все в одной таблице тормознуто.
Записывать во временую тоже нереально. Так как надо оббновление Онлайн. В базе будет до 10 000 строк.
Но данные будут обновляться часто. Примерно 1 000 000 запросов на update в день. Есть еще вариант обновлять раз в час. Дабы количество полей во временной таблице уменьшилось примерно до 40.

 

[Mr_Max]

berkut

Разные юзер агенты (Около 30)

Скорее всего ему нужны лишь "живые" пользователи

 

[Омск]

К логу доступ не имееться

-~{}~ 13.03.08 23:07:

Вы правы. Только "живые"

 

[Mr_Max]

1 000 000 запросов на update

Ага
И индекс будет обновляться у тебя при каждом апдейтe

?
Подумай справится ли у тебя БД с
Обновлением 11 query|per|sec.
С "перестройкой" индексов.

-~{}~ 13.03.08 22:12:

Прочитай ссылку о скорости выполнения апдейтов.

 

[berkut]

о чём трындеть, если даже к логу доступа нет. это как некоторые тут, пишут билинг, виртуальными денюшками на счету управляют, а не знают как 2 таблицы связать.

 

[Омск]

то есть выход разбить таблицу? Я понимаю что это такое. Просто никогда не пользовался) Но такой вопрос.

Есть таблица из 40 полей. 3 числовых индекса. Нужен 1 update

Есть 3 таблицы. В сумме 40 полей. по 1 индексу на каждую. Нужно 3 Update. Хм, есть ли смысл бить?

Про оптимизацию и ускорение работы я обязательно завтра с утра на свежую голову почитаю.

-~{}~ 14.03.08 00:08:

Исправлюсь. Нужен 1 UPDaTE но для 3-х таблиц)

Но разве это ускорит работу?

-~{}~ 14.03.08 00:14:

Во вторых если таблица одна то в ней всего 1 ключ. Номер сайта. И ключ не изменяеться. В итоге при UPDATE будет изменены только данные, размер ключей же останеться таким же.

 

[Alexandre]

Есть таблица из 40 полей.

это уже не оптимальная таблица (будет есть много место в памяти) и что - все 40 полей будут заполнены?

 

[Омск]

Да. По умолчанию поля имеют значение 0. Ко всем кроме ключа применяеться только UPDaTE +1

Решил все же разделить на таблицы с:

3 поля.
25 полей
25 полей
15 полей
12 полей

А вот уже для истории собирать данные каждый день. И ложить их в обшую таблицу.

-~{}~ 14.03.08 17:35:

Все таблицы состоят из ид сайта, он же ключ. И числовые данные.

 

[Gas]

Все таблицы состоят из ид сайта, он же ключ. И числовые данные.

круто, а user-agent, разрешение, geo-target'ing, referrer - тоже всё числами. Это я к тому, что всё равно нужны таблицы справочники, а если так - то при твоей схеме, нужно будет в real-time ещё доставать данные из их + возможно дополнять, ф топку.
Пишешь всю инфу как есть в темповую таблицу, а крон скриптом раскидываешь по таблицам с агрегированными данными и подчищаешь темповую.
Google аналитикс статистику тоже показывает не на текущий момент, а с запаздыванием и ничего.