|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Strange Alex 2:5000/104.51 19 Dec 2002 06:11:10
To : Andrey Ostanovsky
Subject : Учет тpаффика
--------------------------------------------------------------------------------
18 Dec 02 22:57, you wrote to me:
SA>> Hу ясен пень в инсерте работает. Ты в load data infile заставь
SA>> работать :)
AO> У меня нет файла.:) Вывод ipacctctl сразу льется в mysql базу.
Hу положим не сразу... :) Или ты дохачил ipacctctl
и mysql API прямо из него пользуешь?
SA>> И еще раз повторяю, сравни скорость заливания
AO> Hу да: записать файл, прочитать, распарсить, залить. Лишние
AO> телодвижения.
О! Мистер теоретик? Смею тебя уверить операция записи чтения
файла на диск гораздо дешевле N insert-ов и даже одного
insert в стиле mysql "insert ..values (...),(...), ...".
Hе просто так утверждаю, а именно потому что провел кучу
различных тестов и выбрал оптимальный вариант.
(А если еще подумать, то файл можно например на MFS сливать
или еще чего придумать)
Дамп из ng_ipacct в mysql у меня происходит раз в минуту.
И там не то что несколько тысяч строк, а бывает что и
несколько десятков тысяч (а ты думал у различных людей
одинаковый трафик ? :) У многих может быть еще больше).
Потом раз в пять минут из общей таблицы дампа все данные
рассортировываются по таблицам клиентов в зависимости от
правил по ip & port (опять же mysqlю передается всего
один запрос и всю сортировку он делает сам не передывая
никаких данных клиенту)
Hу и дальше например раз в сутки суммарные показания
за этот день сливаются в долгохранящиеся таблицы общей
_статистики_ (до этого они были просто данные).
И уже из нее (+ для точных показаний за текущие сутки
еще и из сегодняшней) данные доступны для различных клиентов
которые будут обсчитывать, отрисовывать, etc _статистику_.
SA>> нескольких тысяч строк через insert и через load data infile.
AO> Да нету там нескольких тысяч строк. Если у меня каждые 10 минут в базу
AO> будут литься несколько тысяч строк - то это должен быть уже явно не
AO> mysql.:)
Можно поспорить. Ибо как раз для такой задачи и на таких данных,
где нет никаких отношений, ничего сложного, сплошные данные,
в отличие от других SQL серверов, рулит именно mysql.
WBR, Strange Alex.
...STRANGE-RIPN, RSA16-RIPE, UIN: 8397628, E-mail: strange(at)unicon.ru
... и в боpьбе с зеленым змием побеждает змий...
--- GoldED+/BSD 1.1.5
* Origin: Novosibirsk, Russia (2:5000/104.51)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
