¿Por qué las bases de datos no crean sus propios índices automáticamente?
32
Pensé que las bases de datos sabrían lo suficiente sobre lo que encuentran a menudo y podrían responder a las demandas a las que se enfrentan para que puedan decidir agregar índices a los datos altamente solicitados.
¿Su automóvil repara automáticamente su propio neumático desinflado?
Kermit
11
Una analogía más precisa es si su ECU altera la potencia suministrada a la bomba de combustible para fijar las tasas de flujo de combustible / aceite y compensar las líneas sucias. a lo que la respuesta es sí ..
Jharwood
11
Una base de datos ya puede poner un índice en una tabla que actualmente solo requiere que le ordenemos, un automóvil físicamente no puede reemplazar una llanta, hasta que construyamos algunos brazos para usar.
Jharwood
1
Lo hacen, para columnas que tienen UNIQUErestricciones.
dan04
8
Si buscas en Google "bases de datos de autoajuste", encontrarás mucha investigación sobre esto. Quizás en el futuro sea común tener algún elemento de esto.
Martin Smith
Respuestas:
25
Actualizar
Esto ahora se implementa en SQL Server Azure. Genera recomendaciones
Puede configurar el Asesor de bases de datos SQL para implementar recomendaciones automáticamente. A medida que las recomendaciones estén disponibles, se aplicarán automáticamente. Al igual que con todas las operaciones de índice gestionadas por el servicio, si el impacto en el rendimiento es negativo, la recomendación se revertirá.
Respuesta original
Algunas bases de datos ya (tipo de) crean índices automáticamente.
En SQL Server, el plan de ejecución a veces puede incluir un operador Index Spool donde el RDBMS crea dinámicamente una copia indexada de los datos. Sin embargo, este spool no es una parte persistente de la base de datos que se mantiene sincronizada con los datos de origen y no se puede compartir entre las ejecuciones de consultas, lo que significa que la ejecución de dichos planes puede terminar creando y soltando índices temporales en los mismos datos repetidamente.
Quizás en el futuro los RDBMS tengan la capacidad de eliminar dinámicamente y crear índices persistentes de acuerdo con la carga de trabajo.
El proceso de optimización del índice es al final solo un análisis de costo beneficio. Si bien es cierto que los humanos pueden tener más información sobre la importancia relativa de las consultas en una carga de trabajo, en principio no hay ninguna razón por la que esta información no pueda ponerse a disposición del optimizador. SQL Server ya tiene un regulador de recursos que permite clasificar las sesiones en diferentes grupos de carga de trabajo con diferentes asignaciones de recursos según la prioridad.
Los índices DMV faltantes mencionados por Kenneth no están destinados a implementarse a ciegas, ya que solo consideran los beneficios de una consulta específica y no intentan tener en cuenta el costo del índice potencial para otras consultas. Tampoco consolida índices faltantes similares. por ejemplo, la salida de este DMV puede informar índices faltantes A,B,CyA,B INCLUDE(C)
Algunos problemas actuales con la idea son
La calidad de cualquier análisis automatizado que en realidad no cree el índice dependerá en gran medida de la precisión del modelo de cálculo de costos.
Incluso dentro del campo del análisis automatizado, una solución fuera de línea podrá ser más exhaustiva que una solución en línea, ya que es imperativo que una solución en línea no agregue gastos generales de contabilidad al servidor en vivo e interfiera con su propósito principal de ejecutar consultas.
Los índices creados automáticamente en respuesta a la carga de trabajo necesariamente se crearán en respuesta a consultas que los hubieran encontrado útiles, por lo que se quedarán atrás de las soluciones que crean los índices de antemano.
Probablemente sea razonable esperar que la precisión de los modelos de costos mejore con el tiempo, pero el punto 2 parece más difícil de resolver y el punto 3 es inherentemente insoluble.
Sin embargo, probablemente la gran mayoría de las instalaciones no se encuentran en esta situación idealizada con personal calificado que supervisa, diagnostica y anticipa continuamente (o al menos reacciona) a los cambios en las cargas de trabajo.
El objetivo de este proyecto es hacer que las bases de datos se autoajusten y se administren automáticamente explotando el conocimiento de la carga de trabajo
La página de inicio del proyecto enumera varios proyectos interesantes. Uno es particularmente relevante para la pregunta aquí
Otro problema interesante surge cuando no hay DBA disponible (por ejemplo, una base de datos integrada o una pequeña empresa). En tales escenarios, un enfoque de sintonización de índice continuo de bajo toque puede llegar a ser importante. Hemos explorado soluciones ... [en] " Un enfoque en línea para el ajuste del diseño físico " en ICDE 2007.
Los autores declaran
Con características DBMS cada vez más comunes, como los índices en línea, resulta atractivo explorar soluciones más automáticas para el problema del diseño físico que avanzan en el estado del arte.
El artículo presenta un algoritmo.
Sus características principales son:
A medida que se optimizan las consultas, identificamos un conjunto relevante de índices candidatos que mejorarían el rendimiento. Esta característica permite que el procesamiento de consultas continúe en paralelo con los índices que se crean en segundo plano.
En el momento de la ejecución, hacemos un seguimiento de los posibles beneficios que perdemos al no tener dichos índices candidatos y también la utilidad de los índices existentes en presencia de consultas, actualizaciones y limitaciones de espacio.
Después de reunir suficiente "evidencia" de que un cambio de diseño físico es beneficioso, activamos automáticamente creaciones o eliminaciones de índice.
La naturaleza en línea de nuestro problema implica que generalmente nos quedaremos atrás de las soluciones óptimas que conocen el futuro. Sin embargo, al medir cuidadosamente la evidencia, nos aseguramos de no sufrir decisiones "tardías" de manera significativa, limitando así el monto de la pérdida incurrida
La implementación del algoritmo permite la aceleración en respuesta a los cambios en la carga del servidor y también puede abortar la creación del índice si durante la creación la carga de trabajo cambia y el beneficio esperado cae por debajo del punto que se considera que vale la pena.
La conclusión de los autores sobre el tema de la afinación física en línea versus tradicional.
Los algoritmos en línea en este trabajo son útiles cuando los DBA no están seguros sobre el comportamiento futuro de la carga de trabajo, o no tienen la posibilidad de realizar un análisis o modelado exhaustivo. Si un DBA tiene información completa sobre las características de la carga de trabajo, un análisis estático y la implementación por parte de las herramientas existentes (por ejemplo, [2, 3]) sería una mejor alternativa.
Nuestro enfoque no puede vencer al asesor de índices si se conoce de antemano toda la carga de trabajo. Sin embargo, en entornos dinámicos con cargas de trabajo cambiantes y en evolución, el enfoque basado en consultas produce mejores resultados.
Es increíblemente peligroso para la carrera de un DBA asumir que su habilidad nunca puede ser automatizada. Eso está matando las carreras de los chicos de la red en este momento, ya que el cambio es hacia centros de datos definidos por software. Como buenos DBA, deberíamos liderar el esfuerzo de automatización.
Cayo
20
El diseño del índice que se implementa es algo más un arte que una ciencia. El RDBMS no es lo suficientemente inteligente como para tomar cargas de trabajo comunes y diseñar una estrategia de indexación inteligente. Depende de la intervención humana (leer: DBA) analizar la carga de trabajo y determinar cuál es el mejor enfoque.
Si no hubiera penalización por tener índices, entonces sería un enfoque de escopeta simplemente agregar un número infinito de índices. Pero debido a que la modificación de datos (INSERTOS, ACTUALIZACIONES y BORRADOS) tiene un impacto en los índices habilitados en una tabla, entonces habrá una sobrecarga variable de estos índices.
Se necesita un diseño y una estrategia humanos para crear índices de forma inteligente que maximicen el rendimiento de lectura, al tiempo que tienen la menor cantidad de sobrecarga de modificación de datos.
El problema es sorprendentemente difícil de corregir, por lo que no es de extrañar que la mayoría de las bases de datos no las creen automáticamente (BigTable / SimpleDB se salgan con la suya porque no permiten uniones arbitrarias, lo que hace las cosas significativamente más fáciles) . Además, la creación de índices sobre la marcha es un proceso lento que requiere acceso exclusivo a toda la tabla, definitivamente no es algo que desee que suceda mientras la tabla está en línea.
Sin embargo, dado el número de aplicaciones web de LAMP por ahí que fueron escritos por aficionados que ni siquiera saben lo que un índice es , sigo pensando que esta característica sería beneficioso para algunas personas.
Diría que comparar BigTable (y sus derivados, como Cassandra, HBase, etc.) con las soluciones RDBMS es comparar manzanas con naranjas: BigTable y sus derivados son más como gigantescas tiendas de valores de clave o columnas, y la clave de fila es inherentemente un índice .
Suman
1
Exactamente. La pregunta está etiquetada rdbmsy no creo que BigTable caiga en la categoría.
ypercubeᵀᴹ
2
@ypercube: ... Sí, lo mencioné en mi respuesta; pero aún vale la pena conocerlo, como mínimo como punto de interés. También mencioné otras bases de datos que son RDBMS que hacen esto, y expliqué por qué no es común. Esto definitivamente no merece un
voto negativo
1
No voté en contra. Estoy de acuerdo en que es un problema muy difícil.
ypercubeᵀᴹ
10
Si bien ya hay algunas respuestas extensas, parecen esquivar la respuesta real: los índices no siempre son deseables.
Con la analogía del automóvil mencionada en los comentarios, sería mejor decir por qué no todos los automóviles están equipados con paquetes de deportes extremos. En parte es un gasto, pero también se debe al hecho de que mucha gente no necesita o quiere neumáticos de bajo perfil y suspensión dura como una roca; Es innecesariamente incómodo.
Entonces, quizás tenga 1,000 lecturas por cada inserción, ¿por qué no tener un índice creado automáticamente? Si la tabla es amplia y las consultas son variadas, ¿por qué no tener varias? Tal vez el commit es crítico en el tiempo y las lecturas no lo son; En estas circunstancias, puede ser inaceptable reducir la velocidad de su inserción. Tal vez esté trabajando con un espacio en disco limitado y no pueda permitirse tener índices adicionales comiendo el espacio que tiene.
El punto es que los índices no se crean automáticamente porque no son la respuesta a todo. El diseño de índices no es simplemente un caso de decir "oye, esto acelerará mis lecturas", hay otros factores a considerar.
+1 si bien es posible y factible automatizar estas cosas, no siempre vamos a mejorar con un montón de índices mágicos implementados por un sistema que no tiene una idea de cómo se usarán los datos mañana, no importa su escritura frente al umbral de compensación de lectura. Me escribió en su blog un poco sobre esto el otro día , pero es evidente que hay mucho más de qué hablar.
Aaron Bertrand
> Tal vez el commit es crítico en el tiempo y las lecturas no lo son; En estas circunstancias, puede ser inaceptable reducir la velocidad de su inserción. Tan buena respuesta, muy útil.
Siddhartha
6
Pueden analizar consultas pasadas y sugerir / crear índices, sin embargo, esto no funciona de manera óptima porque los índices logran un equilibrio para acelerar lo que desea optimizado a un costo y el servidor no puede conocer sus intenciones.
No son inteligentes, son una pieza de código. Cada vez que ingresa datos nuevos en una base de datos, debe encontrar una nueva ubicación y un mapa para encontrarlos cuando se solicite. La indexación suena más fácil de lo que es, ¿solo le das un nuevo número a una nueva porción de datos? Bueno, ¿qué tal si la próxima consulta no es sobre el último fragmento de datos sino sobre 36271 fragmentos anteriores? Puede encontrarlo fácilmente con su índice, ¿verdad? Pero, ¿qué pasa si la consulta incluye una palabra como "pesca" que se encuentra en el antiguo trozo 36271 hecho en 1997? ¿Ho? Ni una palabra sobre pesca en el viejo artículo.
Si los datos llegaran a la base de datos uno por uno, podrían indexarse así. Pero la indexación simple tendrá resultados incorrectos y / o un rendimiento lento tarde o temprano ...
UNIQUErestricciones.Respuestas:
Actualizar
Esto ahora se implementa en SQL Server Azure. Genera recomendaciones
y la gestión de índices se puede configurar para que sea automática .
Respuesta original
Algunas bases de datos ya (tipo de) crean índices automáticamente.
En SQL Server, el plan de ejecución a veces puede incluir un operador Index Spool donde el RDBMS crea dinámicamente una copia indexada de los datos. Sin embargo, este spool no es una parte persistente de la base de datos que se mantiene sincronizada con los datos de origen y no se puede compartir entre las ejecuciones de consultas, lo que significa que la ejecución de dichos planes puede terminar creando y soltando índices temporales en los mismos datos repetidamente.
Quizás en el futuro los RDBMS tengan la capacidad de eliminar dinámicamente y crear índices persistentes de acuerdo con la carga de trabajo.
El proceso de optimización del índice es al final solo un análisis de costo beneficio. Si bien es cierto que los humanos pueden tener más información sobre la importancia relativa de las consultas en una carga de trabajo, en principio no hay ninguna razón por la que esta información no pueda ponerse a disposición del optimizador. SQL Server ya tiene un regulador de recursos que permite clasificar las sesiones en diferentes grupos de carga de trabajo con diferentes asignaciones de recursos según la prioridad.
Los índices DMV faltantes mencionados por Kenneth no están destinados a implementarse a ciegas, ya que solo consideran los beneficios de una consulta específica y no intentan tener en cuenta el costo del índice potencial para otras consultas. Tampoco consolida índices faltantes similares. por ejemplo, la salida de este DMV puede informar índices faltantes
A,B,CyA,B INCLUDE(C)Algunos problemas actuales con la idea son
Probablemente sea razonable esperar que la precisión de los modelos de costos mejore con el tiempo, pero el punto 2 parece más difícil de resolver y el punto 3 es inherentemente insoluble.
Sin embargo, probablemente la gran mayoría de las instalaciones no se encuentran en esta situación idealizada con personal calificado que supervisa, diagnostica y anticipa continuamente (o al menos reacciona) a los cambios en las cargas de trabajo.
El proyecto AutoAdmin en Microsoft Research se ejecuta desde 1996
La página de inicio del proyecto enumera varios proyectos interesantes. Uno es particularmente relevante para la pregunta aquí
Los autores declaran
El artículo presenta un algoritmo.
La implementación del algoritmo permite la aceleración en respuesta a los cambios en la carga del servidor y también puede abortar la creación del índice si durante la creación la carga de trabajo cambia y el beneficio esperado cae por debajo del punto que se considera que vale la pena.
La conclusión de los autores sobre el tema de la afinación física en línea versus tradicional.
Las conclusiones aquí son similares a las de otro documento Autonomous Query-driven Index Tuning
fuente
El diseño del índice que se implementa es algo más un arte que una ciencia. El RDBMS no es lo suficientemente inteligente como para tomar cargas de trabajo comunes y diseñar una estrategia de indexación inteligente. Depende de la intervención humana (leer: DBA) analizar la carga de trabajo y determinar cuál es el mejor enfoque.
Si no hubiera penalización por tener índices, entonces sería un enfoque de escopeta simplemente agregar un número infinito de índices. Pero debido a que la modificación de datos (INSERTOS, ACTUALIZACIONES y BORRADOS) tiene un impacto en los índices habilitados en una tabla, entonces habrá una sobrecarga variable de estos índices.
Se necesita un diseño y una estrategia humanos para crear índices de forma inteligente que maximicen el rendimiento de lectura, al tiempo que tienen la menor cantidad de sobrecarga de modificación de datos.
fuente
De hecho, hay algunas bases de datos que hacen esto. Por ejemplo, BigTable de Google y SimpleDB de Amazon crean automáticamente índices (aunque tampoco lo son los RDBMS) . También hay al menos un motor MySQL RDBMS que hace esto. SQL Server también realiza un seguimiento de los índices que cree que debe crear , aunque no va tan lejos como para crearlos.
El problema es sorprendentemente difícil de corregir, por lo que no es de extrañar que la mayoría de las bases de datos no las creen automáticamente (BigTable / SimpleDB se salgan con la suya porque no permiten uniones arbitrarias, lo que hace las cosas significativamente más fáciles) . Además, la creación de índices sobre la marcha es un proceso lento que requiere acceso exclusivo a toda la tabla, definitivamente no es algo que desee que suceda mientras la tabla está en línea.
Sin embargo, dado el número de aplicaciones web de LAMP por ahí que fueron escritos por aficionados que ni siquiera saben lo que un índice es , sigo pensando que esta característica sería beneficioso para algunas personas.
fuente
rdbmsy no creo que BigTable caiga en la categoría.Si bien ya hay algunas respuestas extensas, parecen esquivar la respuesta real: los índices no siempre son deseables.
Con la analogía del automóvil mencionada en los comentarios, sería mejor decir por qué no todos los automóviles están equipados con paquetes de deportes extremos. En parte es un gasto, pero también se debe al hecho de que mucha gente no necesita o quiere neumáticos de bajo perfil y suspensión dura como una roca; Es innecesariamente incómodo.
Entonces, quizás tenga 1,000 lecturas por cada inserción, ¿por qué no tener un índice creado automáticamente? Si la tabla es amplia y las consultas son variadas, ¿por qué no tener varias? Tal vez el commit es crítico en el tiempo y las lecturas no lo son; En estas circunstancias, puede ser inaceptable reducir la velocidad de su inserción. Tal vez esté trabajando con un espacio en disco limitado y no pueda permitirse tener índices adicionales comiendo el espacio que tiene.
El punto es que los índices no se crean automáticamente porque no son la respuesta a todo. El diseño de índices no es simplemente un caso de decir "oye, esto acelerará mis lecturas", hay otros factores a considerar.
fuente
Pueden analizar consultas pasadas y sugerir / crear índices, sin embargo, esto no funciona de manera óptima porque los índices logran un equilibrio para acelerar lo que desea optimizado a un costo y el servidor no puede conocer sus intenciones.
fuente
No son inteligentes, son una pieza de código. Cada vez que ingresa datos nuevos en una base de datos, debe encontrar una nueva ubicación y un mapa para encontrarlos cuando se solicite. La indexación suena más fácil de lo que es, ¿solo le das un nuevo número a una nueva porción de datos? Bueno, ¿qué tal si la próxima consulta no es sobre el último fragmento de datos sino sobre 36271 fragmentos anteriores? Puede encontrarlo fácilmente con su índice, ¿verdad? Pero, ¿qué pasa si la consulta incluye una palabra como "pesca" que se encuentra en el antiguo trozo 36271 hecho en 1997? ¿Ho? Ni una palabra sobre pesca en el viejo artículo.
Si los datos llegaran a la base de datos uno por uno, podrían indexarse así. Pero la indexación simple tendrá resultados incorrectos y / o un rendimiento lento tarde o temprano ...
fuente