Да, вопрос запутанный.Если вы знаете лучший способ спросить, что я спрашиваю, пожалуйста, поделитесь!
Я разрабатываю независимый REST API с использованием NodeJS и Redis.Сервер настроен на индексирование любых полей, которые установлены для этого в спецификации модели.
Например:
// user object
{
firstName: 'Peter',
lastName: 'Boyd',
role: 'worker'
}
Прямо сейчас, когда пользователь добавляется, поле, которое получаетпроиндексировано поле "роль".База данных будет выглядеть следующим образом:
// user objects stored as regular key
key: "users:<ID1>" | value: "{ ...userData }"
// "role" indexes stored as hash key
hash key: "users:role" | field: "worker" | value: "users:<ID1>"
Когда добавляется второй пользователь, который также имеет значение «работник» для поля «роль», это выглядит так:
// user objects stored as regular key
key: "users:<ID1>" | value: "{ ...userData1 }"
key: "users:<ID2>" | value: "{ ...userData2 }"
// "role" indexes stored as hash key (previous value gets replaced)
hash key: "users:role" | field: "worker" | value: "users:role:worker"
// "worker" value for "role" gets created as list
key: "users:role:worker" | value: [ "users:<ID1>", "users:<ID2>" ]
Таким образом, вторичный индекс не создается, если он не требуется для экономии места.Вторичный индекс представляет собой список, который содержит ключи пользовательских объектов.Начальное значение индекса содержит ключ этого списка в качестве значения, которое в данном случае равно «users: role: worker».
Это работает хорошо, за исключением случаев, когда несколько пользователей создаются одновременно с пустой базой данных.Этот дизайн индексации не является состоянием состояния, и поэтому он вызывает странные вещи.
Мой вопрос: как я могу улучшить этот дизайн?Я подумал о паре решений, но у каждого из них есть несколько недостатков.
Возможное решение # 1
Создать вторичный индекс (список с ключом "пользователи: роль: работник ") с самого начала.Однако кажется, что это будет пустая трата времени, учитывая, что для каждого поля, имеющего индекс, будет создано две записи, которые часто не нужны.
Возможное решение # 2
Вместо сохранения идентификатора в качестве значения для каждого индекса, сохраните строковый массив идентификаторов.Это предотвратит создание вторичного списка.Новые идентификаторы пользователей будут просто добавлены в массив строк.Однако этот метод означает, что массив строк будет перезаписываться при добавлении нового пользователя.Это заставляет меня думать, что одновременные запросы просто перезаписывают друг друга, что приводит к нежелательным результатам.
Что вы думаете?Есть ли лучший дизайн, чтобы справиться с этим?
Помощь и отзывы очень важны!