Как лучше хранить данные о трафике в БД?

Question

[Dmmitry]

Здравствуйте!

Нужно хранить в mysql БД данные о трафике. Каждая запись может иметь значение от 100 байтов до 100 терабайтов. С этими записями будут производиться различные действие, например, суммирование и тд.

Подскажите, как лучше хранить все это дело в базе? Я думал хранить в одной величине, например, в байтах, но что-то слишком большие цифры получаются.

Answer 1

[Евгений Вольф]

Подскажите, как лучше хранить все это дело в базе? Я думал хранить в одной величине, например, в байтах, но что-то слишком большие цифры получаются.

Если эти числа не выходят за максимальный допустимый размер (диапазон), например 9223372036854775807 - знаковое, 18446744073709551615 - без знаковое BIGINT, то скорее всего, ничего лучше, для хранения чисел (чем специальный тип БД, предназначенный для хранения именно чисел) - Вы не найдете.

P.S. Если нужна точность до байт - хранить нужно в байтах. Если до мегабайт - соотв. округлять значения и хранить в мегабайтах. Т.е., в зависимости от необходимой точности можно выбрать конечную величину. Обработка больших цифр (целочисленных) - для компьютера не есть проблема, числа обрабатываются в ряде случаев, лучше чем например, текст.

Comments

[Freeman]

Добавлю еще, что проблема отображения больших чисел — надуманная. В большинстве случаев столбцы цифр терабайтов с точностью до байта не нужны, но округлять можно при выводе. Было бы что округлять.

При желании даже на уровне запроса можно выводить в разных единицах — через case when. И выбирать еще, в двоичных или десятичных килобайтах/мегабайтах считать. Главное — исходные цифры без потерь сохранить.

Answer 2

[Дмитрий Александров]

Храни как отдельные единицы. Т.е. для одной записи у тебя будут поля "терабайт" "гигабайт" "мегабайт" "байт" и напиши функции для преобразования в нужные тебе величины. Т.е. если ты добавляешь 1 мегабайт а у тебя уже в этой записи 1024 мегабайта то делаешь "терабайт"+1 , мегабайт =1. Отдельно функцию суммирования всех полей и т.д. Вообще лучше избегать работы и математики с огромными числами. Кроме того будет намного удобнее оперировать с округленными значениями. Если будете хранить все это одним полем то к примеру запись 1 терабайта будет 1e+12 байт что просто ужасно.

Comments

[Dmmitry]

я не против избежать работы с огромными числами) но по другому я не знаю как даже, нужно мониторить сколько трафика ушло на определенный ресурс

[Дмитрий Александров]

Дмитрий Чередниченко: Я же говорю как вариант можешь раскладывать по принципу как я выше описал. Проблема больших чисел в том что каждый ЯП, каждая функция в фремворки или собственная, каждый вызов вывода данных все это неизбежно приводит к ошибкам округления. Живой пример:
Mysql минимум -9,223,372,036,854,775,808 максимум 9,223,372,036,854,775,807 или при счете от
минимум 0 максимум 18,446,744,073,709,551,615
PHP минимум -2,147,483,648 максимум 2,147,483,647 или php 64 битный
минимум -9,223,372,036,854,775,808 максимум 9,223,372,036,854,775,807
Тоже самое происходит и с другими ЯП или форматами данных.

Намного проще упростить систему по рецепту выше =)

Answer 3

[rPman]

У вас проблема не с большими числами, bigint их решит, а большой объем данных, миллионы и миллиарды записей положат вашу базу и создадут охренительные проблемы в будущем
Поэтому сразу закладывайте партиционирование таблиц по интервалам времени, причем не обязательно средствами базы данных, достаточно самим создавать новую таблицу для каждого следующего временного интервала (недели, месяцы - зависит от вашей нагрузки).

почему вы хотите хранить простые линейные логи в БД?
что еще вам нужно делать с данными кроме фильтрации и суммы?

если всетаки храните в базе, то не создавайте индексов на такие поля как объем трафика и url, это наиглупейшая ошибка, во время записи в таблицу заранее считайте необходимые параметры, выделяйте важные данные из url, вычисляйте домен, ip (сегодня он один, завтра другой), собирайте суммы по трафику в отдельной табличке, если нагрузка позволяет, можете по ip считать (или по зонам), в итоге вы будете работать не с сырыми данными, а уже агрегированными и посчитанными, их на порядок меньше и они удобнее для использования.

Answer 4

[lega]

Хотите экономно? "Сворачивайте" на ходу и раскладывайте готовый результат по группам (отчетам).