Dilemme de conception de couche métier: mémoire ou E/S?

Question

Le projet sur lequel je travaille est confronté à un dilemme de conception sur la façon d'obtenir des objets et des collections d'objets à partir d'une base de données. Il est parfois utile de mettre en mémoire tampon * tous les objets * objets de la base de données avec ses propriétés en mémoire, il est parfois utile de simplement définir un ID objet et interroger ses propriétés à la demande (appel 1 db par objet pour obtenir toutes les propriétés). Et dans de nombreux cas, les collections doivent prendre en charge à la fois la mise en mémoire tampon des objets en mémoire et leur initialisation avec un minimum d'informations pour un accès à la demande. Après tout, tout ne peut pas être mis en mémoire et tout ne peut pas être lu à la demande. C'est un problème de mémoire omniprésent vs IO.

Quelqu'un at-il dû faire face au même problème? Comment a affecté votre conception? Quelles sont les leçons difficiles apprises? D'autres pensées et recommandations?

EDIT: mon projet est un exemple classique d'une DLL de couche de gestion, consommée par une application Web, des services Web et une application de bureau. Lorsqu'une liste de produits est demandée pour une application de bureau et affichée uniquement par nom de produit, cette séquence d'étapes est acceptable pour afficher tous les produits (disons qu'il y a un million de produits dans la base de données):
db appeler pour obtenir tous les noms de produits
2. Un appel db pour obtenir toutes les informations produit si l'utilisateur clique sur le produit pour voir les détails (accès à la demande)

Cependant, si cette même API va être consommée par un service Web pour afficher tous les produits avec des détails, le trafic réseau deviendra bavard. La meilleure séquence dans ce cas serait:
1. Que diable, tampon tous les produits et les champs de produits d'un seul appel db (dans ce cas en mémoire tampon des produits 1 million semble aussi effrayant)

Answer 1

Cela dépend à quelle fréquence les données changements. Il est courant de mettre en cache des données statiques et quasi statiques (généralement avec une fenêtre d'expiration du cache).

Les bases de données sont déjà conçues pour mettre en cache des données, de sorte que les E/S réseau fournies ne constituent pas un goulot d'étranglement, laissez la base de données faire ce qu'elle sait faire.

Avez-vous examiné certaines des technologies de mise en cache disponibles?

• .NET Framework 4 ObjectCache Class

• Cache Class: Using the ASP.NET Cache outside of ASP.NET

• Velocity: Build Better Data-Driven Apps With Distributed Caching

• Object cache for C#

Answer 2

Ce n'est pas un p populaire osition, mais évitez toute mise en cache à moins que ce ne soit absolument nécessaire ou si vous savez immédiatement que vous allez avoir besoin de "l'échelle Internet". Vous avez essayé d'étendre un cache en couches au sommet de la base de données? Allez-vous écrire dans le cache et ne lire ou attendre qu'un objet LRU pour écrire des modifications? que se passe-t-il lorsqu'une autre application ou un niveau de services Web est placé sur la base de données et obtient des lectures incohérentes?

La plupart des bases de données modernes ont déjà un cache et peuvent probablement les implémenter mieux que vous, il suffit de déterminer si vous voulez toucher le câble DB chaque fois que vous avez besoin de quelque chose. Dans la grande majorité des cas, le DB fonctionnera très bien et vous garderez votre cohérence.La théorie de BASE et de CAP est agréable et amusante à discuter et à imaginer, mais parfois, vous ne pouvez pas battre le coût-de-marché juste en touchant la bonne vieille base de données. Stress test et déterminez vos hotspots, implémentez votre cache de manière conservatrice si nécessaire.