Как вы запрашиваете DynamoDB?

Question

Я смотрю на Amazon DynamoDB, так как похоже, что он избавляет от всех хлопот по обслуживанию и масштабированию сервера базы данных.В настоящее время я использую MySQL, и поддержание и масштабирование базы данных - это полная головная боль.

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

Я совершенно новичок в NoSQL и нереляционных базах данных.

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

Или вы можете запустить полное сканирование таблицы и применить к ней фильтр.Суть в том, что он будет сканировать только 1 Мб за раз, поэтому вам, вероятно, придется повторить сканирование, чтобы найти число результатов X.

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

Для экземпляра, скажем, у меня есть клон Flickr.Моя таблица изображений может выглядеть примерно так:

• Идентификатор изображения (номер, первичный ключ хеша)
• Дата добавления (номер, первичный ключ диапазона)
• Идентификатор пользователя (Строка)
• Теги (набор строк)
• и т. Д.

Поэтому, используя запрос, я смогу перечислить все изображения за последние 7 дней и ограничить его Xколичество результатов довольно легко.

Но если бы я хотел перечислить все изображения от конкретного пользователя, мне нужно было бы выполнить полное сканирование таблицы и отфильтровать по имени пользователя.То же самое можно сказать и о тегах.

И поскольку вы можете сканировать только 1 МБ за раз, вам может потребоваться выполнить несколько сканирований, чтобы найти X изображений.Я также не вижу способа легко остановиться на количестве картинок X.Если вы пытаетесь получить 30 изображений, первое сканирование может найти 5, а второе - 40.

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

Или я здесь совершенно не в себе?

Answer 1

Да, вы правы в отношении компромисса между производительностью и гибкостью запросов.

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

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

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

Answer 2

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

Эта таблица "схема" может быть:

    User ID (String, Primary Key)
    Date Added (Number, Range Key)
    Image ID (Number)

-

Таким образом, вы можете запросить по ИД пользователя и отфильтровать по дате

Answer 3

Вы можете использовать составной ключ хеш-диапазона в качестве основного индекса.

со страницы DynamoDB:

Первичный ключможет быть хеш-ключом с одним атрибутом или составным хэш-диапазоном.Первичным ключом хеша одного атрибута может быть, например, «UserID».Это позволит вам быстро считывать и записывать данные для элемента, связанного с данным идентификатором пользователя.

Составной ключ диапазона хеш-индекса индексируется как элемент ключа хеш-функции и элемент ключа диапазона.Этот многокомпонентный ключ поддерживает иерархию между значениями первого и второго элемента.Например, составной ключ диапазона хэша может быть комбинацией «UserID» (хэш) и «Timestamp» (диапазон).Удерживая постоянным элемент ключа хеша, вы можете выполнять поиск по элементу ключа диапазона для получения элементов. Это позволит вам использовать API запросов, например, для извлечения всех элементов для одного идентификатора пользователя в диапазоне временных отметок.