2012-06-26 23 views
9

¿Existe una fórmula/estimación/sensación que nos muestre cuál es el número óptimo de índices en una base de datos RavenDB según el número de tipos de documentos, el número de campos por documento y el número de relaciones entre ellos?Demasiados índices en RavenDB

Notas adicionales:

Según entiendo (primera) consultamos índices en RavenDB, no documentos y (2º) Los índices son como vistas materializadas, por lo que puede costar mucho. Necesito saber cuántos índices dañarían el rendimiento de RavenDB al actualizarlos y hacer que la latencia sea demasiado grande para ignorarla.

Como Raven/MaxNumberOfParallelIndexTasks se establece en el número de procesadores en la máquina actual, ¿significa que el proceso de indexación para otros índices se bloquearía hasta que finalicen las tareas de indexación actuales? ¿O son actualizaciones parciales que se ejecutarán una y otra vez?

+0

esta es una pregunta interesante. no estoy seguro de que veamos una respuesta concreta a menos que el creador entre, pero vale la pena un +1 –

+1

@marc_s Gracias por la edición. –

+0

@nathan gonzalez ¡Estoy deseando que llegue! –

Respuesta

3

Kaveh, En general, preferimos una menor cantidad de índices, porque los índices tienen un costo no trivial asociado. Dicho esto, no cuestan much, especialmente porque se están construyendo en segundo plano.

Tenemos muchos clientes que funcionan con varias docenas de índices, y tenemos algunos que funcionan con unos pocos cientos.

El MaxNumberOfParallelIndexTasks controla cuántos índices actualizamos en paralelo, pero cómo y por qué funciona es un bit complejo para explicar. Desde su punto de vista, realmente no se aplica, porque junto con MaxNumberOfParallelIndexTasks, también tenemos en cuenta cosas como la carga actual del sistema, los costos, etc. En un gran número de índices, algunos índices esperarían mientras que otros están construyendo Sí, pero eso está sujeto a un conjunto de límites, y es probable que no pueda ver esto como un problema en situaciones del mundo real.