мне данное решение или нет. Читая описание, сложилось ощущение, что может не подойти.
У меня задача писать в бд раз в n(предположим минуту) большой объем данных(статистику от IoT устройств). Значения для столбцов думаю могут превышать 60 байт и достигать килобайт.(За сутки будут проходить гигабайты данных)
Далее хочется на основании этой информации выводить всякие графики(В идеале data len прикрутить)
Но вот информация для графиков не выглядит, как мало столбов, много колонок. Похоже, что это будет много столбцов(сотни, тысячи, может больше), но в сравнении с общим кол-вом столбцов это должно быть мало.
Таким образом нарушаются вот эти рекомендации
- подавляющее большинство запросов - на чтение;
- при чтении, вынимается достаточно большое количество строк из БД, но только небольшое подмножество столбцов;
- значения в столбцах достаточно мелкие - числа и небольшие строки (пример - 60 байт на URL)
- при чтении, вынимается достаточно большое количество строк из БД, но только небольшое подмножество столбцов
При нарушении данных рекомендаций, я довольно сильно в производительности потеряю?
не парься, пиши, потом разберёшься. Любой другой SQL сервер ты этим просто убьёшь
Есть варик посмотреть в сторону InfluxDB например, но его нет в поддержке дата лен(
тогда это не варик :) ещё можно подумать точно ли все значения нужны с такой частотой
Да, тоже думали об этом. Получается, что для аналитики такая частота действительно выглядит избыточной. Но так или иначе хочется хранить все события с такой частотой где либо.
timescaledb попробуйте - это PostgreSQL как раз для IoT данных timeseries
Вроде как постгря плохо перерабатывает такой объем данных за сутки
ну так это не постгря, а отдельный большой коммерческий форк для работы с timeseries - данными, оно оптимизировано под это
Посмотрю подробнее, спасибо
Обсуждают сегодня