Orientdb: Prise en charge du Big Data pour l'index de hachage

L'implémentation actuelle de l'index de hachage ne nécessite qu'une seule E/S pour la lecture et au plus 3 E/S pour l'écriture, mais nous souffrons toujours d'une surcharge d'E/S aléatoires. Les E/S aléatoires moyennes prennent 20 ms, c'est très lent. L'optimisation actuelle du cache d'écriture amortit ce surcoût mais nous en souffrirons toujours en cas d'insertions massives. Pour éviter cette surcharge, il est bon d'avoir des optimisations qui ont été appliquées pour les essais LSM. Dans l'arbre LSM de nutshed, il y a un dictionnaire trié, dont une instance en mémoire et une seconde sur le disque, ces instances sont fusionnées en arrière-plan à l'aide de très gros morceaux de données, nous n'aurons donc pas 3 E/S pour l'écriture mais environ 3/16 E/S pour une écriture unique qui est beaucoup plus rapide si nous prenons également en compte le fait que des optimisations supplémentaires du cache d'écriture seront appliquées, nous aurons une implémentation d'index très très rapide. L'optimisation supplémentaire est l'utilisation du filtre Bloom, mais sans compter celui qui est le gaspillage total des ressources du serveur.

Mais cela consomme aussi beaucoup de ressources, 4 mois pour une personne seule et environ 2,5 mois pour deux personnes. Mais le résultat devrait être vraiment précieux.

Cette optimisation devrait être implémentée après https://github.com/orientechnologies/orientdb/issues/1756 issue.