Primero, Solr no usa árboles B. Un índice de Lucene (la biblioteca subyacente utilizada por Solr) está compuesto por un índice de solo lectura segmentos
. Para cada segmento, Lucene mantiene un diccionario de términos, que consta de la lista de términos que aparecen en el segmento, ordenados lexicográficamente. La búsqueda de un término en este diccionario de términos se realiza mediante una búsqueda binaria, por lo que el costo de una búsqueda de un solo término es O(log(t)) donde t es el número de términos. Por el contrario, usar el índice de un RDBMS estándar cuesta O(log(d)) donde d es el número de documentos. Cuando muchos documentos comparten el mismo valor para algún campo, esto puede ser una gran victoria.
Además, el responsable de confirmación de Lucene, Uwe Schindler, agregó soporte para consultas de rango numérico Hace unos pocos años. Para cada valor de un campo numérico , Lucene almacena varios valores con diferentes precisiones. Esto le permite a Lucene ejecutar consultas de rango de manera muy eficiente. Dado que su caso de uso parece aprovechar mucho las consultas de rango numérico, esto puede explicar por qué Solr es mucho más rápido. (Para obtener más información, lea los javadocs que son muy interesantes y brindan enlaces a trabajos de investigación relevantes).
Pero Solr solo puede hacer esto porque no tiene todas las restricciones que tiene un RDBMS. Por ejemplo, Solr es muy malo para actualizar un solo documento a la vez (prefiere las actualizaciones por lotes).
