Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Огромная и быстрорастущая таблица. / 25 сообщений из 27, страница 1 из 2
07.11.2013, 16:38:55
    #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
07.11.2013, 16:43:58
    #38456530
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
1) Покажите настоящий DDL таблицы.

2) Решение с предварительной агрегацией правильное. Нужно только определиться со значениями шага агрегации. Т.е. возможно достаточно будет вести табличку с агрегацией по дням. А может придется агрегировать по минутам.
...
Рейтинг: 0 / 0
07.11.2013, 16:47:58
    #38456540
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
sdfghsdfh78,762,715 строк и весит 4.3 ГБЧто-то многовато. Это примерно 54 байта на запись.
Тогда как примерный подсчет дает 4+4+8+4+4+2+2=28 байт на запись.
Движок таблицы какой?
...
Рейтинг: 0 / 0
07.11.2013, 16:53:42
    #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
07.11.2013, 16:57:26
    #38456554
sdfghsdfh
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
miksoftДвижок таблицы какой?

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


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

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


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

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

Да ничего там особенно сложного нет. Берёшь данные, выкидываешь ненужные параметры, и время сжимаешь в более крупные куски. Главное -- ещё раз -- чётко представлять ЗАЧЕМ всё это нужно, и не выкинуть лишние данные.
...
Рейтинг: 0 / 0
07.11.2013, 17:00:00
    #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
07.11.2013, 17:00:22
    #38456566
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
sdfghsdfh,

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

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

ну какие могут "в природе" быть "решения" для вашей частной задачи?
...
Рейтинг: 0 / 0
07.11.2013, 17:05:33
    #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
07.11.2013, 17:06:37
    #38456583
sdfghsdfh
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
tanglirsdfghsdfh,

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

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

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

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

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

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

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

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

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



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

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



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

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



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

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

ЗЫ. Еще у Вас прозвучало что-то про "нагрузку на канал"... В принципе, для этого дела неплохо подходит MRTG - с "историей" и графиками...
...
Рейтинг: 0 / 0
08.11.2013, 03:21:11
    #38457248
sphinx_mv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
sphinx_mvsdfghsdfhmiksoftПочему doctets int(11) ? А если сессия больше 4 Гб будет?Вот максимальное значение (SELECT MAX( doctets ) FROM raw) этого поля со всей таблицы: 88956519 за 2 месяца наблюдения. Тут я тоже не пойму как так, по идее тут должна быть цифра объёма переданных данных за одну сессию, т.е. числа должны быть большими, хоть гигабайты. Есть идеи почему так?У меня есть устойчивое подозрение, что собираете Вы данные о траффике по технологии netflow .Забыл сказать: в netflow поле doctets - 32-битное беззнаковое целое. Поэтому int(11) - достаточно.
...
Рейтинг: 0 / 0
08.11.2013, 03:43:35
    #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
08.11.2013, 11:23:14
    #38457542
netwind
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромная и быстрорастущая таблица.
MasterZiv
Получается так, что тут особенно и выкидывать нечего.

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


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