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

Question

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

У меня есть:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 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 (единственным ограничением будет общий размер и производительность базы данных)

Answer 2

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

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

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

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

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