Premièrement, Solr n'utilise pas d'arbres B. Un index Lucene (la bibliothèque sous-jacente utilisée par Solr) est constitué d'un segments
. Pour chaque segment, Lucene maintient un dictionnaire de termes, qui se compose de la liste des termes qui apparaissent dans le segment, triés lexicographiquement. La recherche d'un terme dans ce dictionnaire de termes est effectuée à l'aide d'une recherche binaire, de sorte que le coût d'une recherche d'un seul terme est O(log(t)) où t est le nombre de termes. Au contraire, utiliser l'index d'un SGBDR standard coûte O(log(d)) où d est le nombre de documents. Lorsque de nombreux documents partagent la même valeur pour un champ, cela peut être une grande victoire.
De plus, le committer Lucene Uwe Schindler a ajouté la prise en charge de requêtes de plage numérique il y a quelques années. Pour chaque valeur d'un champ numérique , Lucene stocke plusieurs valeurs avec des précisions différentes. Cela permet à Lucene d'exécuter des requêtes de plage très efficacement. Étant donné que votre cas d'utilisation semble exploiter beaucoup les requêtes de plage numérique, cela peut expliquer pourquoi Solr est tellement plus rapide. (Pour plus d'informations, lisez les javadocs qui sont très intéressants et donnent des liens vers des articles de recherche pertinents.)
Mais Solr ne peut le faire que parce qu'il n'a pas toutes les contraintes d'un SGBDR. Par exemple, Solr est très mauvais pour mettre à jour un seul document à la fois (il préfère les mises à jour par lots).
