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

Мои данные

Это прежде всего мониторинг данных, передаваемых в виде отметки времени: значение для каждого контролируемого значения на каждом контролируемом устройстве. Он регулярно собирал множество приборов и многие контролируемые значения.

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

Мое использование

В нисходящем потоке я собираюсь использовать различные данные undefined для интеллектуального анализа данных/машинного обучения. Пока не совсем ясно, что такое использование, но ясно, что я буду писать весь код ниже по потоку в Python. Кроме того, мы очень маленький магазин, поэтому я могу реально справиться с такой сложностью в настройке, обслуживании и взаимодействии с приложениями, расположенными ниже по потоку. У нас просто не так много людей.

Выбор

Мне не разрешено использовать SQL RDBMS для хранения этих данных, поэтому я должен найти правильное решение NoSQL. Вот что я нашел до сих пор:

  • Cassandra
    • Похоже на меня, но похоже, что некоторые из основных пользователей перешли. Это заставляет меня задаться вопросом, не будет ли это просто такой яркой экосистемой. У этого сообщения SE, кажется, есть хорошие вещи, чтобы сказать: данные временного ряда Кассандры
  • Accumulo
    • Опять же, это кажется прекрасным, но я обеспокоен тем, что это не крупная, активно развивающаяся платформа. Похоже, это оставило бы меня немного голодным для инструментов и документации.
  • MongoDB
    • У меня есть, возможно, иррациональная, интенсивная неприязнь к монгольской толпе, и я ищу любую причину отказаться от этого как решения. Мне кажется, что модель данных Монго ошибочна для вещей с такой статической, регулярной структурой. Мои данные даже входят (и должны оставаться) в порядке. Тем не менее, все и их мать, похоже, любят эту вещь, поэтому я действительно пытаюсь оценить ее применимость. См. Это и многие другие сообщения SE: Что использовать NoSQL DB для редких временных рядов, таких как данные?
  • HBase
    • Вот где я сейчас склоняюсь. Похоже, что преемник Кассандры с полностью используемым подходом к моей проблеме. Тем не менее, это большая часть технологий, и я обеспокоен тем, что действительно знаю, за что я запишу, если я его выберу.
  • OpenTSDB
    • В основном это база данных по временному ряду, построенная поверх HBase. Отлично, правда? Я не знаю. Я пытаюсь понять, что другой слой абстракции покупает меня.

Мои критерии

  • Открытый исходный код
  • Хорошо работает с Python
  • Подходит для небольшой команды.
  • Очень хорошо документировано
  • Имеет конкретные функции, позволяющие использовать данные упорядоченного временного ряда.
  • Помогает решить некоторые из моих проблем с версиями данных

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

Любые мысли?

Ответ 1

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

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

http://www.datastax.com/cassandrausers

Относительно ваших критериев:

  • Открытый исходный код
    • Да
  • Хорошо работает с Python
  • Подходит для небольшой команды
    • Да
  • Очень хорошо документировано
  • Имеет конкретные функции, позволяющие использовать данные упорядоченного временного ряда
    • См. выше ссылки
  • Помогает решить некоторые из моих проблем с версиями данных
    • Если я правильно понимаю ваше описание, вы можете решить эту проблему несколькими способами. Вы можете начать запись новой строки при изменении версии. В качестве альтернативы вы можете использовать составные столбцы для хранения версии вместе с парой timestamp/value.

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

Чем больше разница между тремя, тем больше будет архитектура системы. Кассандра берет свою архитектуру от Динамо Амазонки. Каждый сервер в кластере тот же, и его очень просто настроить. HBase и Accumulo или более прямых клонов BigTable. Они имеют больше движущихся частей и потребуют больше настроек/типов серверов. Например, настройка типов серверов HDFS, Zookeeper и HBase/Accumulo.

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

Ответ 2

У меня есть только опыт в 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/%[email protected]com%3E

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

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

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

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

Ответ 3

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

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

Ответ 4

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

  • Открытый исходный код

    Существует бесплатное издание Community Edition

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

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

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

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

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

    Трудно побить IBM redbooks, но мы пытаемся. API, конфигурация и администрирование документируются подробно и с примерами.

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

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

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

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

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