powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Огромная и быстрорастущая таблица.
25 сообщений из 27, страница 1 из 2
Огромная и быстрорастущая таблица.
    #38456509
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Дано:
Существует база MySQL, в ней одна таблица. В эту таблицу некий сервис, один раз в сутки сбрасывает статистику всех подключений из локальной сети во вне и наоборот, предположительно с какого-то центрального роутера. В таблице есть поля:

id | unix_secs | doctets | srcaddr | dstaddr | srcport | dstport
Где:
id - автроинкрементарный id
unix_secs - юникс время
doctets - трафик предположительно в байтах
srcaddr - исходящий ip
dstaddr - целевой ip
srcport - исходящий порт
dstport - целевой порт

Ну так вот, таблица с данными за 2 месяца содержит 78,762,715 строк и весит 4.3 ГБ. В таблицу заносится каждое соединение. Поэтому за сутки с одного локального IP записываются тысячи строк соединений во вне и из вне. Хотя локальных ip в районе 250. К примеру за один день на мой комп из вне было 19532 подключений, т.е. это даунлоад трафик, где с одного, где с разных ip.
Задача:
Нарисовать на php какой нибудь сервис статистики, дабы можно было глянуть и увидеть с каких ip более всего трафика ушло/пришло, т.е. кто больше всего грузит канал. Но есть одна проблема.
Проблема:
Проблема в том что база растёт на глазах. Запрос с выборкой по конкретному ip и дате выполняется около минуты. А через n месяцев табличка будет весить n Гб и обрабатываться неизвестно как долго. Поэтому от такого количества данных необходимо избавляться!
Решение:
То что первое пришло в голову. К примеру, кроном будет запускаться раз в сутки какой нибудь скрипт, который будет выбирать данные по каждому локальному ip, суммировать их и класть в другую таблицу, где вместо тысяч строк из старой таблицы, будет одна, а обработанные строки в старой таблице будут удаляться.
Вопрос:
Посоветуйте пожалуйста, как можно поступить в данной ситуации более гибко/правильно/грамотно? Спрашиваю ибо мало опыта. Предлагать настроить по человечески тот сервис который сбрасывает статистику бесполезно.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456530
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1) Покажите настоящий DDL таблицы.

2) Решение с предварительной агрегацией правильное. Нужно только определиться со значениями шага агрегации. Т.е. возможно достаточно будет вести табличку с агрегацией по дням. А может придется агрегировать по минутам.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456540
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh78,762,715 строк и весит 4.3 ГБЧто-то многовато. Это примерно 54 байта на запись.
Тогда как примерный подсчет дает 4+4+8+4+4+2+2=28 байт на запись.
Движок таблицы какой?
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456546
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft1) Покажите настоящий DDL таблицы.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CREATE TABLE `raw` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `unix_secs` int(11) unsigned NOT NULL DEFAULT '0',
 `doctets` int(11) unsigned NOT NULL DEFAULT '0',
 `srcaddr` varchar(15) NOT NULL DEFAULT '0',
 `dstaddr` varchar(15) NOT NULL DEFAULT '0',
 `srcport` smallint(5) unsigned NOT NULL DEFAULT '0',
 `dstport` smallint(5) unsigned NOT NULL DEFAULT '0',
 PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=78762716 DEFAULT CHARSET=latin1
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456554
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftДвижок таблицы какой?

MyISAM если об этом речь.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456556
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh Проблема:
Проблема в том что база растёт на глазах. Запрос с выборкой по конкретному ip и дате выполняется около минуты. А через n месяцев табличка будет весить n Гб и обрабатываться неизвестно как долго. Поэтому от такого количества данных необходимо избавляться!


Мужик, если у тебя запрос к табличке в 78 миллионов строк работает около минуты, тебе нужно РАДОВАТЬСЯ, что так быстро работает.

sdfghsdfh Решение:
То что первое пришло в голову. К примеру, кроном будет запускаться раз в сутки какой нибудь скрипт, который будет выбирать данные по каждому локальному ip, суммировать их и класть в другую таблицу, где вместо тысяч строк из старой таблицы, будет одна, а обработанные строки в старой таблице будут удаляться.


Предагрегация. Нормально. Главное -- неуагрегировать данные так, что они потом будут неюзабельны.
Для этого надо чётко себе представлять задачи, для которых это всё организуется.

sdfghsdfh Вопрос:
Посоветуйте пожалуйста, как можно поступить в данной ситуации более гибко/правильно/грамотно? Спрашиваю ибо мало опыта. Предлагать настроить по человечески тот сервис который сбрасывает статистику бесполезно.

Да ничего там особенно сложного нет. Берёшь данные, выкидываешь ненужные параметры, и время сжимаешь в более крупные куски. Главное -- ещё раз -- чётко представлять ЗАЧЕМ всё это нужно, и не выкинуть лишние данные.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456563
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh
Код: sql
1.
2.
`srcaddr` varchar(15) NOT NULL DEFAULT '0',
 `dstaddr` varchar(15) NOT NULL DEFAULT '0',

***! храните в интах и юзайте INET_ATON()/INET_NTOA()
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html
sdfghsdfh
Код: sql
1.
 `unix_secs` int(11) unsigned NOT NULL DEFAULT '0',

ещё раз ***! для кого timestamp придумали?
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456566
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh,

Почему doctets int(11) ? А если сессия больше 4 Гб будет?

`srcaddr` и `dstaddr` переделывайте на int unsigned, они будут по 4 байта занимать.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456573
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirи юзайте INET_ATON()/INET_NTOA()
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html А еще лучше всю трассу движения данных от оборудования до таблицы переделать на 4-х байтовые числа.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456574
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivДа ничего там особенно сложного нет. Берёшь данные, выкидываешь ненужные параметры...
Я было подумал что может в природе есть решения, кроме как написать скрипт.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456577
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh,

ну какие могут "в природе" быть "решения" для вашей частной задачи?
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456579
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE `raw` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `unix_secs` int(11) unsigned NOT NULL DEFAULT '0',
 `doctets` int(11) unsigned NOT NULL DEFAULT '0',
 `srcaddr` varchar(15) NOT NULL DEFAULT '0',
 `dstaddr` varchar(15) NOT NULL DEFAULT '0',
 `srcport` smallint(5) unsigned NOT NULL DEFAULT '0',
 `dstport` smallint(5) unsigned NOT NULL DEFAULT '0',


Получается так, что тут особенно и выкидывать нечего. srcaddr,srcport определяют источник, dstaddr,dstport -- приёмник.
На самом деле, если анализировать протоколы (один из портов, чисто теоретически) и номера портов, то можно один из портов викидывать, тот, который динамический (более 16000). Потому что они как раз НЕ идентифицируют приёмник, они будут разными для разных сессий, а по сути это одно и то же.

Далее unix_secs надо превращать в дату и время и укрупнять по периодам, doctets -- суммировать.
А больше тут выбрасывать и нечего.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456583
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tanglirsdfghsdfh,

ну какие могут "в природе" быть "решения" для вашей частной задачи?

Я решил что задача с уменьшением объёма таблицы не такая уж и редкая.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456584
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfhMasterZivДа ничего там особенно сложного нет. Берёшь данные, выкидываешь ненужные параметры...
Я было подумал что может в природе есть решения, кроме как написать скрипт.Классических решений два:
1) Писать данные в промежуточную таблицу. По расписанию/периодически читать данные из это таблицы, агрегировать их и писать в таблицы-агрегаты, затем удалять обработанный фрагмент из исходной таблицы.
2) Писать данные в промежуточную таблицу (на всякий случай, или даже не писать вовсе) и одновременно писать/обновлять в таблицы-агрегаты.

Оба варианта имеют подварианты и свои плюсы/минусы.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456588
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftsdfghsdfhпропущено...

Я было подумал что может в природе есть решения, кроме как написать скрипт.Классических решений два:
1) Писать данные в промежуточную таблицу. По расписанию/периодически читать данные из это таблицы, агрегировать их и писать в таблицы-агрегаты, затем удалять обработанный фрагмент из исходной таблицы.
2) Писать данные в промежуточную таблицу (на всякий случай, или даже не писать вовсе) и одновременно писать/обновлять в таблицы-агрегаты.

Оба варианта имеют подварианты и свои плюсы/минусы.

Спасибо огромное!
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456590
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfhmiksoftпропущено...
Классических решений два:
1) Писать данные в промежуточную таблицу. По расписанию/периодически читать данные из это таблицы, агрегировать их и писать в таблицы-агрегаты, затем удалять обработанный фрагмент из исходной таблицы.
2) Писать данные в промежуточную таблицу (на всякий случай, или даже не писать вовсе) и одновременно писать/обновлять в таблицы-агрегаты.

Оба варианта имеют подварианты и свои плюсы/минусы.

Спасибо огромное!Да не за что. Первый вариант - это фактически ваш изначальный вариант.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456598
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Други! Огромное вам спасибо! По сути вопрос закрыт. Спасибо всем так оперативно откликнувшимся! Всем лучи добра!
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456604
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfhПо сути вопрос закрыт.Не торопитесь, подводные камни еще остались.
Так что приходите еще :)
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456624
sdfghsdfh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftsdfghsdfh,

Почему doctets int(11) ? А если сессия больше 4 Гб будет?



Вот максимальное значение (SELECT MAX( doctets ) FROM raw) этого поля со всей таблицы: 88956519 за 2 месяца наблюдения. Тут я тоже не пойму как так, по идее тут должна быть цифра объёма переданных данных за одну сессию, т.е. числа должны быть большими, хоть гигабайты. Есть идеи почему так?
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38456634
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfhmiksoftsdfghsdfh,

Почему doctets int(11) ? А если сессия больше 4 Гб будет?



Вот максимальное значение (SELECT MAX( doctets ) FROM raw) этого поля со всей таблицы: 88956519 за 2 месяца наблюдения. Тут я тоже не пойму как так, по идее тут должна быть цифра объёма переданных данных за одну сессию, т.е. числа должны быть большими, хоть гигабайты. Есть идеи почему так?Ну это зависит от системы. Если, например, это небольшой сайт, на котором просто нет больших файлов и вообще информации немного, то неудивительно.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38457247
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfhmiksoftsdfghsdfh,

Почему doctets int(11) ? А если сессия больше 4 Гб будет?



Вот максимальное значение (SELECT MAX( doctets ) FROM raw) этого поля со всей таблицы: 88956519 за 2 месяца наблюдения. Тут я тоже не пойму как так, по идее тут должна быть цифра объёма переданных данных за одну сессию, т.е. числа должны быть большими, хоть гигабайты. Есть идеи почему так?У меня есть устойчивое подозрение, что собираете Вы данные о траффике по технологии netflow . Соответственно, и каждая запись в таблице - не "сессия" (одна закачка), а отдельный "flow" (комбинация адресов источника и назначения, входящего и исходящего портов и т.п.), котрых на одну "сессию" может быть множество и по которым на "умном" рутере выполняется агрегация отдельных ip-пакетов. Для сбора этих данных ограничивается объем выделенной памяти и интервал агрегации. По этим событиям накопленный набор данных о проходящем трафике сбрасывается на коллектор... Ну, и так далее...

Кстати, Ваш 2-х месячный объем данных - это примерно половина 5-минутного "среза", который "проходит" в нашей системе. Коллектор складывает исходные данные netflow в файлы на диске, по которым проходит агрегатор. Агрегированные данные выкладываются (в гораздо меньшем количестве записей) в таблицу БД, а исходные файлы сохраняются "для истории"...

ЗЫ. Еще у Вас прозвучало что-то про "нагрузку на канал"... В принципе, для этого дела неплохо подходит MRTG - с "историей" и графиками...
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38457248
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sphinx_mvsdfghsdfhmiksoftПочему doctets int(11) ? А если сессия больше 4 Гб будет?Вот максимальное значение (SELECT MAX( doctets ) FROM raw) этого поля со всей таблицы: 88956519 за 2 месяца наблюдения. Тут я тоже не пойму как так, по идее тут должна быть цифра объёма переданных данных за одну сессию, т.е. числа должны быть большими, хоть гигабайты. Есть идеи почему так?У меня есть устойчивое подозрение, что собираете Вы данные о траффике по технологии netflow .Забыл сказать: в netflow поле doctets - 32-битное беззнаковое целое. Поэтому int(11) - достаточно.
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38457258
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sdfghsdfh,

полезно просто почитать про ОЛАП, ДатаВерХаусе,
дименшены, факты, снежинки, ETL, дрил-дауны,
и так далее.

Может быть, (а може и нет) вас заинтересует что-то
типа такого (из Гугла):

http://sourceforge.net/projects/phpmyolap/?source=directory

Если побыстрому, то подход обычный :
от простого к сложному:

1. берете 5-10 самых частоиспользуемых тяжелых запросов

2. делаете из них create table st_trafic_daily as select.....

3. анализируете и понимаете что этой таблице
надо просто добавлять результат прошедшего дня,
можно ночью.

4. Если что надо живое -- анализируете делаете так что
живые данные (скаже за последние несколько дней)
всегда есть в быстром доступе

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

6. далее увидуте размерность по лоцализации трафика:
ИП, ЛАН,..... организация, компания, может на ГЕО размерность выйдете
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38457542
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Получается так, что тут особенно и выкидывать нечего.

много чего можно удалить, но товарищ полковник будет против. если бы не они, провайдеры бы значительно меньше мучились.
sphinx_mvЗабыл сказать: в netflow поле doctets - 32-битное беззнаковое целое. Поэтому int(11) - достаточно.
так вот кто тормозит внедрение ipv6!
...
Рейтинг: 0 / 0
Огромная и быстрорастущая таблица.
    #38457604
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netwindsphinx_mvЗабыл сказать: в netflow поле doctets - 32-битное беззнаковое целое. Поэтому int(11) - достаточно.так вот кто тормозит внедрение ipv6! Ну, и при чем тут ipv6?!
Это же количество байт , переданных в "потоке"! А нужно смотреть на поля адресов источника и назначения.
Поддержка ipv6 уже есть в netflow 9-ой версии - нужно еще, чтобы используемый коллектор netflow поддерживал эту версию...
...
Рейтинг: 0 / 0
25 сообщений из 27, страница 1 из 2
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Огромная и быстрорастущая таблица.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]