Как запрашивать и представлять отношения между объектами / хешами в Redis - PullRequest
Новая
       11

Как запрашивать и представлять отношения между объектами / хешами в Redis

2 голосов
/ 09 декабря 2011

Допустим, у меня есть приложение, в котором есть статьи и авторы.Он сохраняет свои данные в базе данных Redis.Статьи хранятся в виде хэшей, как показано ниже в синтаксисе JSON: 

{ "title" : "My title", "content" : "This is a content", "authorId" : 1}

Кроме того, мои авторы представлены хэшами: 

{ "name": "John Smith", "username" : "jsmith", "password" : "secret", "id" : 1}

Вопрос в том, как бы вывосстановить все статьи с указанием идентификатора автора?Есть ли какая-то команда в Redis, чтобы сделать это?Вы бы получили и отфильтровали их вручную?Или мой способ представления этих отношений некорректен?Что бы вы предложили?

1 Ответ

5 голосов
/ 09 декабря 2011

В Redis нет прямого способа получить хэши, используя значение поля в качестве критерия выбора.С вашей текущей моделью данных единственный путь к ней - получить все хэши статей, а затем отбросить те, которые не соответствуют, но этот метод далек от эффективности.

Дело в том, что вам придется поддерживатьИндекс самостоятельно.Поскольку у вас не может быть наборов внутри хешей, я бы сделал это с помощью отдельных наборов, содержащих идентификаторы статей автора.Таким образом, у вас будут хеши авторов: 

author_1: { "name": "John Smith", ... "id": 1 }
author_2: { "name": "Jane Doe", ... "id": 2 }

И наборы для этого сопоставления: 

author_1_articles: [1, 3]
author_2_articles: [2]

И он сопоставляется с этими статьями: 

article_1: { "title": "My title", ... "authorId": 1 }
article_2: { "title": "Another one", ... "authorId": 2 }
article_3: { "title": "What a story", ... "authorId": 3 }

Теперь, когда вы хотите получить статьи для автора X, вы просто получите SMEMBERS author_X_articles и получите список идентификаторов статей.

Я бы использовал наборы, потому что Redis просто проигнорирует это, если вы добавите одну и ту же статью для автора несколько раз.Таким образом, в списке статей, которые вы получите, никогда не будет дубликатов, и вы можете использовать SADD без предварительной проверки, если статья уже есть в наборе.

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

...