StackExchange Redis Поиск в коллекции

Мы рассматриваем возможность использования Redis, размещенного в Azure. Наш первый случай использования NuGet StackExchange - это поиск по нашей клиентской базе. Первоначально это около 10 000 клиентов, но со временем они будут расти.

У покупателя будет конкретная модель поиска, примерно так:

    {
     "Id": 123,
     "Name": "Bob Smith",
     "Age": 72,
     "Postcode": "AB123EF",
     "Email": "[email protected]",
     "Telephones": [
        "07710123456", 
        "01453123456"
      ]
    }

Насколько я понимаю, вам следует избегать ввода больших объектов blob в Redis, поэтому хранить список как один объект - не лучшая идея. Итак, мы использовали функции List * для хранения каждого элемента под ключом и сериализации данных.

Первоначальная работа выглядит примерно так:

    var tasks = new List<Task>();

    foreach (var customer in customers)
    {
     tasks.Add(db.ListLeftPushAsync(_key, JsonConvert.SerializeObject(customer)));
    }

    await Task.WhenAll(tasks).ConfigureAwait(true);

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

Это принципиально оставило нам вопрос о запросе информации. Я понимаю, что Redis хранит все как строку, но я не понимаю, как искать в списке, поскольку это объект Redis, а не строка. Таким образом, мы не можем использовать, например, ListRange(_key).Where(c => c.Contains("Bob")).

Пожалуйста, дайте мне знать, если наш подход неверен или есть метод, который мне просто не хватает.


azure redis stackexchange.redis azure-redis-cache
person Tom    schedule 18.10.2019    source источник
comment
Вы рассматривали возможность использования RediSearch?   -  person Guy Korland    schedule 20.10.2019

Ответы (1)


arrow_upward
2
arrow_downward

Я полностью согласен с тем, что @GuyKorland сказал, что вам следует использовать зрелый продукт, например _1 _, а не реализовать систему пользовательского поиска на основе redis.

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

Во-первых, как сохранить данные клиента, такие как ваш образец клиента, в redis. Вы знаете, что redis - это база данных K-V в памяти, поэтому вы можете хранить объект или данные json в виде структуры redis Hash с ее ключом, используя уникальный префикс Id & a, как показано ниже.

CUSTOM#123 => 
  Id => 123
  Name => Bob Smith
  Age => 72,
  Postcode => AB123EF
  Email => [email protected]
  Telephones#0 => 07710123456
  Telephones#1 => 01453123456

Во-вторых, чтобы построить индексы для всех свойств класса объекта, используя структуру redis List или Sorted Set, как показано ниже.

Например, использование List для свойств Name и Age. Идея состоит в том, чтобы использовать префикс типа NAME concat Name значение объекта типа Bob с символом # для создания ключа redis и сохранения значения Id как элемента redis List.

\\ To build `NAME` index for all objects contains `Bob`, `Smith` and `Bob Smith` in the `Name` propertory
NAME#Bob => 123, ... 
NAME#Smith => 123, ...
NAME#Bob Smith => 123, ...
\\ Do the same operation above to build `AGE` index
AGE#72 => 123, ...

Наконец, вы можете искать Bob в ключах redis с префиксом NAME#, используя команду GET NAME#Bob, чтобы получить список клиентов Id точно, или команду keys NAME#Bob*, чтобы получить список клиентов Id нечетко, после чего вы можете непрерывно получать эти данные клиентов, содержащие Name свойство со значением Bob. Если вы хотите отсортировать список клиентов Id, вы должны использовать Sorted Set вместо List для сортировки результатов списка Id.

Я по-прежнему рекомендую вам использовать зрелый продукт, основанный на Redis, например RediSearch, это поможет вам быстро реализовать ваши потребности.

person Peter Pan    schedule 23.10.2019
comment
Спасибо за ответ. Реализация azure не поддерживает Redisearch из коробки, поэтому, если мы разместим его там, нам придется пойти по маршруту докеров. Однако другой вариант - разместить его в нашей собственной архитектуре. - person Tom; 01.11.2019