Форум MySQL

Нет, эти логи в почасовом формате необходимо хранить минимум 15-ти дневной давности. А лучше - 30-ти. Объединять в суточную статистику - все что более давние. Но удалять вот их уже - точно нельзя...
Не понял одного - зачем месяц делить на три. По десять дней? Тогда ясно. Угу, спасибо, это вариант. 16 таблиц... грустно.

Что в varchar? Сколько сейчас записей в таблицах? Каждая таблица по 55 Мб или все вместе? Можно такой финт ушами сделать - хранить информацию об текущих сутках в одной таблице, а месяц поделить на 3, таким образом у вас будет 16 таблиц вместо 4. Для обеспеченья работоспособности и скорости, главное, чтобы размер одной таблицы не превышал разумные пределы (скажем так, 50-100 Мб для одной таблицы MyISAM - это много).

PS Проблема вообще говоря известная и многие страдают - актуальные логи как правило вообще больше чем за 2 дня не хранят.

Loki
В таблице есть данные (на самом деле - таких таблиц четыре, каждая - для своего направления), эти данные имеют столбцы user_id , hour , date , плюс еще три столбца - у каждой таблички из этих четырех - они свои и суть их не так важна, важно лишь понимать, что один столбец - varchar , два других - int.
Люди что-либо делают, и данные записываются на текущую дату и на текущий час. После этого, эти самые люди смотрят свою статистику - сколько и чего они наделали и что им за это будет...
То есть, данные должны храниться по часам. Разумеется, архивные данные... ну там - месячной давности и более давние - я их склеиваю в суточную статистику - без разбивки на часы. Но значения это не имеет, статистика увеличивается, увеличивается и увеличивается. Воздушный шарик тоже так может, а итог?...

valenok
Всё, что возможно из этого - уже было сделано, ужать далее данные не получится. А вот то что отдельная таблица... в сущности, я и ждал того, что сказал Loki.

НУ я думаю может стоить поступить так:
Таблица вобщем - там записанно что пользователи смогли сделать.

Создать отдельную таблицу, там сделать по строке для каждой операции,
а потом чистить первую и увеличивать по значению ячейку: пользователи смогли сделать у той операции..

Тоесть в одной по строке на пользователя и операцию а на второй только операцию и колвл пользователей сумевших совладать с операцией.

можно создать архивную таблицу. Так как каждая таблица - отдельный файл, то нагрузка на БД снизится.
А что за статистика? ее должен получать каждый пользователь? Может стоит обобщать статистику за определенные периоды. Вообще, если будет больше подробностей, то придумать что-нибудь можно.

Наверное говорил. Меня беспокоит постоянное наполнение той базы, которая точно так же - постоянно читается пользователями. сколько это может продолжаться, если 55 мб данных накопилось за несколько дней интенсивной (нормальной) работы? Недолго. Поэтому я и ищу вариант архива. Что возвращает нас к моему первоначальному вопросу - какие есть варианты организации архива, без урезания данных? В частности, меня интересует необходимость создания другой базы. Нужно ли? Или достаточно другую таблицу? Или и то, и другое - не нужно, нужно класть в файлы?

В статистику про пользователей вообще ничего не пишется. Пишется про их работу. Там нет ни юзерагентов, ни айпи. Там есть то, что они смогли сделать. Эти "пользователи" - действительно Пользователи... а не посетители... В форуме softtime хранится дата регистрации, контакты и количество сообщений. Представьте, что данных больше. Да еще и не ВООБЩЕ, за всё время, а с разбивкой на часы - отдельные данные за каждый час работы.

Просто у тебя выходит что ты в таблицу 47 раз для каждого пользователя записываешь его user_agent
достаточно одного и с йп...

Вобщем твоё дело.

--

Доступ затрудник к статистике в файлам ав не доступ к бд.
Тоесть и файлов труднее доставать статитстику чем из бд.

--

Может и стоит создать ещё БД - архивную.
А ты разве про объём ничего не говорил?

Почему чтение из текстовых файлов затруднит доступ к mysql? Если я не ошибаюсь, то mysqld - это одно, а httpd - это другое.
Создание других таблиц объема к базе не уменьшит, но мне всегда казалось, что обращение за информацией идет не в базу, а в таблицу. То есть, влияет именно объем таблицы. В конце концов - никто не мешает создать вторую базу, архивную.

В статистике пользователей может быть очень много разных данных. И вот чего там нет, так это ip...

Чтение из текстовых файлов - затруднит к ней доступ.
Создание других таблиц не уменьшмит обьём БД

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

Статистика пользователей?
Какие статитстические даееые вы собираетесь хранить кроме ip ?

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