NoSQL для чтения временных рядов / зарегистрированных данных прибора, которые также версируются

Похоже, вы описываете один из наиболее распространенных вариантов использования Cassandra. Данные временных рядов в целом часто очень хорошо подходят для модели данных cassandra. В частности, многие люди хранят данные метрик / датчиков, как вы описываете. Видеть:

• http://rubyscale.com/blog/2011/03/06/basic-time-series-with-cassandra/
• http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra
• http://engineering.rockmelt.com/post/17229017779/modeling-time-series-data-on-top-of-cassandra

Что касается вашего беспокойства по поводу сообщества, я не уверен, что производит у вас такое впечатление, но существует довольно большое сообщество (см. Irc, списки рассылки), а также растущее число пользователей cassandra.

http://www.datastax.com/cassandrausers

Что касается ваших критериев:

• Open source
  • Yes
• Works well with Python
  • http://pycassa.github.com/pycassa/
• Appropriate for a small team
  • Yes
• Very well documented
  • http://www.datastax.com/docs/1.1/index
• Has specific features to take advantage of ordered time series data
  • See above links
• Helps me solve some of my versioned data problems
  • If I understand your description correctly you could solve this multiple ways. You could start writing a new row when the version changes. Alternatively you could use composite columns to store the version along with the timestamp/value pair.

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

Большей разницей между этими тремя будет архитектура системы. Cassandra заимствует свою архитектуру у Dynamo от Amazon. Все серверы в кластере одинаковы, и их довольно просто настроить. HBase и Accumulo или несколько прямых клонов BigTable. У них больше движущихся частей и потребуется больше настроек / типов серверов. Например, настройка серверов определенных типов HDFS, Zookeeper и HBase / Accumulo.

Отказ от ответственности: я работаю в DataStax (мы работаем с Cassandra)

У меня есть опыт работы только с Cassandra и MongoDB, но мой опыт может кое-что добавить.

Так что вы в основном делаете метрики, основанные на времени?

Хорошо, если я правильно понимаю, вы используете временную метку в качестве механизма управления версиями, чтобы вы запрашивали определенную временную метку, скажем, чтобы получить последний расчет, который вы использовали на основе идентификатора метрики или чего-то еще, и получаете ts DESC и снимаете первую строку?

Иногда это звучит как версионное хранилище значений ключей.

Имея это в виду, я бы, вероятно, не рекомендовал ни один из двух, которые использовал.

Кассандра слишком жесткая и слишком наследственная, она также основана на том, как вы запрашиваете, до такой степени, что вы можете сделать только одну сводную диаграмму данных из (я полагаю, вы хотите построить график этих показателей) семейства столбцов, которое безумно, поэтому я отказался от него . Что касается поиска (для чего Facebook его использует и только), то он тоже не такой уж и впечатляющий.

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

Хотя я бы представлял, как это происходит в Монго, примерно так:

{
_id: ObjectID(),
metricId: 'AvailableMessagesInQueue',
formula: '4+5/10.01',
result: NaN
ts: ISODate()
}

И вы запрашиваете последнюю версию своего расчета:

var results = db.metrics.find({ 'metricId': 'AvailableMessagesInQueue' }).sort({ ts: -1 });
var latest = results.getNext();

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

Мне нравится эта ветка на HBase: http://mail-archives.apache.org/mod_mbox/hbase-user/201011.mbox/%3C5A76F6CE309AD049AAF9A039A39242820F0C20E5@sc-mbx04.TheFacebook.com%3E

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

Я лично не использовал HBase, поэтому не принимайте всерьез то, что я говорю об этом ....

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

Надеюсь, это немного поможет,

Это не плагин для какой-то конкретной технологии, но эта статья о хранилище временных рядов с использованием MongoDB может предоставить другой способ размышления о хранении больших объемов «сенсорных» данных.

http://www.10gen.com/presentations/mongodc-2011/time-series-data-storage-mongodb

База данных временных рядов Axibase

• Открытый источник

  Есть бесплатная Community Edition

• Хорошо работает с Python

  https://github.com/axibase/atsd-api-python. Есть и другие языковые оболочки, например клиент ATSD R.

• Подходит для небольшой команды

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

• Очень хорошо задокументировано

  Трудно превзойти Redbooks IBM, но мы стараемся. API, настройка и администрирование подробно документированы с примерами.

• Имеет специальные функции для использования упорядоченных данных временных рядов

  Это база данных временных рядов с нуля, поэтому доступны агрегирование, фильтрация и непараметрические прогнозы ARIMA и HW.

• Помогает мне решить некоторые из моих проблем с версионными данными

  ATSD изначально поддерживает версионные данные временных рядов в редакциях SE и EE. Версии отслеживают статус, время изменения и изменения источника по одной и той же метке времени для контрольных журналов и согласований. Это полезная функция, если вам нужны чистые, проверенные данные с отслеживанием. Подумайте об измерении энергии, записи PHMR. Схема ATSD также поддерживает теги серий, которые вы можете использовать для хранения столбцов управления версиями вручную, если вы используете версию CE или вам нужно расширить столбцы управления версиями по умолчанию: статус, источник, время изменения.

Раскрытие информации - я работаю в компании, которая разрабатывает ATSD.