Моделирование данных с MangoDB?

Question

Я новичок в работе с данными.

Поэтому у меня много данных, основанных на времени.

Строка данных за каждые 15 минут. Должен ли я вычислять данные и хранить данные за каждый 1 час, 1 день, 1 месяц в базе данных?

если я это сделаю, будет ли эта схема хорошей.

{
   _id: "joe",
   name: "Joe Bookreader",
   time min: [
                {
                  time: "1",
                  steps: "10"
                },
                {
                  time: "2",
                  steps: "4"
                }
              ]
   time day: [
                {
                  time: "1",
                  steps: "30"
                },
                {
                  time: "2",
                  steps: "30"
                }
              ]

 }

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

Answer 1

На минутку от программного подхода к проблеме и обдумайте поставленную задачу.

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

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

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

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

Я упоминаю об этом потому, что вы храните time min а также time day, Если time day можно рассчитать на основе time min Вы не должны хранить его в базе данных, а рассчитать его на лету. Вы можете написать запросы, которые приведут к фактическому результату time day без использования каких-либо дополнительных вычислительных мощностей на вашем узле приложения. Все вычисления будут выполняться на узле данных, гораздо более эффективно, чем на вычислительном узле, и без сетевых штрафов.

Я понимаю, что этот пост немного стар, но я надеюсь, что мой ответ кому-нибудь поможет.