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

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

У меня есть:

Около 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. Это позволяет использовать большое количество вычислений на основе даты и времени.

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

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