Как вы отслеживаете отношения в NoSQL?

1. user:userid: comments-разумный подход-подумайте об этом как о эквиваленте индекса столбца в SQL с добавленным требованием, чтобы вы не могли запрашивать неиндексированные столбцы.

2. Это где вам нужно думать о ваших требованиях. Список с 30 миллионами пунктов не является необоснованным, потому что он медленный, но потому что с ним невозможно что-либо сделать. Если ваше реальное требование-отобразить некоторые последние комментарии, Вам лучше сохранение очень короткого списка, который обновляется при добавлении комментария-помните, что NoSQL не требует нормализации. Условия гонки-это проблема со списками в базовом хранилище значений ключей, но обычно ваша платформа поддерживает списки правильно, вы можете сделать что-то с блокировками, или вам на самом деле все равно о неудачных обновлениях.

3. то же, что и для комментариев пользователей - создайте ключевое слово индекса:posts

4. больше того же - вероятно, список клубы как собственность студента и индекс на этом поле, чтобы получить всех членов клуба

подход couchDB предлагает испускать правильные классы материала в фазе карты и суммировать его в reduce.. Таким образом, вы можете отобразить все комментарии и испустить 1 для данного пользователя и позже распечатайте только те. Однако для создания постоянных представлений всех отслеживаемых данных в couchDB потребуется много дискового хранилища. кстати, у них также есть эта страница wiki об отношениях:http://wiki.apache.org/couchdb/EntityRelationship.

Riak, с другой стороны, имеет инструмент для сборки родство. Это линк. Вы можете ввести адрес связанного (здесь комментарий) документа в "корневой" документ (здесь пользовательский документ). Есть один трюк. Если он распространяется, он может быть изменен одновременно во многих местах. Это вызовет конфликты и в результате огромное векторное дерево часов:/..не так плохо, не так хорошо.

У Риака есть еще один "механизм". Он имеет 2-слойное пространство имен ключей, так называемое ведро и ключ. Так, например, для студентов, Если у нас есть клуб A, B и C и studentx, StudentY вы могли бы поддерживать следующее соглашение:

{ Key = {ClubA, StudentX}, Value = true }, 
{ Key = {ClubB, StudentX}, Value = true }, 
{ Key = {ClubA, StudentY}, Value = true }

и для чтения отношения просто перечислите ключи в заданных ведрах. Whats неправильно с этим? Это чертовски медленно. Риаку никогда не нравилось перечислять ведра. Становится все лучше и лучше. кстати. вы не тратите память, потому что этот пример {true} может быть связан с одним полным профилем StudentX или Y (здесь конфликты невозможны).

как вы видите это NoSQL != В NoSQL. Вам нужно посмотреть на конкретную реализацию и проверьте сами.

упомянутые ранее магазины столбцов выглядят хорошо подходящими для отношений.. но все зависит от ваших потребностей A и C и P;) если вам не нужен A, и у вас меньше, чем байты Peta, просто оставьте его, продолжайте MySql или Postgres.

удачи

вы

"user": {
    "userid": "unique value",
    "category": "student",
    "metainfo": "yada yada yada",
    "clubs": ["archery", "kendo"]
}

"comments": {
    "commentid": "unique value",
    "pageid": "unique value",
    "post-time": "ISO Date",
    "userid": "OP id -> THIS IS IMPORTANT"
}

"page": {
    "pageid": "unique value",
    "post-time": "ISO Date",
    "op-id": "user id",
    "tag": ["abc", "zxcv", "qwer"]
}

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

например, важные индексы для вас are

• комментарий.Имя пользователя
• комментарий.PageID
• комментарий.PostTime
• страница.Tag []

Если вы используете NosDB (база данных NoSQL на базе .NET с поддержкой SQL) ваши запросы будут как

 SELECT * FROM Comments WHERE userid = ‘That user’;

 SELECT * FROM Comments WHERE pageid = ‘That user’;

 SELECT * FROM Comments WHERE post-time > DateTime('2016, 1, 1');

 SELECT * FROM Page WHERE tag = 'kendo'

проверьте все поддерживаемые типы запросов из их лист для SQL чит или документации.