Присоединиться к операции с NOSQL

Вам пришлось бы делать множественный отбор, и соединять данные вручную в вашем приложении. См. этот SO пост для получения дополнительной информации. Из этого поста:

Большие наборы данных могут быть запрошены из таких сервисов, как AppEngine, используя язык GQL ("gee-kwal"), который основан на подмножестве SQL. Заметно, что в GQL не хватает любой команды JOIN. Из-за распределенной природы БД Bigtable, выполнение соединения между двумя таблицами было бы ужасно неэффективно. Вместо этого программист должен реализовать такую логику в своем приложении или спроектировать свое приложение таким образом, чтобы оно в нем не нуждалось.

Калеб прав. Вы пишете пользовательский код с помощью решения NoSQL, если ваши данные плохо помещаются в хранилище значений ключей. Кэширование обработки map-reduce/async и пользовательского вида являются обычным делом. Брайан Акер сделал очень забавную (и сатирическую, и предвзятую) презентацию в ноябре 2009 года на OpenSQLCamp http://www.youtube.com/watch?v=LhnGarRsKnA. Пропустите 40 секунд, чтобы услышать о соединениях

Когда у вас очень большие данные, вы, вероятно, хотите избежать объединения. Это связано с тем, что накладные расходы, связанные с индивидуальным поиском ключей, относительно велики (службе необходимо выяснить, к какому узлу (узлам) обращаться, и запросить их параллельно, а также дождаться ответа). Под "накладными расходами" я подразумеваю задержку, а не ограничение пропускной способности.

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

Если это случается не очень часто, вы, вероятно, могли бы взять удар, но если вы захотите сделать много из них, то, возможно, стоит "денормализовать" данные.

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

Кроме того, большинство nosql (на самом деле) также не поддерживают вторичные индексы, что означает, что вы должны дублировать данные, если хотите сделать запрос по любому другому критерию.

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