hashmap de mémoire faible recommandé pour l'implémentation pour Java

Question

Je travaille actuellement sur un problème lié à la programmation où je suis tenté de faire une hashmap massive de données. La clé pour les données est une implémentation personnalisée en mémoire basse d'une CharSequence qui implémente hashCode() et est égale à (...) et la valeur est un objet Integer.

Il peut y avoir des millions d'entrées dans cette hashtable et j'ai réussi à réduire drastiquement l'utilisation de la mémoire pour la valeur en ayant l'entier comme pointeur dans un fichier vers les données que je souhaite hacher mais le problème est que la clé des dizaines d'octets (en moyenne 25 octets) et que les clés doivent être conservées en mémoire dans l'implémentation par défaut de HashMap.

J'ai besoin d'un hashmap qui a un faible en-tête de mémoire et qui peut éventuellement paginer les clés sur le disque ou bien stocker une représentation hachée des clés. Si les clés sont elles-mêmes hachées alors je serais préoccupé par les collisions de hachage.

Idéalement, je voudrais pouvoir stocker un million d'entrées dans la carte par 50 Mo d'espace de segment (un tableau de 25 octets dans la clé et un objet entier dans la partie valeur).

Est-ce que quelqu'un a de l'expérience avec des cartes sauvegardées sur un système de fichiers à mémoire faible qui sont optimisées pour réduire l'encombrement des touches?

Merci,

Chris

Answer 1

Vous pouvez utiliser la table de hachage Java et écrire une classe FileKey qui prend un RandomAccessFile, décalage et longueur, précalculer le hachage à la construction et qui implémente Comparable en lisant les données du fichier juste pour la comparaison.

En conjonction avec un simple cache MRU, vous pouvez conserver un certain nombre de clés en mémoire en utilisant un autre hashmap qui est claveté sur les mêmes touches, mais qui utilise un comparateur personnalisé qui compare uniquement les valeurs de décalage et de longueur Les données).

Answer 2

Que diriez-vous Berkeley DB Java Edition? Sa classe StoredMap ressemble à ce que vous cherchez.

Answer 3

Je pense que la valeur par défaut HashSet n'est pas un mauvais choix: créez vous-même la paire valeur/clé (vous n'avez donc pas besoin de les placer dans un objet supplémentaire). C'est très efficace sur le plan de la mémoire de cette façon; il faut seulement environ (1/loadFactor)^(3/2) * 4 octets de plus de mémoire sur votre objet clé + 4 octets pour la valeur. En pratique, cela devrait ajouter quelque chose comme 8 octets de frais généraux par entrée. (Vous pouvez réduire cela davantage si vous savez à l'avance combien de clés vous allez stocker.)