[LIB] librairie de cache en C ?

Bonjour,

Après quelques recherches je n'ai pas réussi à trouver de librairie C pour gérer un cache de mémoire.
J'ai vu libmemcache mais cette dernière nécessite l'installation du daemon memcache pour pouvoir fonctionner.

Existe-t-il une librairie de gestion de cache mémoire en C qui ne nécessite pas l'installation d'un programme tiers ?

J'en aurais besoin pour stocker le resultat de requêtes SQL afin de limiter les accès à la base de données.

Merci d'avance

Pourquoi ne pas le faire toi-même avec un simple système LRU? Cela ne devrait pas prendre trop de temps et tu aurais la plus grande prise sur ce qu'il s'y passe.

Jc

Les resultats de mes requêtes SQL sont stockés dans des structures, ce sont donc ces structures que je souhaite monter en cache. Il y a plusieurs types de structures différentes bien sûr.

Comment ça s'implémente une pile LRU, avec une liste chainée ?

Pour identifier les éléments de mon cache je dois utiliser une sorte de checksum je suppose ?

Etant donné la charge imposée à mon programme, plusieurs occurences du même binaire sont executés et tournent en parrallèle. Pour que chaque occurence puisse partager le même cache, il faut utiliser de la mémoire partagé non ?

Je sens que ça va pas être simple à faire ce truc 8O

Citation:

---

tant donné la charge imposée à mon programme, plusieurs occurences du même binaire sont executés et tournent en parrallèle. Pour que chaque occurence puisse partager le même cache, il faut utiliser de la mémoire partagé non ?

---

Si tu as plusieurs processus qui tournent en parallèle (soit plusieurs executables, ou soit des fork), alors oui, à priori il faudra de la mémoire partagée.

Mais si c'est toi qui a concu le programme, est-ce que tu ne peux pas passer à une gestion threadée ? Ca sera plus simple au niveau de la mise en oeuvre je pense, puisque les threads d'un même processus partagent le même espace mémoire.

Le système de thread me paraît plutôt difficile à mettre en place au niveau humain, je ne suis pas le seul à gérer cette application, et surtout pas celui qui décide des modifications majeures ! Je peux proposer bien sûr mais je connais déjà la réponse, c'est un peu la politique maison, tant que ça marche, pourquoi changer !

Merci quand même. :P

Bon alors ya pas de librairie de cache en C ??!!! :x

Quand on voit la profusion de librairies en Java, en C on a vraiment que les yeux pour pleurer... :evil:
C'est dingue alors que le C est quand même beaucoup plus vieux que la Java. :?

Citation:

---

Envoyé par tomasha

Bon alors ya pas de librairie de cache en C ??!!! :x

---

Il n'y a rien de standard.

Je ne vois pas bien ce que tu appelles "librairie (bibliothèque) de cache".

Ca me semble soit très 'applicatif' (genre, je tape le début d'une commande, et la suite vient toute seule par défaut), soit éventuellement 'système' (auquel cas, ce serait plus une fonction du serveur que du client, AMA...).

C'est pour économiser quoi exactement ?

Apparemment, une sorte de table de hachage:
requete SQL --> structure contenant les résultats

Citation:

---

Comment ça s'implémente une pile LRU, avec une liste chainée ?

Pour identifier les éléments de mon cache je dois utiliser une sorte de checksum je suppose ?

---

A mon avis une table de hachage semble plus adaptée, puisque à chaque requète correspond 1 et 1 seul resultat. Le checksum est justement géré par la fonction de hachage. C'est avec cette fonction (CRC, MD5, ...) qu'elle va pouvoir retrouver en temps constant l'élément que tu cherches.

Après à toi d'implémenter un système de "table de hachage LRU" si tu ne veux pas qu'elle dépasse une certaine taille (100 requètes max par exemple). Tu pourrais stocker dans une liste à part (qui elle n'est pas limitée) la fréquence de toutes les requètes et leur état (en cache ou non). Tu pourras ainsi mettre à jour ta table pour qu'elle ne contienne que les requetes le plus fréquentes. Ca peut être fait soit à chaque nouvelle requète (bof), ou alors dans un thread qui effectue la mise à jour dès que le système n'est pas trop surchargé.


Mais on rentre plus dans des considérations algorithmiques. Donc à voir avec le forum correspondant ;) Sauf si tu as des questions sur l'implémentation d'une table de hachage en C bien sûr !

J'appelle "librairie de cache" une librairie permettant le stockage de différentes données structurées, afin d'y accéder rapidement.

Je consulte régulièrement une base de donnée pour récupérer des données, lorsque ces données sont peu volatiles (elles ne changent pas souvent), je souhaiterais les stocker dans un "cache" après la consultation de la base.

Ainsi lorsque je souhaite accéder à ces données, je questionne d'abord le cache, si elles sont là tant mieux, j'économise un accès à la base, sinon je consulte la base et je stocke le résultat dans le cache. Et ainsi de suite.

Je me suis déjà créé une petite librairie qui implémente une table de hashage, mais ça ne stocke que des chaines de caractères, pas des structures...

En fait je stocke mes resultset de requêtes SQL dans des structures dont chaque champs correspond à une colonne du resultset. Suivant les resultset, c'est donc pas les mêmes structures.

Une table de hashage qui stocke du void* c'est faisable ?

Tu peux y stocker ce que tu veux ..... mais le problème est comment retrouver le type de ce que tu as stocké si tu stockes des void* ?

Et je ne suis pas sur de comprendre pourquoi tu devrais y stocker plusieurs types différents ... tu n'as pas de structure RecordSet ? Ou alors tu as peut-être plusieurs RecordSet différents, selon les champs retournés ? (dans ce cas, presque une infinité .... 8O )

Il y a peut être une partie du design à réétudier pour permettre de manipuler ces différents types de recordset facilement.

Citation:

---

Envoyé par bigquick

Tu peux y stocker ce que tu veux ..... mais le problème est comment retrouver le type de ce que tu as stocké si tu stockes des void* ?

---

Oui c'est le principal souci du void* !

Citation:

---

Envoyé par bigquick

Et je ne suis pas sur de comprendre pourquoi tu devrais y stocker plusieurs types différents ... tu n'as pas de structure RecordSet ? Ou alors tu as peut-être plusieurs RecordSet différents, selon les champs retournés ? (dans ce cas, presque une infinité .... 8O )

Il y a peut être une partie du design à réétudier pour permettre de manipuler ces différents types de recordset facilement.

---

RecordSet kesaco ?

ResultSet pardon :oops:

Ah ok :wink:
Donc pour répondre à ta question oui j'ai plusieurs structures différentes qui correspondent chacune à un resultset particulier.

Et comment fais tu pour les différencier pour le moment ? Je pense que le problème sera le même dans la table de hachage si tu stockes des void*, donc ta solution devrait s'appliquer tout aussi bien :)

(et comment fais-tu pour gérer le nombre plus impressionant de resultsets différents qui peuvent être retournés par les requètes SQL ?)

Je connais l'ordre des resultsets, je sais donc où stocker chaque resultset.

Je ne suis pas spur de comprendre (encore :oops:)

J'imagine que le résultat d'une rèquete peut aussi bien être des tableaux de {int,char*,float} que des tableaux de {char*,char*} par exemple. Je ne vois pas comment tu fais pour stocker ces différents résultats.

Tout-à-fait oui, chaque colonne d'un resultset peut avoir un type particulier.

Là où je me suis mal exprimé c'est que ma structure me sert pour stocker UNE ligne du resultset, et donc pour stocker le resultset entier (toutes les lignes) j'utilise un tableau de structure.

Et donc ta structure contient un tableau de void* (un pour chaque colone) ?
Ou est-ce que tu as isolé différents resultsets possibles et créés autant de structures correspondantes ?

2ème solution, j'ai autant de structures que de resultset différents, et autant de champs dans une structure que de colonnes dans le resultset correspondant.

Ca facilite beaucoup l'accès à ces données plutôt qu'un tableau de void*.
Et puis comment tu parcours un tableau de void* ? je doute que l'accès au 6ème champ (par exemple) se fasse par "champ[5]"... :?

Citation:

---

Ca facilite beaucoup l'accès à ces données plutôt qu'un tableau de void*.

---

L'accès est facilité, mais tu dois avoir un nombre de strutures incroyable... si je ne me trompe pas, ca donne quelque chose du genre

Code:

---

1 2 3 4 5

(les nombres choisis sont des exemples) Nombre de types différents existants : 3 (int, float, char*) Nombre de colones max d'une requète : 5   Nombre de structures possibles : 3^1 + 3^2 + 3^3 + 3^4 + 3^5 !!

---

Citation:

---

Et puis comment tu parcours un tableau de void* ? je doute que l'accès au 6ème champ (par exemple) se fasse par "champ[5]"...

---

Si si, bien sûr, comme pour un tableau de n'importe quel type. Seulement, il va falloir caster ton void* en un type concret (int*, float*, ...) pour pouvoir l'utiliser. Il te faut donc des infos en plus, stockées dans ton resultset, pour savoir de quel type est chaque colone.


Par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

enum type { entier, flottant, chaine };   struct resultset { int nb_colones; type* types_colones; // tableau des types contenus void** contenu_colones; // tableau des contenus eux-même (void*) };

---

Mais j'imagine que tu as déjà un code qui fonctionne pour tout cela. Mais c'est vrai que pour mettre en cache ces resultset différents, en programmation non OO, je ne vois pas de solution évidente, à part ce type de cast peu élégant.

Peut-être que quelqu'un peut donner son avis la dessus ?

Désolé mais on a du mal se comprendre, je n'ai pas un nombre hallucinant de structures différentes, juste autant que de resultset définis dans les procédures stockées (gdb sybase).

Exemple dans une proc stockée j'ai :

Code:

---

1 2 3

select codeHotel, numResa, date, numJour from #resa

---

Je stockerais chaque ligne dans une structure

Code:

---

1 2 3 4 5 6 7

typedef struct { char codeHotel[4];; char numResa[12]; char date[10]; short numJour; } Resa

---

et la totalité du resultset dans un tableau de cette structure.

Si jamais le resultset change, je dois changer la structure bien sûr.


Pour ce qui est de ta solution, elle est intéressante, puisqu'elle me permet de n'avoir qu'une seule structure pour tous les resultset, mais l'utilisation me paraît assez fastidieuse, à moins de développer une couche englobant l'implémentation de ce système...

Peux-tu développer un peu plus l'accès à des éléments d'un tableau de void* ?

Merci

Ahhhhhh :D
D'accord, je ne savais pas que tu disposais d'un nombre de requètes bien fixes. A ce moment là, en effet plus de problème, sauf pour le stockage en cache, ou je ne vois pas comment faire cohabiter ces structures au sein d'une même table de hachage.

Pour ce qui est du tableau de void*, l'accès se fait comme dans un tableau normal: tab[5]. Mais tu vas obtenir un void* qu'il faut ensuite caster comme il faut :arrow: il faut donc connaitre le type exact de ce qui se cache derrière, par exemple avec une structure "header" qui indique ce que contiennent tes colones.

Mais quitte à avoir un "selecteur" pour retrouver le type de chaque colone, autant finalement utiliser une union. Par exemple, en modifiant le code du post précédent:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

// types utilisables enum type { entier, flottant, chaine };   // en tête de résultat : les colones typedef struct { int nb_colones; // nombre de colones type* types_colones; // leur type } header;     // une case de ton tableau final (par ex. ligne 3 colone 2) typedef union { int entier; float flottant; char* chaine; } case;     // la totalité des resultats typedef struct { header entete; int nb_resultsets; // nombre de lignes case** resultsets; // tableau représentant les lignes (ligne = case*) } resultat;

---

et maintenant l'utilisation
par exemple si on a fait une requete de type {int, float, char*}

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

resultat r;   r.entete.nb_colones = 3; // int, float, et char* r.entete.types_colones = malloc( r.entete.nb_colones * sizeof(type) ); r.entete.types_colones[0] = entier; r.entete.types_colones[1] = flottant; r.entete.types_colones[2] = chaine;   // on va dire que la requete a retourné 15 lignes r.resultsets = malloc( 15 * sizeof(case*) ); for (int i=0; i<15; ++i) r.resultsets[i] = malloc( r.entete.nb_colones * sizeof(case) );   r.resultsets[0][0].entier = 5; r.resultsets[0][1].flottant = 3.567; r.resultsets[0][2].chaine = ....;   // pour une autre requete qui retourne {char*, int} tu pourrais faire: r.resultsets[0][0].chaine = ...; r.resultsets[0][1].entier = 3; // mais avec un header qui reflete bien cette structure !

---

Pour les récuperer, il faut simplement tester ce qui se trouve dans le header:

Code:

---

1 2	if (r.entete.types_colones[0] == entier) printf("%d\n", r.resultsets[i][0].entier);

---

Voilà, c'était un début d'explication, pas forcément très clair :oops:, mais c'est un moyen comme un autre de stocker toutes tes requetes dans la même structure. Et il faut bien sûr penser a libérer la mémoire allouée :)

Voilà, avec ça pas de problème pour les stocker dans ta table de hachage. Mais quelqu'un a peut-être une autre idée pour utiliser ta méthode courante, avec plusieurs strcture différentes ?

Si si c'est très clair !! :) Merci pour cette solution intéressante, je vais réfléchir à son intégration.

En fait là tu n'utilises finalement pas de tableau de void*, la question que je me posait quant à l'utilisation d'un void**, c'est l'accès au données. En effet tu peux faire en sorte de savoir que le 3ème élément du tableau est un type char ou int (peu importe) et donc le caster en conséquence.
Mais pour y accéder ça me paraît plus hard avec "element[2]" car element[0] peut-être un char[12] et element [1] peut-être un int, donc un taille différente !! Ya une solution à ce genre de problème ?

Mmmm, si tu as un tableau de void*, tu stockes dedans uniquement des pointeurs. Donc des pointeurs sur int, sur char (pour les chaines), sur float .... A toi de caster ton void* en int*, char*, .... en fonction. Par contre ça implique une allocation dynamique systematique, ce qui n'est vraiment pas top niveau performances (*).

Pour éviter cette allocation dynamique, en stockant les types POD directement dans le tableau, je pense qu'il faut passer par une union (comme dans le code du post précédent).

Après, il est même possible de faire une union

Code:

---

1 2 3 4 5 6

union { int entier; float flottant; char chaine[32]; };

---

mais rappelle-toi que l'union va occuper la place de l'élément le plus gros (logique ...). Donc la elle occupera 32 octets, pour chaque case du tableau, même si il n'y a qu'un int stocké dedans :? C'est pas top ....

D'où le char* pour gérer les chaines de caractère dans l'union. Ton union (int,float,char*) ne prendra que 4 octets, donc pas de perte apparente. Et les chaines seront le seul type géré par allocation dynamique dans tes resultset.

--

(*) : <mode déconsillé, pas beau, non portable, et illisible> :nono:
Dans le cas d'un tableau de void*, tu "pourrais" te passer de l'allocation dynamique pour les int et les float. Sur une architecture 32 bits classique ils font tous les deux 4 octets, comme un pointeur. Donc il serait possible de les stocker dans le void*, et des les récuperer tels quels. Mais de jamais (!!!) s'en servir comme pointeur. Enfin de toute façon il ne faut pas le faire :)
</mode déconsillé, pas beau, non portable, et illisible>

Très instructif tout ça, merci !!

J'espère que j'ai pas raconté trop de bétises alors ....
Mais je me suis relu, normalement ça va :)

Ca serai sympa d'avoir un autre avis sur la manière dont tu pourrais procéder pour stocker tes resultats dans ta table de hachage... Pour l'instant, je ne vois qu'un changement de structure :arrow: 1 seule et même structure pour stocker tous les types de résulats.... Il y a peut-être une autre solution...

Mais c'est vrai que l'avantage de celle-ci, si tu découpes bien ton architecture de manière modulaire, c'est qu'il sera facile de rajouter des requètes, puisqu'il faut simplement créer une nouvelle instance de ta structure, avec le bon header, et elle pourra s'ajouter aux autres de manière transparente.

En effet ce serait pratique.