Форум MySQL

Здравствуйте. Есть такая ситуация: пишу свой биллинг. Данные в таблицу должны валиться из Netflow в таблицу tab1. С этим проблем нет. Но данные должны агрегироваться и вставлятся в таблицу tab2. Для этого придумана такая штука: в таблицу tab1 ложатся данные, потом эти данные забираются кроном для агрегации, и тут же данные из таблицы tab1 удаляются. Хочется сделать что бы данные, на время работы крона, ложились не в таблицу, а в буфер например и после очистки таблицы tab1 заносились. Возможно ли такое реализовать? и как это сделать (если возможно).
Заранее спасибо.

Самый простой способ: в начале работы агрегатора tab1 переименовать в tab1_tmp и создать пустую таблицу tab1. После чего спокойно вынимать данные из tab1_tmp и удалить ее по окончании.

Изначально, предпалагается что поток Netflow будет лить в 2 таблицы: 1. для сбора серых данных tab1, 2. промежуточная таблица, данные в которой будут удаляться tab1_tmp.
Просто есть вероятность того, что в промежуток между выборкой из таблицы tab1_tmp и удалением данных из нее могут прилитеть еще данные, они не обработаются и удалятся. И для этого хочется что бы поток, на время исполнения манипуляции с данными собирался где-нить в памяти, а потом выкладывался в tab1_tmp/

Ничего не понял. Это уже следующий вопрос? Как он связан с вопросом из первого поста?

Ну значит в первом случае, я не правильно выразился, сорри

Тогда лучше еще раз все опишите подробно, потому что я не могу понять о чем речь...

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

так и что это меняет?
данные льются в таблицы table1 и table2, после чего из table1 мы выбираем данные, агрегируем и пишем в table3... то есть зачем Вы рассказывали про table2 вообще не понятно. Ну да не в этом дело - решение-то остается прежним:
1. table1 переименовываем в table1_tmp
2. создаем чистую table1
3. из table1_tmp выбираем даные, обрабатываем и кладем в table3
4. удаляем table1_tmp

что непонятно?

Ну как же)))) все популярно и понятно!))) спасибо большое логику понял
Просто на этом форуме хотелось увидить реализацию через запросы, как-нить по хитрому, а оно вон как оказалось просто

не всё просто.
Привлечение раздела языка администрирования данных в общем случае снижает и надежность и безопасность.
Всё ж регулярно тыкать команды ALTER в живую БД это риск.

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

Решение смелое и неожиданное :)
Попробуйте.
Хотя столь короткий интервал меня пугает, но сама идея весьма яркая.
По таблице на каждый час уже так достойно.

Мне кажется двух таблиц должно быть вполне достаточно. Просто в описанном алгоритме не переименовывать таблицы, а переключать поток:
переключили поток на свободную таблицу, обработали заполненную, очистили обработанную. Когда пришло время - проделали тоже самое, просто поменяв таблицы местами.

С перенаправлением могут возникнуть проблемы... т.к. Flow-tools пишется на С++, а в нем сейчас ковырятся как бы не савсем удобно...

как бы аргумент савсем детский.

Прочитайте тему http://softtime.ru/forum/read.php?id_forum=3&id_theme=66427, там ближе к середине задача подобная вашей, возможно что-то пригодиться.

нет, это не то...

Что же Вы не сказали, что я Вас уже второй раз посылаю по этой ссылке...
P.S. Василий Петрович Триггер попросился таки на пенсию? :)

Он не просто просился на пенсию, а сам! своим пешком отвалил)))) вот и нужен альтернативный вариант... Кстати, в ветке про тригеры я так и намекнул: трггер не надежный работник, дохленький))