Вычислимая, высокопроизводительная схема пользовательского поля

задняя часть

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

Здесь я поделюсь еще одной хитрой идеей, которая может не только гарантировать, что ее можно будет получить через настраиваемые поля, но и добиться высокой эффективности запросов. Мы используем комбинацию Redis и постоянной базы данных.

дизайн пространства имен Redis

Ключевой формат определяемого пользователем поля (User Defined Field, сокращенно udf), хранящегося в Redis:udf:filedName,Как показано ниже:

Соответствующая ему структура данных — хеш, поле — значение поля, а значение — список идентификаторов пользователей (разделенных запятыми).

Постоянные базы данных (mysql, postgresql, mongodb и т. д.) содержат строки JSON.

Нам нужно синхронизировать данные между Redis и mongo/mysql/postgres. Это не сложно, это включает только добавление, удаление и изменение полей, и этого достаточно для синхронизации обеих сторон.

Пример запроса

Сценарий 1: запрос на соответствие значений общего типа

запроситьfavorColour= "КРАСНЫЙ" для всех пользователей:

где ключ редисudf:favorColour

стоимость:

{
    "RED": "用户ID 1",
    "BLUE": "用户ID 2",
    "BLACK": "用户ID 3，用户ID 4"
}

Шаги запроса следующие:

  1. hget udf:favorColour RED, временная сложность O(1)
  2. Если он существует, получить строку, разобрать строку в список идентификаторов пользователей и запросить связанных пользователей.
  3. Если он не существует, получить нуль, указывающий, что ни один пользователь не соответствует условию

Сценарий 2: значение типа коллекции в запросе

Опросить всех пользователей, чьи «профессиональные интересы» включают «информатику и технологии».

ключ Redisudf:interestedCourses

стоимость:

{
    "计算机科学与技术": "用户ID1，用户ID2"
}

Шаги запроса следующие: (то же, что и выше)

  • hget udf:interestedCourses RED, временная сложность O (1)
  • Если он существует, получить строку, разобрать строку в список идентификаторов пользователей и запросить связанных пользователей.
  • Если он не существует, получить нуль, указывающий, что ни один пользователь не соответствует условию

Сценарий 3. Запрос всех данных настраиваемых полей, принадлежащих пользователю

Здесь идентификатор пользователя проверяется непосредственно в базе данных, а временная сложность по-прежнему составляет O (1).После проверки строка может быть напрямую преобразована в JSON.

Категории