Идеальный выбор базы данных для хранения данных носимых устройств (Fitbit)

Недавно я разрабатываю приложение для Fitbit. Я рассматриваю MongoDB или HBase, так как они поддерживают агрегацию и поддержку обработки данных в формате значения ключа. Пример набора данных:

{
    "activities-heart": [
        {
            "customHeartRateZones": [],
            "dateTime": "today",
            "heartRateZones": [
                {
                    "caloriesOut": 2.3246,
                    "max": 94,
                    "min": 30,
                    "minutes": 2,
                    "name": "Out of Range"
                },
                {
                    "caloriesOut": 0,
                    "max": 132,
                    "min": 94,
                    "minutes": 0,
                    "name": "Fat Burn"
                },
                {
                    "caloriesOut": 0,
                    "max": 160,
                    "min": 132,
                    "minutes": 0,
                    "name": "Cardio"
                },
                {
                    "caloriesOut": 0,
                    "max": 220,
                    "min": 160,
                    "minutes": 0,
                    "name": "Peak"
                }
            ],
            "value": "64.2"
        }
    ],
    "activities-heart-intraday": {
        "dataset": [
            {
                "time": "00:00:00",
                "value": 64
            },
            {
                "time": "00:00:10",
                "value": 63
            },
            {
                "time": "00:00:20",
                "value": 64
            },
            {
                "time": "00:00:30",
                "value": 65
            },
            {
                "time": "00:00:45",
                "value": 65
            }
        ],
        "datasetInterval": 1,
        "datasetType": "second"
    }
}

Что было бы идеальным выбором для базы данных для хранения данных датчика, поскольку я хочу провести анализ этих данных в своем приложении? Спасибо!


database mongodb bigdata fitbit
person Nicole    schedule 20.09.2015    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Одна вещь, о которой следует беспокоиться с Mongo: накладные расходы на хранение данных огромны. В типичной СУБД или БД временных рядов в каждой строке хранятся только ваши данные, а не метаданные (имена и типы полей).

Вам следует изучить базы данных временных рядов, такие как Graphite и InfluxDB. Даже у Cassandra есть некоторые возможности для этого.

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

Одной из простых БД для начала является Graphite. Это приводит к очень специфическому компромиссу: требования к хранению данных для каждого графика являются постоянными (т. Е. Не увеличиваются со временем, даже если вы регистрируете данные за годы). Он также может обрабатывать миллионы показателей в секунду. Единственным недостатком является то, что разрешение «устаревает», поэтому вы можете сказать ему хранить разрешение 1 м в течение нескольких дней, но затем уменьшить разрешение до 10 м на месяц, затем разрешение 1 ч на 1 год и разрешение 1 д на 10 лет. Вы можете указать ему сохранять статистику (максимум, минимум, среднее значение, 90-й процентиль) для каждого интервала. Получение графика любого произвольного промежутка времени - это, по сути, поиск по одному диску. Есть отличные панели для просмотра ваших данных (рекомендую Grafana).

person BraveNewCurrency    schedule 18.01.2016

arrow_upward
0
arrow_downward

Базы данных NoSQL — хороший выбор, когда у вас нет структуры в ваших данных. Вы также можете эмулировать функциональность (ключ, значение) в РСУБД. Показанные вами примеры данных выглядят так, что их можно легко нормализовать и сохранить в MySQL или SQL Server. Почему бы тебе не заняться этим первым? Он также будет очень легко управляемым. Самое главное, ваши данные имеют структуру.

Если производительность становится проблемой, в вашем распоряжении есть индексы. Даже денормализация. Вы можете найти шаги по нормализации ваших данных здесь, в этом ответе SO о нормализации в базах данных . Вы можете выполнять агрегирование и обработку данных в СУБД так же хорошо, как и в любом решении NoSQL. У вас есть другая причина?

person displayName    schedule 20.09.2015
comment
Данные с датчиков будут большими и будут собираться через равные промежутки времени. Следовательно, я рассматривал базу данных NoSQL. - person Nicole; 21.09.2015
comment
@Nielet: Большой размер не поддается количественной оценке, чтобы помочь кому-либо сказать вам, следует ли вам использовать СУБД или NoSQL. Я знаю, что таблицы РСУБД без проблем обрабатывают порядок миллионов строк. Я не знаю о миллиардах, потому что я еще не сталкивался с этим случаем. Не беспокойтесь о данных, поступающих от датчиков. Если у вас нет какой-либо конкретной ошибки с РСУБД, используйте только их. - person displayName; 21.09.2015

arrow_upward
0
arrow_downward

Вы можете попробовать Amazon Redshift, потому что:

  • Он имеет возможности прямой загрузки json с использованием команд копирования.
  • Он поддерживает полный ANSI SQL (поскольку он основан на PostgreSQL).
  • Он имеет встроенные аналитические функции.
  • Он поддерживает Python и R, если вы хотите еще больше «аналитики».
  • Он имеет прямую связь с наиболее популярными решениями для создания отчетов (Microstrategy, Tableau и т. д.).
  • Это полностью в облаке AWS.
person Paladin    schedule 21.09.2015