La mejor manera de almacenar en caché una colección de objetos. ¿Juntos o como artículos individuales?

Question

Supongamos que tengo una colección de usuarios. Cada usuario tiene un User_ID, Nombre de usuario y Tenant_ID.

A veces necesito todos los usuarios para un Tenant_ID específico.
A veces necesito un usuario específico basado en User_ID".
A veces necesito un usuario basado en nombre de usuario.

siempre tendré la Tenant_ID disponibles para su uso como parte de las operaciones de búsqueda.

¿Cuál es la forma ideal de implementar una capa de caché para estos datos?
¿Qué consideraciones debo considerar ya que estoy tratando con un sistema de varios inquilinos?
¿Cuál es la mejor forma de administrar todas las claves de caché posibles?

Opción # 1: tienda todos los usuarios juntos bajo una única clave de "Tenant_1_Users"

El problema con esto es que va a transferir una gran cantidad de datos no deseados sobre el alambre. Si solo necesito encontrar un usuario específico, entonces necesito hacer la búsqueda en el código usando LINQ o algo después de recuperar todas las colecciones.

Opción n. ° 2: Duplicar el mismo objeto Usuario bajo diferentes teclas como "TenantID_1_UserID_5" y "TenantID_1_Username_Jason".

El problema aquí es administrar todas las diversas claves y la ubicación de los objetos de usuario. Especialmente si necesito enjuagar un usuario específico porque se ha actualizado en la base de datos. Ahora necesito saber todos los lugares posibles donde podría almacenarse. También usa más memoria ya que el mismo usuario puede estar bajo diferentes teclas.

Relacionados: AppFabric Cache 'Design' - Caching Individual Items or Collections?
El problema es que Azure AppFabric Caching no admite regiones, etiquetas o notificaciones.

Answer 1

Por lo que vale, tendería a no querer almacenar en caché el mismo objeto en varias claves, porque si necesita actualizar o eliminar ese registro más tarde, deberá recordar actualizar/eliminar todas las claves posibles que podría haber usado.

Answer 2

En el pasado he agregado elementos a la memoria caché individualmente, quitando la memoria caché de la clave principal del registro. Luego, cuando fue necesario, mantuve un objeto de diccionario que me dio una búsqueda rápida para encontrar la (s) clave (s) primaria (s) en función de algún otro valor. Cuando lo necesitaba, creaba una clase de colección personalizada que completaba toda la lógica para mantener el diccionario, buscaba los registros que habían expirado de la memoria caché, buscaba registros que nunca se agregaban a la memoria caché, proporcionaba accesodores para recuperar elementos por sus diversos valores, etc. Esta estructura hizo que cada elemento de datos pudiera caducar individualmente sin llevar consigo el resto de la colección, pero mis diccionarios aún mantendrían la lista de las claves que pertenecían a qué valores secundarios para poder restaurar un elemento caducado. elemento fácilmente, sin importar qué acceso fue utilizado para solicitarlo.

No puedo decir que esto sea necesariamente la mejor manera, pero parecía funcionar bien para reducir los viajes al almacén de datos sin atascar el servidor de la aplicación porque tenía demasiado amontonado en la memoria. Estaba trabajando con ASP.NET estándar y un backend SQL cuando desarrollé esta técnica, pero no veo ninguna razón por la cual no podría convertirse a un entorno de nube.

Answer 3

En este caso estaría tentado a hacer algo como:

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

Esto tiene las ventajas de un único objeto de ser almacenados en caché con múltiples diccionarios de búsqueda que proporcionan el índice en la lista. Podría encapsular esto en algunos buenos métodos como GetUserFromName (string username) ... etc ... para que sea más fácil de usar en su código. Tal vez todos juntos en una clase UserCache para que pueda instanciar el caché y llamar a los métodos de búsqueda en él.