Quand choisiriez-vous une table de hachage plutôt qu'un arbre binaire de recherche équilibré ?

Choisissez une table de hachage quand vous n'avez besoin que de recherches, insertions et suppressions par clé, et que vous voulez du temps constant en moyenne. Choisissez un arbre équilibré quand vous avez besoin d'ordre : parcours d'intervalles, clé la plus proche, ou itération dans l'ordre trié, le tout en temps logarithmique. Les arbres offrent aussi un pire cas prévisible, alors qu'une table de hachage peut se dégrader fortement avec un mauvais hachage ou se bloquer sur un redimensionnement au mauvais moment.

Mon choix par défaut est une table de hachage, parce que la plupart du temps je fais des recherches ponctuelles par id et que le temps constant en moyenne est difficile à battre. Dès que le besoin implique de l'ordre, en revanche, je change. Tout ce qui ressemble à donne-moi tous les événements entre deux horodatages, ou trouve la clé suivante après celle-ci, est une requête par intervalle, et une table de hachage ne peut pas la traiter sans tout parcourir. Ça appelle un arbre, ou en pratique une structure triée avec recherche dichotomique. Je pense aussi à la traîne. Les recherches par hachage sont constantes en moyenne, mais une mauvaise fonction de hachage ou un rehachage peut faire un pic, et dans un budget de latence ça compte pour moi. Sur un classement que j'ai construit, on a commencé avec un dictionnaire utilisateur vers score et il fallait trier tout ça à chaque lecture. Une fois passés à un sorted set dans Redis, les lectures sont devenues logarithmiques et l'endpoint a arrêté de tomber aux heures de pointe. Mêmes données, motif d'accès différent, structure différente.