ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Ilya Kulagin                         2:5020/871.18  25 Dec 2002  14:30:01
 To : Victor Sudakov
 Subject : Учет тpаффика
 -------------------------------------------------------------------------------- 
 

 
  >>  Гмм, не совсем. Ибо хранить _весь_ трафик слишком накладно. У нас работает
  >>  следующая схема:
  >>  весь траффик хранится месяц после выставления счета. Hа его основе 
  >> считается агрегированный за день, неделю, месяц, квартал трафик по 
  >> конкретному клиенту.
 
  VS> Детальную статистику следует хранить 8 месяцев, бухгалтерскую три года.
  VS> Я сейчас затрудняюсь привести точную ссылку, но это сведения из
  VS> Положения по автоматизированным системам расчетов.
 
 Хорошо. Предположим, я буду хранить записи такого вида:
 client_id (int, 4 байта)
 start_time (datetime year to second, 6 байт)
 end_time (datetime year to second, 6 байт)
 service_bytes (int, 4 байта)
 tarif1_bytes (int, 4 байта)
 tarif2_bytes (int, 4 байта)
 tarif3_bytes (int, 4 байта)
 
 с принудительным сбросом раз в 5 минут (т.е. если логон диалапщика произошёл в
 13:04, а логофф - в 13:11, то хранятся интервалы 13:04-13:05, 13:05-13:10 и
 13:10-13:11
 
 Четыре градации тарифов - это даже перебор, я ещё больше 3-х не видел. Итого,
 каждая запись = 32 байта
 каждому клиенту в сутки примерно не больше 12*24 - ну, скажем, 300 записей. Доля
 сумасшедших, звонящих раз в минуту и отцепляющихся после команды LIST на pop-е, 
 компенсируется звонящими раз в день на полтора часа.
 
 Допустим, постоянных (активных) клиентов в день 1000. Это не много, но и не так 
 уж мало.
 
 Итого прогнозируемый пиковый объем базы
 1000 клиентов * 32 байта * 300 записей * 30 суток * 8 месяцев
 итого 250 мегабайт. Что даже по меркам mysql - копейки. 
 
 В чём резюм. Да всё в том же. Лог отпарсили, мусор выкинули - и в базе
 появляется не по 500 записей в секунду, а по 100 в минуту в самом худшем
 случае...
 
 Касательно запросов по сбору статистики.
 Хранится статистика, естественно, вся. Hо есть ли смысл каждый раз каждому
 клиенту выдавать отчёт за все 8 месяцев? Вряд ли, я, как клиент, от такого
 авангардизма точно ошизею. Итого - отчёт даётся "за день (неделю, месяц) при
 условии работы в этот период" - и вот в такой постановке задачи и хранение в
 отдельной таблице итоговых результатов по (дням, неделям, месяцам), и
 оптимизация запросов (смотрим по таблице итогов - траффика не было, отчёт
 пропускаем; траффик был - отчёт собираем) - уже вполне нормально работают именно
 с базой.
 
 Примите уверения в совершеннейшем к Вам почтении
 /kiv
 
 --- QDed/FreeBSD
  * Origin: Moose 2:5020/871.18 (2:5020/871.18)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор