изоляция агрегационных запросов

[belbek]

изоляция агрегационных запросов

запуск запроса на вывод агрегированной статистической информации съедает дофига ресурсов, настолько дофига, что пишущие в эту же базу скрипты не успевают делать инсерты,
во время работы агрегационного вопроса. Доп. условия: агр. запросы уже оптимизированы, кеширование результатов арг. запроса уже включено, т.е. теряем инсерты только при первом запуске агр. запроса. Какие методы решения проблемы? Спасибо.

 

[c0dex]

belbek
у нас было решено в виде 2х бд с репликацией, на одной шли инсерты и работа сайта, на другой - считалась статистика

 

[Wicked]

окей... что значит, что теряются инсерты? вставка происходит нормально, но потом не всегда в базе находятся эти ряды? или они отваливаются по таймауту от нагрузки? или они отваливаются по таймауту от локов (engine=myisam?) ? или может еще какие-то причины?

вот.. собственно, надо понять, что же происходит

 

[Gas]

belbek
обычно для расчёта статистики советуют схему как описал c0dex

Ну а так:
1. не писать сразу в таблицы со статистикой, а в какие-то лог-файлы, потом их парсить и вставлять по крону;
2. попробовать insert delayed
3. перевести с myisam на innodb, тогда не будут insert'ы становиться в очередь после долгоиграющих select'ов (только скорость работы может и уменьшиться, зато таких проблем с конкурентностью не будет, можешь на свой страх и риск покрутить innodb_flush_log_at_trx_commit )

-~{}~ 21.05.10 13:18:

вот.. собственно, надо понять, что же происходит

мне кажется ситуация страндартная:
- таблица myisam
- запускается долгий select запрос
- insert/update становится в очередь за ним
- а уже после в очередь становятся все select'ы
- всё стаёт колом пока не выполнится первый долгий select

 

[belbek]

Всем спасибо, делаю по рецепту c0dex

 

[Dovg]

belbek
Дофига каких именно ресурсов аггрегация дофига съедает?
Что значит "теряются инсерты"?

Если проблема просто в локе, то достаточно банальной ротации таблиц ИМХО.