|
ru.cisco
- RU.CISCO ---------------------------------------------------------------------
From : Gennady Abramov 2:5020/400 01 Jun 2005 14:45:35
To : Constantin Stefanov
Subject : Re: netflow коллектор какой лучше
--------------------------------------------------------------------------------
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 обработает запрос на предмет суммирования пары
милионов записей из этих десятков милионов, попадающих в ту или иную сеть?
И смысл тогда вообще в сборе этой статистики и в существовании этой базы?
/BeSD wishes
--- ifmail v.2.15dev5.3
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
