Първо, Solr не използва B-дървета. Индексът на Lucene (основната библиотека, използвана от Solr) е съставен от сегменти
. За всеки сегмент Lucene поддържа терминологичен речник, който се състои от списък с термини, които се появяват в сегмента, лексикографски сортирани. Търсенето на термин в този терминологичен речник се извършва чрез двоично търсене, така че цената на търсене с един термин е O(log(t)) където t е броят на членовете. Напротив, използването на индекса на стандартна RDBMS струва O(log(d)) където d е броят на документите. Когато много документи споделят една и съща стойност за дадено поле, това може да бъде голяма победа.
Освен това комитерът на Lucene Uwe Schindler добави поддръжка за много производителен заявки за числов диапазон преди няколко години. За всяка стойност на числово поле , Lucene съхранява няколко стойности с различна точност. Това позволява на Lucene да изпълнява заявки за обхват много ефективно. Тъй като вашият случай на използване изглежда използва много заявки за числови диапазони, това може да обясни защо Solr е много по-бърз. (За повече информация прочетете javadocs, които са много интересни и дават връзки към подходящи научни статии.)
Но Solr може да направи това само защото няма всички ограничения, които RDBMS има. Например, Solr е много лош при актуализирането на един документ наведнъж (предпочита пакетните актуализации).
