Предложения базы данных для временных рядов событий
В одном из моих проектов мне нужно ввести в базу данных огромную коллекцию событий для последующей обработки, и я пытаюсь решить, какая СУБД лучше всего подойдет для моей цели.
У меня:
Около 400 000, 000 дискретных событий на данный момент
Около 600 ГБ данных, которые будут храниться в БД
Эти события бывают разных форматов, но я оцениваю количество отдельных атрибутов примерно в 5000. Большинство событий содержат значения только примерно для 100 атрибутов каждое. Значения атрибутов следует рассматривать как произвольные строки и, в некоторых случаях, как целые числа.
События в конечном итоге будут объединены в единый временной ряд. Хотя у них есть некоторая внутренняя структура, нет никаких ссылок на другие события, что, я считаю, означает, что мне не нужна объектная БД или какая-то система ORM.
Мои требования:
Лицензия с открытым исходным кодом - Я возможно, придется его немного подправить.
Масштабируемость за счет возможности расширения до нескольких серверов, хотя сначала будет использоваться только одна система.
Быстрые запросы - обновления не так важны.
Зрелые драйверы / привязки для C / C ++, Java и Python. Желательно с лицензией, которая хорошо сочетается с другими - я бы предпочел не связывать себя чем-либо из-за технического решения. Я думаю, что у большинства драйверов БД здесь нет проблем, но об этом все равно следует упомянуть.
Доступность для Linux.
Было бы неплохо, но не обязательно, если бы она была доступна и для Windows
Моя идеальная БД для этого позволила бы мне получить все события за указанный период времени с помощью одного запроса.
То, что я нашел / рассмотрел до сих пор:
Postgresql с увеличенным размером страницы, очевидно, может иметь до 6000 столбцов в каждой таблице. Если моя оценка количества атрибутов не отключена, это могло бы быть.
MySQL , кажется, имеет ограничение в 4000 столбцов на таблицу. Я мог бы использовать несколько таблиц с небольшим количеством SQL-fu, но я бы не стал этого делать.
MongoDB - это то, к чему я сейчас склоняюсь. Это позволило бы мне сохранить внутреннюю структуру событий, но при этом иметь возможность запрашивать их. Его API также кажется довольно простым. Я понятия не имею, насколько хорошо он работает с точки зрения производительности - по крайней мере, на одном сервере.
OpenTSDB и его структура сбора метрик звучат интересно. Я мог бы использовать один временной ряд для каждого атрибута (который может помочь с некоторые из моих обработок), имеют значение атрибута как тег и дополнительно помечают записи, чтобы связать их с конкретным событием. Вероятно, у него более крутая кривая подготовки, чем у трех вышеупомянутых, как с точки зрения администратора, так и с точки зрения прикладного программиста. Понятия не имею о его производительности.
Используйте HBase напрямую. Это могло бы соответствовать моим требованиям лучше, чем OpenTSDB , хотя - судя по моему прошлому опыту работы с hadoop - накладные расходы на администрирование, вероятно, все же выше, чем первые три варианта.
Вероятно, есть другие базы данных, которые могли бы это сделать. , поэтому дайте мне знать - я буду признателен за любые предложения или комментарии, которые могут помочь мне в этом.
PS: У меня минимальный опыт работы в качестве администратора БД, поэтому я прошу прощения за любые неправильные представления.