Как эффективно хранить данные больших временных рядов?

Мне нужно хранить и иметь возможность запрашивать некоторые очень большие объемы данных временных рядов.

Свойства данных следующие:

количество серий: около 12.000 (двенадцать тысяч)
количество точек данных во всем мире: около 500 000 000 в месяц (пятьсот миллионов)
типы смешанных значений: большинство точек данных являются значениями с плавающей точкой, остальные являются строками
период выборки: переменная между сериями, а также внутри серии
метки времени: точность в миллисекундах
срок хранения данных: несколько лет, без разложения или понижающей выборки
архивы данных должны быть построены почти в реальном времени, но приемлемая задержка (~ 1 час) приемлема
прошлые данные могут быть восстановлены при необходимости, но с высокой стоимостью
иногда, но довольно редко, некоторые прошлые данные требуют обновления

Свойства предполагаемых запросов:

большинство запросов к данным будет основано на метках времени; от одного дня до нескольких месяцев / лет. 90% + будут запросы по самым последним данным

Другие требования:

решение должно быть бесплатным как в бесплатном пиве и желательно с открытым исходным кодом

Моя первоначальная мысль заключалась в том, чтобы использовать PyTables / Pandas с файлами HDF5 в качестве хранилища данных вместо базы данных SQL.

Вопросов :

Предполагая, что PyTables / Pandas - это «лучший» маршрут, было бы лучше разделить данные на несколько файлов HDF, каждый из которых охватывает определенный период времени, или поместить все в один файл, который затем станет огромным?
Должен ли я пойти и предпочесть фиксированный или табличный формат? Для меня фиксированный формат выглядит нормально, если я сохраняю один файл HDF в месяц, так как, таким образом, целая серия, вероятно, помещается в ОЗУ, и я могу разрезать в памяти, не нуждаясь в индексе формата таблицы. Я прав ?

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

Другие подходы, которые я рассмотрел:

Базы данных массива: они превосходно подходят для временных рядов с постоянным периодом выборки, так как тогда вам нужно только сохранить время начала и окончания и период выборки массива, а затем только значения в самом массиве и индексирование легко. Но с переменными периодами выборки внутри самих рядов мне нужно поддерживать более тесное отношение timestamp-> value, которое, на мой взгляд, не очень подходит для массивов СУБД.
стандартная база данных SQL с меткой времени, paramID, значением в виде столбцов, но по своей природе они запрашивают много дискового ввода-вывода для любого запроса

database python performance

— flyingmig
источник

Вы должны рассмотреть базы данных массива - en.wikipedia.org/wiki/Array_DBMS#List_of_Array_DBMS . Я не говорю, что один из них будет правильным, или даже лучшим или даже достаточно хорошим ответом, просто они должны войти в ваши мысли. Помимо записей в этом списке есть система kdb ( kx.com ), хотя она далеко не бесплатна.

— Высокая производительность Марк

Спасибо за ваш вклад. Я рассмотрел базы данных массивов, но проблема, с которой я столкнулся, заключается в том, что они идеально подходят для временных рядов с постоянным периодом выборки, поскольку вам нужно только сохранить время начала и окончания и период выборки массива, а затем только значения в сам массив и индексация просты. Но с переменными периодами выборки внутри самих рядов мне нужно поддерживать более тесное отношение timestamp-> value, которое, на мой взгляд, не очень подходит для массивов СУБД. С учетом сказанного, я был бы рад оказаться неправым.

— flyingmig

редактирование вопроса, чтобы добавить то, что я рассмотрел до сих пор

— flyingmig

Вопрос: нужно ли хранить все данные? Могут ли данные со временем затухать и / или существует ли приемлемый уровень точности для рядов с плавающей запятой?

— J Trana

@ moinuddin-quadri В итоге я использовал объекты DataFrame от pandas, поддерживаемые ежемесячными файлами HDF5 в табличном формате. Система работает уже более года и работает очень стабильно и быстро, даже не используя SSD-диски. Я постараюсь написать все это как ответ, когда у меня будет время. Остальное не стесняйтесь PM мне.

— flymig

Ответы:

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

Чтобы дать вам представление о том, насколько хорошо он масштабируется, когда графит был впервые запущен в производство на Orbitz, он обрабатывал 160 000 метрик в минуту .

— Брайан Оукли
источник

Спасибо за предложение, но, насколько я понимаю, шепот не подходит, потому что его точность - вторая, когда мне нужна точность в миллисекундах, и, как вы правильно заметили, у меня есть и строковые данные, которые не могут быть сохранены там.

— flyingmig

@flyingmig Не пиши шепотом так быстро. Его временные метки являются значениями эпох Unix. И «строковые данные», которые вы описали в этом вопросе, больше похожи на перечисления, и они обычно хранятся в виде небольших целочисленных значений.

— Росс Паттерсон

Sears использует Carbon / Graphite / Ceres для хранения 4M + уникальных точек данных в минуту. Он не идеален и требует кластеризации графита и SSD, но работает. Все остальные решения не масштабируются до этого уровня, который мы нашли, но если у вас есть идеи, не стесняйтесь вмешиваться.

— Кевин Дж. Райс

InfluxDB - это база данных с открытым исходным кодом, написанная на Go. Он был написан специально для обработки данных временных рядов, и они опубликовали тесты, показывающие гораздо лучшую производительность по сравнению с Cassandra :

InfluxDB превзошел Cassandra во всех трех тестах, увеличив пропускную способность записи в 4,5 раза, при этом занимая в 10,8 раза меньше дискового пространства и обеспечивая в 168 раз более быстрое время отклика для проверенных запросов.

— Дан Дакалеску
источник

Возможно, вы захотите оформить ориентированные на столбцы базы данных. Я не уверен, что вы подразумеваете под массивными базами данных, но с моим предложенным подходом вы можете иметь динамическое число значений за период времени. Вы также можете иметь несколько значений для одной и той же отметки времени. Интересно то, что если у вас есть значения, измеренные в одной и той же отметке времени, вы можете сохранить их в виде дополнительных столбцов (например, датчик, который измеряет температуру и влажность, цену торговли акциями и размер сделки, ...). Из-за ориентированной на столбцы природы вы можете иметь таблицы с 100 столбцами, но если ваш запрос обращается только к пяти столбцам, база данных считывает только данные пяти столбцов.

Я написал серию о создании вашей собственной базы данных временных рядов, вы можете взглянуть на нее:

— hellomichibye
источник