Besoin de connaître les avantages et les inconvénients de l'utilisation de la ramdirectory

Un ramdirectory est plus rapide, mais ne s'écrit pas sur le disque. Il n'existe que tant que votre programme est en cours d'exécution et doit être créé à partir de zéro chaque fois que votre programme fonctionne.

Si votre index est suffisamment petit pour s'adapter confortablement dans la RAM et que vous ne la mettez pas à la mise à jour fréquemment, vous pouvez maintenir un index sur le disque, puis créer une ramdirectory à partir de celui-ci à l'aide de la RAMDirectory constructeur. Interrogation qui devrait ensuite être plus rapide que d'interroger celui sur disque, une fois que vous avez payé la pénalité de le charger. Mais mesurez la différence - si l'indice peut s'intégrer dans la mémoire en tant que ramdirectory, il peut également s'adapter dans le cache de disque, de sorte que vous ne voyez peut-être pas beaucoup de différence.

Vous devriez profiler l'utilisation de la ramdirectory. Au moins sous Linux, l'utilisation de la RamDirectory n'est pas plus rapide que l'utilisation de la FSDirectory par défaut, en raison de la manière dont les tampons d'OS I / O.

Je comparez FSDirectory et RamDirectory.

• La taille de l'index est de 1,4 g
• Centos, Mémoire 5G

  Rechercher 1000 mots-clés, le temps de réponse moyen / min / max (MS) est ici

  • FSDirectory
    • première exécution: 357/7/2611
    • Deuxième exécution: 47/7/837
    • Troisième exécution (Application de redémarrage): 53/7/2343
    • ramdirectory
      • première course: 38/7/1133
      • Deuxième exécution: 34/7/189
      • troisième exécution (apps de redémarrage): 38/7/959

        Donc, vous pouvez voir que RamDirectory est faire plus vite puis FSDirectory, mais après le réchauffement du cache du fichier OS ', l'écart de vitesse n'est pas si distinct. Quel est l'inconvénient de la rmadirectory? Dans mon test

        • Il mange beaucoup plus de mémoire, le fichier 1.4G a besoin d'environ 2G pour le charger dans la mémoire. tandis que FSDirectory utilise seulement 700 m. Ensuite, cela signifie plus longtemps pour GC complet.
        • Il a besoin de plus de temps pour charger, en particulier lorsque le fichier d'index est grand. Il a besoin de copier les données du fichier en mémoire lors de l'ouverture de l'index. Cela signifie que les demandes seraient bloquées pour plus de temps lors de la redémarrage de l'application.
        • Ce n'est pas si pratique de maintenir deux index en même temps. Parce que notre application commute l'index toutes les plusieurs heures. Nous voulons que nouvel indice s'échauffe lorsque l'ancien Index travaille toujours dans le même Tomcat.