Po pierwsze, Solr nie używa B-drzewa. Indeks Lucene (bazowej biblioteki używanej przez Solr) składa się z tylko do odczytu segmenty
. Dla każdego segmentu Lucene prowadzi słownik terminów, który składa się z listy terminów pojawiających się w segmencie, posortowanej leksykograficznie. Wyszukiwanie terminu w tym słowniku terminów odbywa się za pomocą wyszukiwania binarnego, więc koszt wyszukiwania pojedynczego terminu wynosi O(log(t)) gdzie t jest liczbą terminów. Wręcz przeciwnie, użycie indeksu standardowego RDBMS kosztuje O(log(d)) gdzie d to liczba dokumentów. Gdy wiele dokumentów ma tę samą wartość dla jakiegoś pola, może to być duża wygrana.
Co więcej, specjalista ds. Lucene, Uwe Schindler, dodał obsługę bardzo wydajnych zapytania dotyczące zakresu liczbowego kilka lat temu. Dla każdej wartości pole liczbowe , Lucene przechowuje kilka wartości z różną precyzją. Dzięki temu Lucene może bardzo wydajnie uruchamiać zapytania dotyczące zakresu. Ponieważ twój przypadek użycia wydaje się bardzo wykorzystywać zapytania z zakresami liczbowymi, może to wyjaśniać, dlaczego Solr jest o wiele szybszy. (Aby uzyskać więcej informacji, przeczytaj bardzo interesujące dokumenty javadocs i podaj linki do odpowiednich artykułów naukowych.)
Ale Solr może to zrobić tylko dlatego, że nie ma wszystkich ograniczeń, jakie ma RDBMS. Na przykład Solr bardzo źle radzi sobie z aktualizacją pojedynczego dokumentu na raz (preferuje aktualizacje wsadowe).
