Application Web - architecture de cache

Question

J'ai une application .Net et un service WCF que j'utilise pour mettre en cache les éléments dans l'ordre chronologique en utilisant SortedSet. Il stocke certaines méta-données que j'utilise pour récupérer le DatabaseId alors la requête sur le Db serait beaucoup plus rapide. J'ai besoin d'aide sur la meilleure/juste/l'architecture la plus appropriée.

Le service contient un SortedSet dans un singleton. Les données stockées sont

public class MyData : IComparable<MyData> { 
    DateTime CreateDate {get; set;} 
    List<int> AccountIds {get; set;} 
    long DatabaseId {get; set;} 

    // implementation to sort by CreateDate 
} 

J'ai une méthode qui a le contrat

List<int> GetDatabaseIds(DateTime startRange, DateTime endRange, 
    List<int> accountIds) 

Cette méthode serait alors passer par le SortedSet, utilisez le GetViewBetween (en utilisant le champ CreateDate), délivre alors une requête LINQ pour renvoyer uniquement les DatabaseIds où les AccountIds correspondent. Cela accélère la récupération de la base de données, mais au fur et à mesure que le nombre d'enregistrements augmente, les besoins en mémoire augmentent également. J'ai expérimenté AppFabric Cache, MemCached et je les ai trouvés non utilisables car ils stockent des éléments dans Key/Value. Peut-être que je me trompe, mais ces produits peuvent-ils être utilisés, si oui comment? Sinon, quelles autres façons puis-je utiliser pour stocker les données séquentielles (par date) pour obtenir les DatabaseIds correspondants?

Mise à jour

La raison pour laquelle je suis pourquoi je fais est que la recherche dans la base de données est directement plutôt lent, et les éléments qui sont stockés dans la base de données ne sont pas toujours dans l'ordre chronologique. Si je peux juste passer dans le DatabaseId, la base de données a seulement besoin de faire une recherche sur le PK. Cela me permettrait également d'utiliser MemCached pour stocker les données en minimisant l'accès à la base de données. C'est le but le plus élevé. Aussi, j'aurais besoin des serveurs web pour évoluer, c'est pourquoi je l'ai déplacé hors du Runtime.Cache vers quelque chose d'externe. Je ne suis pas sûr à 100% que j'ai vraiment besoin de ce genre de mise en cache, mais lorsque j'interrogais la base de données directement, il y aurait un décalage beaucoup plus important même avec les bons index en place. En utilisant cette méthode, la recherche WCF renvoie des résultats dans environ 20 ms (avec environ 1.000.000 enregistrements) et la requête db serait très rapide (ne peut pas rappeler le calendrier). Je suis également fatigué que l'utilisation commence à grimper, cette WCF ne serait pas échelle.

En outre, j'ai pensé à stocker l'intégralité de SortedList dans le cache, mais la conversion en/from/constant l'a rendu plutôt lent.

Je m'attends à ce que le nombre de lignes augmente d'au moins 10 000/jour et que les enregistrements soient ajoutés à tout moment via une autre méthode WCF.

Peut-être ce que je l'ai fait est complètement faux, mais quelques choses que j'ai pensé sont:

1. Créer une nouvelle table dans la Db qui stocke exactement comme je l'ai dans le cache. Continuez à essayer d'optimiser la requête/base de données pour que la requête soit beaucoup plus rapide.
2. Gardez le service WCF, mais créez un nouveau champ ExpiryDate et expirez, De cette façon, les vieux trucs non utilisés ne resteront pas longtemps.

Idées ??

Answer 1

Vous pouvez utiliser un cache personnalisé comme celui que j'ai ici: http://www.itsalltechnical.com/2011/01/non-web-expiring-generic-cache-in-c.html

Je mentionne cela parce que vous pouvez personnaliser la façon dont vous récupérez les données si vous ne souhaitez pas l'accès de style dictionnaire. Je pense que dans la plupart des structures de mise en cache, vous verrez la même méthodologie de dictionnaire, de sorte que vous pourriez être coincé là. Vous pourriez envisager d'utiliser un autre type de persistance basée sur les objets à grande vitesse comme MongoDB ou Cassandra (fonctionne pour facebook) pour le débit. Heureusement, vous avez beaucoup d'options.