Миграция SQL в значение ключа и MapReduce - PullRequest
Новая
       13

Миграция SQL в значение ключа и MapReduce

0 голосов
/ 22 ноября 2011

У меня есть база данных SQL с двумя таблицами, подобными этой: 

Users
 Id (PK)
 Name

Orders
 Id (PK)
 UserId (FK - User.Id)
 Amount

Я хотел бы переместить это в хранилище ключей-значений NoSQL (т.е. MongoDb), чтобы избежать объединений (на оченьбольшие результирующие наборы).

  1. Имеет ли эта структура смысл при переносе в базу данных KV?Если нет, я должен добавить еще одну таблицу, например User_Orders, относящуюся к пользователям и заказам?

У меня есть экран, который отображает заказы в сетке, но я также хотел бы отображать имя пользователя.В SQL я использовал бы соединение, чтобы извлечь это из базы данных.

  1. Существует ли в NoSQL эквивалент (без объединения), кроме запроса базы данных один раз для Order.UserId для получения связанного пользователя?Если нет, то как я могу применить (Distributed?) Map-Reduce в этом случае для достижения той же цели, если предположить, что моя архитектура позволяет мне запускать несколько внешних серверов и серверов приложений?

Спасибо!

1 Ответ

1 голос
/ 22 ноября 2011

Большое изменение от реляционной базы данных к NoSQL будет денормализация .В зависимости от того, как часто имя пользователя изменяется в вашей системе, вы можете просто добавить имя пользователя в коллекцию orders ( таблица в реляционных терминах).

Итак, ваша orders схема сбора будет выглядеть так: 

{"userId":"abc123", "userName": "Some Name", "orderId":"someorderId","amount":153.23}

Вы можете использовать простые find() запросы для получения данных о заказах и пользователях.Если изменить имя, это будет multi-document-update , но если это случается не часто, это не так уж и плохо.Один раз в обновлениях Blue Moon, денормализация хороша, поскольку она приносит пользу чтению.Опять же, это не эмпирическое правило, но это полностью зависит от вашего варианта использования и дизайна, чтобы учитывать соотношение чтение: запись.

Если имя пользователя меняется очень часто, и вы не хотите денормализовать, то вы всегда можете кэшировать карту userId to userName с соответствующим TTL и искать ID -> Name на уровне приложения.вместо того, чтобы использовать базу данных для наложения бизнес-ограничений.

Вам не понадобится map-Reduce, чтобы просто извлекать заказы и пользователей - если только вы не выполняете массовое агрегирование данных.

...