|
MySQL.RU - Webboard
 Вернуться
 Эффективные хранение и обработка статистики (Alexander) 14/08/2004 - 12:15:18
 Re: Эффективные хранение и обработка статистики (walrus) 14/08/2004 - 17:15:11
Re: Эффективные хранение и обработка статистики (Alexander) 14/08/2004 - 19:04:23
Re: Эффективные хранение и обработка статистики (Alexander) 14/08/2004 - 19:17:13
Re: Эффективные хранение и обработка статистики (Dinky) 16/08/2004 - 18:22:20
Re: Эффективные хранение и обработка статистики (dxfan) 17/08/2004 - 15:30:00
> Original message text:
> From: Alexander - 14/08/2004 - 12:15:18
> Subject:Эффективные хранение и обработка статистики
> -----------------
> Вопрос скорее не по мускулу, а вопрос по эффективности хранения и обработки статистики по трафику. Есть сервер с базой данных stat, есть таблица на каждый месяц (пр. 200408Traffic) с полями src,dst,id,type,bytes,time и с несколькими индексами (иникальными и обычными). В нее постоянно должна литься статистика со считалок ~ 15-20 млн. записей в месяц. Надо сформировывать каждые 3-5 минут таблицу вида date,id,ip,bytes.
> поле id - идентификатор клиента, который берется из другой таблички с соответсвием id <-> ip. Он выставляется: update 200408Traffic set id= ... where id=0. Есть ситуации, когда юзер меняет ip в середине месяца, для этого он и нужен.
>
> Картина получается следующаяя при таких объемах записей в таблице (15-20 млн) сильно тормозится запись новых данных, т.к. есть индексы. С другой стороны формирование таблицы с обобщенными данными без индексов - в 3 минуты не уложиться явно.
>
> Посоветуйте какие-нибудь эффективные решения данного вопроса, как можно улучшить данную схему. Рад буду любым советам.
>
>
From: Dinky - 16/08/2004 - 18:22:20
Subject:Эффективные хранение и обработка статистики
-----------------
пара замечаний по ключам:
1) избыточность ключей, зачем вам на каждое поле по ключу?
например, в первой таблице KEY (collector) не нужен, а во второй - KEY (date) явно лишние, т.к. с них начинаются PK
2) если group by date "тормозит", значит индекс по этому полю не используется, можно запрос целиком увидеть?
советы по алгоритму (как я это понял):
если Вам надо хранить/обрабатывать исходную информацию вечно - создавайте каждый месяц новую таблицу ;) другой вариант - держать в одной, но не использовать ее для запросов, только как хранилище, тогда сворачивать статистику во вторую таблицу лучше "на лету", только понадобится еще одна таблица - типа кэш на текушую дату (id,ip_addr,type) - по ней скрипт должен проверить существование записи, если уже есть - инкрементировать поле bytes в 200408Total, если нет - добавить запись в обе. Это сведет к минимуму загрузку key buffer-a. Впрочем, если Вы на том же сервере собираетесь отчеты по второй таблице гонять, тогда кэш таблица не нужна, мучайте 200408Total :)
--
Dmitry
[Это сообщение - спам!]
Последние сообщения из форума
Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL,
версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
16672
|
|
