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

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

Для (растущего) набора symbols у меня будет список (time,value) кортежей (со временем увеличивающийся). Не все symbols будут обновлены; некоторые symbols могут быть обновлены, а другие нет, и могут быть добавлены совершенно новые symbols.

Таким образом, база данных должна позволять:

  • Добавить символы с исходным одноэлементным (кортежным) списком. Например. О: [(2012-04-14 10:23, 50)]
  • Обновите символы с помощью нового кортежа. (Добавить этот кортеж в список этого символа).
  • Прочитайте данные для данного символа. (В идеале даже позвольте мне указать временные рамки, за которые должны быть возвращены данные)

Операции создания и обновления, возможно, должны быть атомарными. Если возможно чтение нескольких символов одновременно, это было бы интересно.

Производительность не критична. Обновления/создания будут происходить примерно раз в несколько часов.


riak nosql mongodb cassandra
person angerman    schedule 14.04.2012    source источник
comment
Переполнение стека не является механизмом рекомендаций   -  person Brian Roach    schedule 15.04.2012

Ответы (2)


arrow_upward
17
arrow_downward

Я считаю, что буквально все основные базы данных NoSQL будут поддерживать это требование, особенно если у вас на самом деле нет большого объема данных (в связи с чем возникает вопрос, почему NoSQL?).

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

Мы выбрали базу данных Cassandra, и наш дизайн был следующим:

  • Единое пространство ключей для всех «символов»
  • Каждый символ был новой строкой
  • Каждый раз запись была новым столбцом для соответствующей строки
  • Каждое значение (может быть более одного значения) было частью значения записи времени.

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

В дополнение к этому, вот некоторая информация об использовании MongoDB (и коллекций с ограничениями, если необходимо) для хранилища временных рядов: MongoDB как база данных временных рядов

Наконец, вот обсуждение SQL и NoSQL для временных рядов: https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql

Я могу добавить к этому обсуждению следующее:

  • Кривая обучения для NoSQL будет выше, вы не получите дополнительную гибкость и функциональность бесплатно с точки зрения «мягких затрат». Кто будет обеспечивать оперативную поддержку этой базы данных?
  • Если вы ожидаете, что эта функциональность будет расширяться в будущем (либо по мере добавления дополнительных полей к каждой временной записи, либо по увеличению емкости с точки зрения количества символов или размера временных рядов символов), то определенно выбирайте NoSQL. Преимущество гибкости огромно, а масштабируемость, которую вы получаете (с приведенным выше дизайном) как на основе «на символ», так и на основе «количества символов», почти неограничена (я говорю почти неограничена - максимальное количество столбцов в строке исчисляется миллиардами, максимальное я считаю, что количество строк на ключевое пространство не ограничено).
person yamen    schedule 14.04.2012

arrow_upward
4
arrow_downward

Взгляните на opentsdb.org базу данных временных рядов с открытым исходным кодом, которая использует hbase. Они были умны в том, как они хранят TS. Это хорошо задокументировано здесь: http://opensdb.net/misc/opentsdb-hbasecon.pdf

person Pierre Francois Aubert    schedule 18.06.2012
comment
+1 для opentsdb: это идеальное решение OSS для хранения огромных временных рядов (например, данных тиков форекс). Настройка Hbase может быть утомительной, но сборщики python OpenTsdb (своего рода транзакторы OpenTsdb) упрощают хранение потоковых данных на лету. - person Peter Host; 05.02.2013