Есть ли какая-то операция Scan API или Query API, которая позволяет выполнять поиск в таблице с составным ключом (pk/sk), но изменяется только в pk для оптимизации операции сканирования таблицы?
Позвольте мне представить прецедент:
Предположим, у меня есть ключ раздела, определяемый идентификатором проекта, и в каждом проекте у меня есть огромное количество записей (sk)
Теперь мне нужно решить запрос «вернуть все проекты». Поэтому у меня нет ключа раздела, и мне нужно выполнить сканирование.
Я знаю, что мог бы создать GSI, решающий эту проблему, но давайте предположим, что это не так.
Есть ли способ выполнить сканирование, которое «перескакивает» между каждым pk, игнорируя элементы sk?
Другими словами, я соберу информацию о первой записи каждого ключа раздела.
Спасибо @RichardDunn, я могу решить проблему с новой таблицей или GSI. Но вопрос был направлен на то, чтобы узнать, есть ли функциональность, позволяющая выполнять такое «оптимизированное» сканирование в той же таблице, чтобы я мог избежать создания индекса или другой таблицы.
Нет, сканирование может быть как по возрастанию, так и по убыванию по ключу сортировки, но других вариантов нет. Опять же, я должен сказать, я действительно думаю, что вы должны рассмотреть две таблицы. Может быть, я что-то неправильно понимаю, но похоже, что ваша схема будет очень проблематичной.
Как вы уже знаете, DynamoDB — это база данных NoSQL. Он оптимизирован для ПРОСМОТРА, и методы, которые вы использовали в базах данных SQL или других (небольших) базах данных, не всегда доступны в DynamoDB.
Концепция ключа раздела заключается в объединении записей, являющихся частью одного раздела, и их сортировке по ключу сортировки. Другая сторона этого заключается в том, что записи, которые не имеют одного и того же ключа раздела, хранятся в других местах. Это не длинный список (или дерево) записей, которые вы можете просмотреть.
При разработке схемы в базе данных NoSQL необходимо учитывать шаблон доступа к этим данным. Если вам нужен список всех проектов, вам нужно вести индекс, который позволит это сделать.
Этого ответа я и ожидал, большое спасибо, @Guy!
Это действительно звучит так, как будто у вас должно быть две таблицы: таблица для «проектов» и таблица для «записей» или что-то еще, что они семантически представляют.