Как хранить временные ряды в mongodb?


11

Мне нужно создать базу данных временных рядов и выполнить следующие задачи:

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

Монго адаптирован к этому, и если да, то как мне структурировать базу данных? (одна серия времени = один документ? Или один документ = одна запись серии времени, и все эти документы образуют коллекцию, которая представляет собой весь временной ряд?)

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

Любая ссылка на учебник, который конкретно объясняет, как управлять временными рядами в Mongo, очень приветствуется.

Спасибо!


Прочитайте схему схемы для данных временных рядов в MongoDB сегодня. Очень хорошо об этом пишу.
akauppi

Существует обновленный технический документ, в котором обсуждаются временные ряды в MongoDB. mongodb.com/colalendar/time-series-best-practices
Роберт Уолтерс,

Ответы:


6

Я предлагаю одну запись временного ряда для каждого документа. Есть несколько проблем с хранением нескольких записей в документе:

  • один документ ограничен определенным размером (в настоящее время 16 МБ); это ограничивает количество записей, которые можно сохранить в одном документе
  • по мере того, как в документ добавляется больше записей, весь документ (и временные ряды) будут без необходимости удаляться и перераспределяться в больший объем памяти.
  • запросы к поддокументам ограничены по сравнению с запросами к обычным документам
  • документы с очень плоской структурой (например, один вложенный документ на каждую секунду) не являются производительными
  • встроенная карта-уменьшение не работает так же на поддокументы

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

Вот пример документа BSON из библиотеки регистрации событий, которая использует MongoDB :

Example format of generated bson document:
{
    'thread': -1216977216,
    'level': 'ERROR',
    'timestamp': Timestamp(1290895671, 63),
    'message': 'test message',
    'fileName': '/var/projects/python/log4mongo-python/tests/test_mongo_handler.py',
    'lineNumber': 38,
    'method': 'test_emit_exception',
    'loggerName':  'testLogger',
    'exception': {
        'stackTrace': 'Traceback (most recent call last):
                       File "/var/projects/python/log4mongo-python/tests/test_mongo_handler.py", line 36, in test_emit_exception
                       raise Exception(\'exc1\')
                       Exception: exc1',
        'message': 'exc1',
        'code': 0
    }
}

Поскольку журнал событий похож на временной ряд, возможно, стоит изучить остальную часть кода . Существуют версии на Java, C #, PHP и Python.

Вот еще один похожий проект с открытым исходным кодом: Zarkov


[обновление] В ответ на комментарий @ RockScience я добавил еще несколько ссылок:


это будет МНОГО документов, если в моем временном ряду будут внутридневные данные за несколько лет !!! не проблема ли иметь столько документов? Исходя из sql фона, я просто считаю, что это не очень эффективно для памяти. (Поскольку будет много повторений для всех точек данных одного и того же временного ряда)
RockScience

@RockScience: MongoDB, как и многие другие базы данных NoSQL, избегает нормализации и эффективности памяти в пользу других вещей, таких как гибкость, скорость и снижение загрузки ЦП. Если вам нужна эффективность памяти, MongoDB может оказаться не лучшим решением для вас. MongoDB копирует полное текстовое имя каждого поля в каждый документ для громкого крика! В любом случае, я обновил свой ответ с помощью нескольких дополнительных ресурсов, включая пример использования MongoDB для хранения очень больших временных рядов.
Leftium

2

Я нашел этот вопрос в SO ( /programming/4814167/storing-time-series-data-relational-or-non ), где OP спрашивает, как хранить временные ряды. Хотя его вопрос в большей степени основан на использовании базы данных NoSQL или RDBMS, и вы, кажется, довольно настроены на использование базы данных NoSQL.

Также найдена эта статья на тему « Уникальные требования к базе данных временных рядов », которая может оказаться полезной.

Надеюсь это поможет.


2

Да, безусловно, база данных NoSQL лучше подходит для хранения данных временных рядов, чем традиционная СУБД.

Да, MongoDB исключительно адаптирован для этого варианта использования.

-Как вы должны структурировать базу данных? Один документ = один входной ряд временного ряда против нескольких временных рядов.

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

Вот пример схемы о том, как оптимально хранить ряды часовых рядов с минутным интервалом:

{
  timestamp_hour: ISODate("2015-07-02T23:00:00.000Z"),
  type: memory_used”,
  values: {
    0: 999999,
    1: 1000000, 
    …,
    58: 0,
    59: 0
  }
}

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

Вот ссылка на учебник, который конкретно объясняет, как управлять временными рядами в MongoDb из официального блога MongoDb: http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in- MongoDB


1
Объединение данных в документе будет лучше с точки зрения производительности и использования ресурсов. Существует три сценария схемы, которые обсуждаются в обновленном временном ряду для документа «Лучшие практики» MongoDB. mongodb.com/colalendar/time-series-best-practices
Роберт Уолтерс,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.