Antirez a dit, voir dans https://news.ycombinator.com/item?id=1171423
Il y a plusieurs raisons :
- Ils ne sont pas très gourmands en mémoire. C'est à vous de décider. Changer les paramètres sur la probabilité qu'un nœud ait un nombre donné de niveaux rendra alors moins gourmand en mémoire que les btrees.
- Un ensemble trié est souvent la cible de nombreuses opérations ZRANGE ou ZREVRANGE, c'est-à-dire qu'il parcourt la liste de sauts comme une liste chaînée. Avec cette opération, la localité du cache des listes de sauts est au moins aussi bonne qu'avec d'autres types d'arbres équilibrés.
- Ils sont plus simples à mettre en œuvre, à déboguer, etc. Par exemple, grâce à la simplicité des listes de sauts, j'ai reçu un correctif (déjà dans le maître Redis) avec des listes de sauts augmentées implémentant ZRANK en O(log(N)). Cela a nécessité de petites modifications du code.
À propos de la durabilité et de la vitesse d'ajout uniquement, je ne pense pas que ce soit une bonne idée d'optimiser Redis au prix de plus de code et de plus de complexité pour un cas d'utilisation qui, à mon humble avis, devrait être rare pour la cible Redis (fsync() à chaque commande) . Presque personne n'utilise cette fonctionnalité, même avec les bases de données ACID SQL, car l'indice de performance est important de toute façon.
À propos des threads :notre expérience montre que Redis est principalement lié aux E/S. J'utilise des threads pour servir des choses à partir de la mémoire virtuelle. La solution à long terme pour exploiter tous les cœurs, en supposant que votre lien est si rapide que vous pouvez saturer un seul cœur, exécute plusieurs instances de Redis (pas de verrous, presque entièrement évolutive linéairement avec le nombre de cœurs) et utilise le "Redis Cluster " solution que je prévois de développer dans le futur.
