Quelqu'un peut-il suggérer une API de mémoire partagée hautes performances prenant en charge des données complexes?

Question

Je cherche à porter un ancien pilote qui génère un grand ensemble complexe de tables de données dans l'espace utilisateur - parce que les tables sont devenues assez grandes pour que la consommation de mémoire soit un sérieux problème. Comme les performances sont critiques et qu'il y aura 16 à 32 lecteurs simultanés de données, nous avons pensé remplacer l'ancienne interface/dev par le code avec un modèle de mémoire partagée qui permettrait aux clients de rechercher directement les tables plutôt que d'interroger le démon directement. La question est - quelle est la meilleure façon de le faire? Je pourrais directement utiliser shm_open(), mais cela me demanderait probablement de concevoir mon propre verrouillage d'enregistrement et même, éventuellement, une structure de données ISAM pour la mémoire partagée.

Plutôt que d'écrire mon propre code pour revisiter les années 1970, existe-t-il une API de mémoire partagée à haute performance qui fournit un mécanisme de recherche basé sur le hachage? Les données sont complètement numériques, les clés de recherche sont des champs de bits de longueur fixe qui peuvent avoir une longueur de 8, 16 ou 32 octets.

Answer 1

C'est quelque chose que je voulais écrire pendant un certain temps, mais il y a toujours quelque chose de plus urgent à faire ...

encore, pour la plupart des usecases d'un magasin de RAM données clé partagée, memcached serait la réponse la plus simple.

Dans votre cas, il semble que ce soit de niveau inférieur, de sorte que memcached, aussi rapide soit-il, n'est peut-être pas la meilleure réponse. Je vais essayer Judy Arrays sur un bloc shmem. Ils sont très rapides, donc même si vous enchaînez l'accès avec un verrou simpliste, vous obtiendrez toujours un accès haute performance.

Pour les tâches plus complexes, je cherche sur les structures sans blocage (quelques liens: 1, 2, 3, 4). J'ai même écrit one il y a quelque temps, avec hopes de l'intégrer dans un noyau Lua, mais il s'est avéré très difficile de conserver l'implémentation existante. Cependant, cela pourrait vous intéresser.