Les fichiers mappés en mémoire sont-ils défectueux pour les données en constante évolution?

Question

Je dispose d'un service chargé de collecter un flux de données en continu à partir du réseau. L'objectif est que l'ensemble de données complet puisse être utilisé (en lecture seule) à tout moment. Cela signifie que le dernier message de données qui arrive au plus ancien doit être accessible au code client.

Le plan actuel consiste à utiliser un fichier mappé en mémoire sous Windows. Principalement parce que l'ensemble de données est énorme, couvrant des dizaines de GiB. Il n'y a aucun moyen de savoir quelle partie des données sera nécessaire, mais lorsque cela est nécessaire, le client peut avoir besoin de sauter à volonté.

Les fichiers mappés en mémoire conviennent parfaitement. Cependant, j'ai vu (écrit) qu'ils sont meilleurs pour les ensembles de données qui sont déjà définis et ne changent pas constamment. Est-ce vrai? Est-ce que le scénario que j'ai décrit ci-dessus fonctionne raisonnablement bien avec des fichiers mappés en mémoire? Ou est-il mieux de conserver un fichier mappé en mémoire pour toutes les données jusqu'à un certain nombre de Mo de données récentes, de sorte que le fichier mappé en mémoire contienne près de 99% de l'historique des données entrantes, mais je stocke le le plus récent, disons 100 Mo dans un tampon mémoire séparé. Chaque fois que ce tampon est plein, je le déplace vers le fichier mappé en mémoire et l'efface ensuite.

Answer 1

Tout ensemble de données défini et qui ne change pas est le meilleur!
Les fichiers mappés en mémoire gagnent généralement quelque chose d'autre - la plupart des systèmes d'exploitation mettront en cache les accès dans la RAM de toute façon. Et la performance sera prévisible, vous ne tombez pas d'une falaise lorsque vous commencez à échanger.

Answer 2

Semble comme une base de données correspond à votre description. La radiomessagerie est quelque chose que la plupart des commerciaux font bien hors de la boîte.

Answer 3

À partir de votre déclaration de problème, je vois exigences suivantes:

données
1. doivent toujours être données disponibles
2. est écrit une fois, je suppose qu'il est append, jamais écrasé.
3. données lues modèle d'accès est aléatoire, i.e. sautiller
4. il semble aussi avoir une exigence de latence implicite

me semble, un fichier de mémoire mappée est choisi pour répondre à 3) + 4). Si votre taille de données peut être mise en mémoire, cela peut être une solution raisonnable. Toutefois, si la taille de vos données est trop grande pour tenir dans la mémoire, le fichier mappé en mémoire peut entraîner des problèmes de performances en raison de fréquentes erreurs de page.

Vous n'avez pas décrit comment "sauter" est fait. S'il est possible de créer un index, vous pouvez sauvegarder les données dans plusieurs fichiers, conserver l'index en mémoire, utiliser l'index pour charger les données et servir, et également mettre en cache les données les plus fréquemment utilisées. L'idée de base est similaire au hachage sur disque. C'est probablement une solution plus évolutive.

Answer 4

Depuis que vous avez étiqueté ce Win32, je suppose que vous travaillez sur une machine 32 bits, auquel cas vous n'avez tout simplement pas assez d'espace d'adressage pour mapper la mémoire de tous vos fichiers. Cela signifie que vous devrez créer et détruire les mappages dans le fichier lorsque vous "sauterez", ce qui rendra cette opération moins efficace que vous ne le pensez. En pratique, vous disposez généralement d'un peu plus de 1 Go d'espace d'adressage contigu pour mapper le fichier sur une fenêtre Windows de 32 bits, et vous pouvez vous retrouver avec moins si vous fragmentez votre espace d'adressage.Cela étant dit, faire cela avec des cartes mémoire a un avantage si vous avez de la mémoire (pas d'espace d'adressage) contraint, puisque lorsque vous faites correspondre un fichier en lecture seule (par opposition à une lecture explicite en mémoire), le système d'exploitation n'aura pas de deuxième copie dans le cache du système de fichiers.

Answer 5

Le fichier peut être mappé en lecture seule dans un thread qui présente les données et possède un thread de travail en arrière-plan qui a le fichier mappé en tant que readwrite pour effectuer l'ajout.