Как лучше хранить график с большим количеством значений?

Question

[Виталий Кузнецов]

Здравствуйте, каким образом можно хранить график с большим кол-вом значений для каждой записи в mysql таблице?

Были варианты:
- Загонять в массив, прогонять через serialize, сохранять в БД
- Создать большое кол-во полей в таблице и хранить значения в этих полях

Задачи: переодически обновлять поля, полей около 186 для 1 записи(при этом сдвигать данные на 1 поле назад, а последнее дописывать новым значением), записей много(в этом и проблема. более 1000 записей).

P.S: оба варианта показались слишком нагруженными, гугление ничего не дало.

Просьба подсказать еще варианты(если вообще таковые имеются).

Comments

[Дмитрий Евграфович]

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

[Виталий Кузнецов]

Дмитрий Евграфович: примерное кол-во значений будет около 186 на 1 запись(записей, для начала около 1000), да, сортировку планируем, но до записи. Т.е каждое значение перезаписывается в прошлое, а в конец дописывается новое

Answer 1

[Artem Moseev]

Для мониторинга я бы посоветовал Graphite, есть готовые интерфейсы для визуализации накопленной статистики. Извлекать данные из хранилища можно в формате json, причем можно запрашивать уже в агрегированном виде.

Answer 2

[Станислав Макаров]

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

Comments

[Виталий Кузнецов]

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

[Станислав Макаров]

Виталий Кузнецов почему ресурсоемко? 186000 записей в одной таблице это чих даже для mysql. Разумеется, одна таблица на всех, а не на каждого))

Answer 3

[Павел Гоголинский]

serialize конечно. Большое количество полей - это очень нерасширяемое решение

Comments

[Виталий Кузнецов]

Просто проблема в том, что будет запись к примеру 186000 полей(186 * 1000 записей). Это же будет очень затратно на ресурсы? Или же нет?

[Павел Гоголинский]

Вот этого не понял (186 * 1000 записей). Что значат цифры?

[Muhammad]

Павел Гоголинский: 1000 записей и у каждой записи 186 полей

[Павел Гоголинский]

Ну так их умножать не нужно. будет тысяча строк, а 186 значений вы сериализуете в одну ячейку каждой строки

Answer 4

[ColdSpirit]

Запись в blob формате?

Comments

[Виталий Кузнецов]

Т.е гнать в serialize, а потом в blob?

[ColdSpirit]

Виталий Кузнецов: возможно, но думаю что serialize оставляет мусор, я бы просто оставил координаты через знаки разделители максимально компактно, может, если есть желание и возможность, еще заархивировать)

Answer 5

[Everything_is_not_so_bad]

Для хранения данных во времени можно использовать кольцевые (циклические) БД, такие как rrdtool.

Answer 6

[Виталий Кузнецов]

Спасибо всем, все-таки решили мы использовать JSON для таких целей(вроде не такая уж и нагрузка огромная оказалась)