Лучший способ кешировать коллекцию объектов.Вместе или как отдельные предметы?

Question

Скажем, у меня есть коллекция пользователей. У каждого пользователя есть User_ID , Имя пользователя и Tenant_ID .

Иногда мне нужны все пользователи для определенного Tenant_ID .
Иногда мне нужен конкретный пользователь на основе User_ID".
Иногда мне нужен пользователь на основе Имя пользователя .

У меня всегда будет Tenant_ID, доступный для использования в качестве части поиска.

Каков идеальный способ реализации слоя кэша для этих данных?
Какие соображения мне следует учитывать, поскольку я имею дело с мультитенантной системой?
Каков наилучший способ управления всеми возможными ключами кэша?

Опция № 1: Хранить всех пользователей вместе под одной клавишей "Tenant_1_Users"

Проблема в том, что я буду передавать много нежелательных данных по проводам. Если мне просто нужно найти конкретного пользователя, то мне нужно выполнить поиск в коде с использованием LINQ или чего-то еще после извлечения целых коллекций.

Опция # 2: Дублировать один и тот же объект User под разными ключами, такими как "TenantID_1_UserID_5" и "TenantID_1_Username_Jason".

Проблема здесь заключается в управлении всеми различными ключами и расположением объектов пользователя. Особенно, если мне нужно очистить конкретного пользователя, потому что он был обновлен в базе данных. Теперь мне нужно знать все возможные места, где он может храниться. Также использует больше памяти, поскольку один и тот же пользователь может находиться под разными клавишами.

Похожие: AppFabric Cache 'Design' - кэширование отдельных элементов или коллекций?
Проблема заключается в том, что Azure AppFabric Caching не поддерживает регионы, теги или уведомления.

Answer 1

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

Answer 2

Раньше я отдельно добавлял элементы в кеш, отключая кеш первичного ключа записи.Затем, при необходимости, я поддерживал объект словаря, который позволил мне быстро найти первичный ключ (и) на основе некоторого другого значения.Когда мне это понадобилось, я бы создал собственный класс коллекции, который обернул бы всю логику для обслуживания словаря, поиска записей, которые истекли из кэша, поиска записей, которые никогда не были добавлены в кэш, предоставляя средства доступа для извлечения элементов с помощьюих различные значения и т. д. Эта структура сделала так, что каждый элемент данных мог истечь индивидуально, не забирая с собой оставшуюся часть коллекции, но мои словари по-прежнему сохраняли список принадлежащих ключей, каким вторичным значениям я мог восстановить просроченныйэлемент легко, независимо от того, какой метод доступа использовался для его запроса.

Не могу сказать, что это обязательно лучший способ, но, похоже, он хорошо работает для сокращения обращений к хранилищу данных без остановки сервера приложений, потому что онбыло слишком много в памяти.Когда я разрабатывал эту технику, я работал со стандартным ASP.NET и SQL-сервером, но не вижу причин, по которым он не может быть преобразован в облачную среду.

Answer 3

В этом случае у меня возникнет соблазн сделать что-то вроде:

List<User> users = [list of users]
Dictionary<string,int> userIDLookup = ...
Dictionary<string,int> tennantIDLookup = ...
Dictionary<string,int> usernameLookup = ...

Это дает преимущества, связанные с кэшированием одного объекта с помощью нескольких словарей поиска, которые обеспечивают индекс в списке.Вы можете инкапсулировать это в несколько хороших методов, таких как GetUserFromName (строка username) ... и т. Д. ..., чтобы упростить использование в вашем коде.Может быть, все собрано в классе UserCache, чтобы вы могли создать экземпляр кеша и вызвать для него методы поиска.