Разработка базы данных DynamoDB (хранилище ключей, noSQL)

Question

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

Это правильное представление о том, как вы будете хранить данные из MySQL в хранилище значений ключей?

TYPE: MySQL
TABLE: users
COLUMNS: user_id(primary), username, location

TYPE: Key Value Store
TABLE: users
KEY: user_id
VALUES: username, location

Итак, если я прав выше.Получение общей пользовательской информации достаточно просто для понимания.Но как мне выполнить следующий запрос в хранилище значений ключей?

SELECT username FROM users WHERE location = 'mexico'

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

--Original Table--
TYPE: Key Value Store
TABLE: users
KEY: user_id
VALUES: username, location

--Additional "query" Table--
TYPE: Key Value Store
TABLE: user-location
KEY: location
VALUES: user_id

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

Это лучший способ решить эти проблемы?Или я что-то упустил?

Answer 1

Обновленный ответ (январь-2014)

DynamoDB начал поддерживать Глобальные вторичные индексы , что означает, что теперь вы можете поместить индекс в местоположение и быстро получать только те, которые живут в Мексике.

Обратите внимание, что на момент написания (это может измениться) вы не можете добавлять индексы к существующим таблицам.

Оригинальный ответ (март-2013)

Замечания по NoSQL в целом:
СУБД NoSQL обычно фокусируется на масштабируемости.
Они также обычно добавляют накладные расходы приложения с точки зрения большего количества кода на стороне сервера.

Вы должны спросить себя "сколько раз мне нужно будет опрашивать пользователей из Мексики"
Ответ, скорее всего, направит вас к правильному подходу при моделировании базы данных.
Это также причина того, что здесь нет «идеальных подгонок» и действительно «образцов нубов» (по крайней мере, насколько мне известно)

Теперь, в частности, в отношении DynamoDB, у вас нет роскоши вторичных индексов (в отличие от других решений NoSQL, которые есть), поэтому вам нужно создавать таблицы-индексы. В вашей модели вы можете создать таблицу, в которой ключ хеша - это местоположение, а ключ диапазона - это идентификатор пользователя. Таким образом, с помощью вызова QUERY API вы можете получить всех пользователей MEXICO.

Можно подумать и о других реализациях, таких как объединение идентификаторов в одном объекте, но опять же, поскольку DynamoDB допускает только объекты размером 64 КБ - вы, вероятно, столкнетесь здесь с проблемой масштабирования.

Answer 2

Не управляйте отдельными индексными таблицами самостоятельно.

Вместо этого используйте новую функцию глобальный вторичный индекс .

Answer 3

Если ваш дизайн таков, что вы в конечном итоге выполняете много поисков в зависимости от местоположения, вам следует изменить дизайн пользовательской таблицы, указав Location как hashkey и userId как key range.Но вышеприведенный способ удаляет возможность запрашивать пользователей по их имени или идентификатору пользователя, а также при вставке нового пользователя не может проверить уникальность в идентификаторе пользователя (что противоречит тому, что делал первичный ключ в MySql).

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

Наилучшим подходом, как вы упомянули, является выполнение всей этой обработки на уровне API в зависимости от ваших потребностей.