|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Constantin Stefanov 2:5020/400 01 Jun 2005 14:59:43
To : Gennady Abramov
Subject : Re: netflow коллектор какой лучше
--------------------------------------------------------------------------------
Gennady Abramov wrote:
> Tue May 31 2005 10:37, Constantin Stefanov wrote to Gennady Abramov:
> >> >> ЗЫ Только Оpакл позволит плоско pаботать с таким количеством записей в
> >> >> одной таблице за счет многоуpовневого pазбиения на pазделы - всё
> >> >> остальное извpат. фpивеpные БД издохнут не pодившись. Интеpбейз
> >> валится
> >> >> на объеме в несколько миллионов записей в таблице (около 3-4).
> >> CS> select count(*) from ip_accounting
> >> CS> 73507895
> >> Если это неаггрегированные значения - то с февраля ты , получается,
> >> прокачал через себя порядка 50Гб, что , безусловно, очень смешные
> >> значения.
> >> CS> База - PostgreSQL. Hе особо напрягается. Hе миллиарды, конечно, да и
> >> CS> скорость небольшая - это данные чуть меньше чем за четыре месяца ( с
> >> CS> начала февраля). Так что жить можно. Хотя из такого объема выборки
> >> CS> делать в реальном времени тяжело - для этих целей есть отдельная
> >> таблица
> >> CS> с уже агрегированными значениями.
> >> И - тем не менее - а зачем?
> >> Почему - при несильно больших объемах - нельзя хранить данные в
> >> компрессированных raw бинарниках, а в базу лить только "уже
> >> аггрегированные значения"?
> >> Тем более , что делать аггрегацию силами базы , мягко говоря,
> >> неоптимальное решение задачи при даже небольших объемах.
> CS> Да не вопрос. Решение было сделано на коленке, когда быстро поандобился
> CS> учет. уже сейчас я думаю именно так и поступить - хранить первичные
> CS> данные от netflow, а в базу - только аггрегированные таблицы для показа
> CS> через веб. Правда, когда руки дойдут - пока и так работает. Я это к
> CS> тому, что даже ьесплатная база вполне может выдержать таблицу с
> CS> десятками миллионов записей. То, что такое решение неоптимально -
> CS> видимо, я с этим соглашусь.
> "Выдержать таблицу" - да. Хотя я бы не стал рисковать. А сколько времени на
> мощной машинке PostgreSQL обработает запрос на предмет суммирования пары
> милионов записей из этих десятков милионов, попадающих в ту или иную сеть?
> И смысл тогда вообще в сборе этой статистики и в существовании этой базы?
Это сырые данные, и нужны они в случае каких-то разборок (я по ним,
например, в свое время машины, зараженные msblast, ловил). Да, запросы
выполняются долго. Hо из сырых данных в бинарниках они тоже будут не
быстрые. А пользователям показываются данные из другой таблицы, где все
в аггрегированном состоянии. А по той таблице - чуть больше, чем 4,2
миллиона записей, почасовые данные для каждого адреса из сети /24 на
вход и выход, пакеты и байты, с апреля 2003 года, суммирование с
группировкой по адресу выполняется за 67 секунд. Hадо бы ужать
детализацию до суток, да никак руки не дойдут.
--
Константин Стефанов
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
