Массовое сохранение пользовательского интернет-трафика

DriveИзвестно, что по каналам Интернета ходит большой объём пользовательского трафика, который, при непрерывной записи, сложно полностью хранить (в течение длительного времени). Предположим, что гигабитный канал, имеющий усреднённую загрузку 80%, генерирует около 290 гигабайт “полезного” трафика в час. Это примерно 7 терабайт в сутки, то есть, если мы используем хранилище данных в 1000 терабайт (несколько тысяч жёстких дисков, несколько стоек в дата-центре), его не хватит и на полгода.

В приведённом выше расчёте не учитывается служебная информация, которая обеспечивает доставку пакетов по каналам связи. Не учитывается из предположения, что для целей записи трафика – она и не требуется. Естественно, несложно привести в пример случаи, когда требуется весь трафик, включая чисто техническую часть. То есть, объём хранения определяют цели. Если целью является наблюдение за пользовательской активностью, то можно подняться в сетевой модели на уровень приложений и принять во внимание тот факт, что существенную долю в интернет-трафике занимает тиражирование одних и тех же объектов. Например, это код веб-страниц, файлы изображений, видеоролики. Это позволяет сильно снизить требования по объёму.

Пусть пользователи просматривают популярный ролик на YouTube. Ролик не изменяется, соответственно, если его экземпляр есть в базе данных нашей исследующей трафик системы, то все пользовательские сеансы можно “сжать” до пары значений: “пользователь имярек – посмотрел ролик с индексом N”. Теперь данные миллиона пользователей, которые трафиком заполняют многие гигабиты, в хранилище уместятся в десяток мегабайтов. Хорошая экономия. То же самое касается веб-ресурсов: если имеется слепок состояния страниц (это, примерно, поисковый индекс), то можно сохранять лишь информацию об успешном доступе к веб-странице. То есть, вместо подробного трафика сохраняется глобальный лог действий с обнаруженными в Сети объектами.

Конечно, такая система, записывающая большие объёмы трафика, должна иметь некий кеш, в который попадает необработанный трафик: детально разбирать трафик на лету – слишком сложно. А основная проблема кроется в том, как именно за разумное время сопоставлять пользовательские действия с накопленной базой объектов. Причём, трудность не в самом поиске в базе, а в идентификации отдельных пользователей.

Адрес записки: https://dxdt.ru/2013/06/17/5930/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 5

  • 1 <t> // 17th June 2013, 17:17 // Читатель jno написал:

    дык, вроде, пользователей можно и “потом” идентифицировать…
    типа, IP-адрес сопоставить человеку часто можно по биллингу ISP, которые придут своим чередом.

    так что, от задач зависит не только плотность “упаковки”, но и оперативность (или масштаб реального времени, если об нём спич вообще идёт)

  • 2 <t> // 17th June 2013, 19:41 // Читатель зашел в гости написал:

    А мне, если честно, не совсем понятно, зачем вообще такие записи. По-моему, особый интерес представляет активность экстремистов, педофилов, пиратов, и т.д. Вероятность того, что на каком-то сервере по пол-года будет лежать детская порнография, приближается к нулю. Смысл?

  • 3 <t> // 17th June 2013, 23:03 // Читатель Z.T. написал:

    >>1000 терабайт (несколько тысяч жёстких дисков<<

    2TB = 100 USD (retail): http://www.newegg.com/Product/Product.aspx?Item=N82E16822148910

  • 4 <t> // 17th June 2013, 23:22 // Читатель зашел в гости написал:

    это на один гигабитный канал – $50к. А сколько таких каналов?

  • 5 <t> // 18th June 2013, 00:09 // Читатель jno написал:

    кто ж их по розничным-то берёт :)