Предложения по базам данных для временных рядов событий

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

У меня есть:

  • Около 400 000 000 дискретных событий на данный момент

  • Около 600 ГБ данных, которые будут сохранены в БД

Эти события бывают разных форматов, но я считаю, что количество индивидуальных атрибутов составляет около 5000. Большинство событий содержат только значения около 100 атрибутов. Значения атрибутов должны рассматриваться как произвольные строки, а в некоторых случаях - целые числа.

События в конечном итоге будут объединены в один временной ряд. Хотя у них есть какая-то внутренняя структура, нет ссылок на другие события, которые, я считаю, означает, что мне не нужна объектная БД или какая-то система ORM.

Мои требования:

  • Лицензия с открытым исходным кодом - мне, возможно, придется немного подкорректировать ее.

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

  • Быстрые запросы - обновления не так критичны.

  • Зрелые драйверы/привязки для C/С++, Java и Python. Предпочтительно с лицензией, которая хорошо сочетается с другими людьми - я бы предпочел не брать на себя что-либо из-за технического решения. Я думаю, что у большинства драйверов DB нет проблем, но в любом случае это нужно упомянуть.

  • Доступность для Linux.

  • Было бы неплохо, но не обязательно, если бы он был доступен для Windows

Моя идеальная БД для этого позволит мне получить все события за определенный период времени с помощью одного запроса.

То, что я нашел/рассмотрел до сих пор:

  • Postgresql с увеличенным размером страницы, по-видимому, может иметь до 6 000 столбцов в каждой таблице. Если моя оценка количества атрибутов не выключена, это может сделать.

  • MySQL, кажется, имеет ограничение 4000 столбцов на таблицу. Я мог бы использовать несколько таблиц с немного SQL-fu, но я бы предпочел не.

  • MongoDB - это то, к чему я сейчас склоняюсь. Это позволило бы мне сохранить внутреннюю структуру событий, все еще будучи в состоянии запросить их. Его API также кажется довольно прямым. Я понятия не имею, насколько хорошо он работает по производительности - хотя бы на одном сервере.

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

  • Используйте HBase напрямую. Это может соответствовать моим требованиям лучше, чем OpenTSDB, хотя, судя по моему прошлому опыту с hadoop, административные накладные расходы, вероятно, все же выше, чем первые три варианта.

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

PS: У меня только минимальный опыт работы в качестве администратора БД, поэтому я приношу свои извинения за любые заблуждения.

ОТВЕТЫ

Ответ 1

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

Вы должны сначала изучить преобразование своей структуры данных из этого:

table_1
-------
event_id
attribute_1
attribute_2
[...]
attribute_5000

в нечто подобное:

table_1          event_values             attributes
--------         ------------             ----------
event_id         event_id                 attribute_id
                 attribute_id             attribute_type
                 attribute_value

который может использоваться с любой RDMS (единственным ограничением будет общий размер и производительность базы данных)

Ответ 2

Вероятно, очень поздно для ответа, но вот что я делаю.

Я использую HDF5 как репозиторий временных рядов. Он имеет ряд эффективных и быстрых стилей сжатия, которые можно смешивать и сопоставлять. Он может использоваться с несколькими языками программирования. Он доступен как для Windows, так и для Linux.

Я использую boost:: date_time для поля timestamp. Это позволяет использовать большое количество вычислений на основе даты и времени.

В финансовой сфере я создаю конкретные структуры данных для каждого из баров, тиков, сделок, котировок,...

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