Как спроектировать эту NoSQL DB

Question

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

Приложение представляет собой регистратор.Я буду что-то записывать, а Динамо будет записывать дату и считать за день.

Например, пользователь регистрирует несколько вещей сегодня, он просто скажет сегодняшнюю дату и logged_times: 5

Затем я могу получить запрос, чтобы получить общую сумму всех logged_times за последнюю неделю /день / месяц и т. д.

Мой вопрос: как вы структурируете базу данных NoSQL, чтобы сделать что-то подобное, что будет эффективно?

Answer 1

Немного понятий NOSQLdb

1. записей должны быть одинаково распределены по первичным ключам.
2. чтения должны быть одинаково распределены по первичным ключам.

Очевидная вещь, которая приходит на ум при рассмотрении данной проблемы и схемы dyanamodb:

имеет ключ logs как первичный ключ и timestamp как вторичный ключ.Для агрегации используйте

select * where pk=logs and sk is_between x and y

, но это нарушит обе концепции.Мы всегда пишем на одном ПК и всегда читаем с одного и того же.

Теперь к этой конкретной проблеме. Наш ПК должен быть достаточно случайным (чтобы не было горячих клавиш ) и достаточно детерминированным (чтобы мы могли запрашивать)

нам нужно будет сделать некоторые предположения о приложении при разработке ключей.скажем, мы решили, что мы будем обновлять каждый час.следовательно, может иметь 7 января 2018-17 в качестве ключа.где 17 означает 17-й час.этот ключ является детерминированным, но он не является достаточно случайным.и каждое обновление или чтение 7 января будет происходить в основном в одном разделе.Чтобы сделать ключ случайным, мы можем вычислить его хеш, используя алгоритм хеширования, такой как md5.скажем, после взятия хэша наш ключ становится 1sdc23sjdnsd.Это не имеет никакого смысла, если вы смотрите на данные таблицы.Но если вы хотите узнать количество событий 7 января 2018-17 гг., Вы просто хешируете время и извлекаете данные из DynamodB с помощью хеш-ключа.если вы хотите знать все события 7 января 2018 года, вы можете повторить 24 получения и агрегировать счет.

Теперь у схем такого типа будут проблемы, при которых

1. Если вы решите переходить с почасовой на минутную ставку.

2. Если большинство ваших запросов выполняются во время выполнения, как, пожалуйста, получите все данные за последние 2,4,6 дня.Это будет означать слишком много поездок туда и обратно в БД.И это будет не только по времени, но и по затратам.

Эмпирическое правило равно , если шаблоны запросов четко определены, используйте NOSQL и сохраняйте результаты по соображениям производительности.Если вы пытаетесь выполнить сортировку или объединение запросов в nosql, это принудительно подгоняет ваш вариант использования на основе вашего выбора технологии.

Вы также можете посмотреть aws рекомендацию храненияданные временного ряда.