Perché i database non creano automaticamente i propri indici?

Avrei pensato che i database avrebbero saputo abbastanza di ciò che incontrano spesso e sarebbero in grado di rispondere alle richieste in base alle quali potrebbero decidere di aggiungere indici ai dati altamente richiesti.

Aggiornare

Questo è ora implementato in SQL Server Azure. Genera raccomandazioni

e la gestione dell'indice può essere configurata per essere automatica .

Abilita la gestione automatica dell'indice

È possibile impostare SQL Database Advisor per implementare automaticamente le raccomandazioni. Man mano che i consigli diventano disponibili, verranno automaticamente applicati. Come per tutte le operazioni sugli indici gestite dal servizio se l'impatto sulla performance è negativo, la raccomandazione verrà ripristinata.

Risposta originale

Alcuni database già creano (tipo di) indici automaticamente.

In SQL Server il piano di esecuzione a volte può includere un operatore Index Spool in cui RDBMS crea dinamicamente una copia indicizzata dei dati. Tuttavia, questo spool non è una parte persistente del database mantenuta in sincronia con i dati di origine e non può essere condivisa tra le esecuzioni delle query, il che significa che l'esecuzione di tali piani potrebbe finire per creare e rilasciare ripetutamente indici temporanei sugli stessi dati.

Forse in futuro i RDBMS avranno la capacità di rilasciare in modo dinamico e creare indici persistenti in base al carico di lavoro.

Il processo di ottimizzazione dell'indice è alla fine solo un'analisi costi-benefici. Mentre è vero che gli esseri umani possono avere maggiori informazioni sull'importanza relativa delle query in un carico di lavoro in linea di principio, non vi è alcun motivo per cui queste informazioni non possano essere rese disponibili all'ottimizzatore. SQL Server dispone già di un regolatore delle risorse che consente di classificare le sessioni in diversi gruppi di carichi di lavoro con allocazioni di risorse diverse in base alla priorità.

I DMV dell'indice mancante menzionati da Kenneth non intendono essere implementati alla cieca in quanto considerano solo i vantaggi di una query specifica e non fanno alcun tentativo di tener conto del costo dell'indice potenziale per altre query. Né consolida indici simili simili. ad es. l'output di questo DMV può riportare indici mancanti su A,B,CeA,B INCLUDE(C)

Alcuni problemi attuali con l'idea sono

• La qualità di qualsiasi analisi automatizzata che non crea effettivamente l'indice dipenderà fortemente dall'accuratezza del modello di determinazione dei costi.
• Anche nel campo dell'analisi automatizzata una soluzione offline sarà in grado di essere più approfondita di una soluzione online in quanto è indispensabile che una soluzione online non aggiunga libri di grandi dimensioni mantenendo sovraccarico al server live e interferisca con il suo scopo principale di eseguire query.
• Gli indici creati automaticamente in risposta al carico di lavoro saranno necessariamente creati in risposta a query che li avrebbero trovati utili, quindi resteranno indietro rispetto alle soluzioni che creano gli indici in anticipo.

È probabilmente ragionevole aspettarsi che l'accuratezza dei modelli di determinazione dei costi migliori nel tempo, ma il punto 2 sembra più complicato da risolvere e il punto 3 è intrinsecamente insolubile.

Tuttavia, probabilmente la stragrande maggioranza delle installazioni non si trova in questa situazione idealizzata con personale qualificato che monitora, diagnostica e anticipa continuamente (o almeno reagisce a) i cambiamenti nei carichi di lavoro.

Il progetto AutoAdmin di Microsoft Research è in esecuzione dal 1996

L'obiettivo di questo progetto è rendere i database auto-ottimizzati e auto-amministrati sfruttando la conoscenza del carico di lavoro

La home page del progetto elenca diversi progetti interessanti. Uno è particolarmente rilevante per la domanda qui

Un altro problema interessante sorge quando non è disponibile alcun DBA (ad esempio un database incorporato o una piccola impresa). In tali scenari, può essere importante un approccio di ottimizzazione dell'indice continuo a basso tocco. Abbiamo esplorato soluzioni ... [in] " Un approccio online alla messa a punto del disegno fisico " in ICDE 2007.

Gli autori affermano

Con funzionalità DBMS sempre più comuni come gli indici online, è interessante esplorare soluzioni più automatiche al problema di progettazione fisica che fa avanzare lo stato dell'arte.

L'articolo introduce un algoritmo

Le sue caratteristiche principali sono:

• Poiché le query sono ottimizzate, identifichiamo un insieme pertinente di indici candidati che migliorerebbero le prestazioni. Questa funzione consente di continuare l'elaborazione delle query in parallelo con gli indici creati in background.
• Al momento dell'esecuzione, seguiamo i potenziali benefici che perdiamo non avendo tali indici candidati e anche l'utilità di indici esistenti in presenza di query, aggiornamenti e vincoli di spazio.
• Dopo aver raccolto abbastanza "prove" che un cambiamento fisico del progetto sia vantaggioso, innesciamo automaticamente creazioni o eliminazioni di indici.
• La natura online del nostro problema implica che generalmente rimarremo indietro rispetto alle soluzioni ottimali che conoscono il futuro. Tuttavia, misurando attentamente le prove, ci assicuriamo di non soffrire in modo significativo di decisioni "tardive", limitando così l'ammontare delle perdite subite

L'implementazione dell'algoritmo consente la limitazione in risposta alle variazioni del carico del server e può anche interrompere la creazione dell'indice se durante la creazione le modifiche del carico di lavoro e il beneficio atteso scendono al di sotto del punto che si ritiene utile.

La conclusione degli autori sul tema dell'ottimizzazione fisica online contro quella tradizionale.

Gli algoritmi online in questo lavoro sono utili quando i DBA non sono sicuri del comportamento futuro del carico di lavoro o non hanno alcuna possibilità di fare un'analisi o una modellizzazione complete. Se un DBA dispone di informazioni complete sulle caratteristiche del carico di lavoro, un'analisi statica e una distribuzione mediante strumenti esistenti (ad esempio, [2, 3]) sarebbe un'alternativa migliore.

Le conclusioni qui sono simili a quelle di un altro articolo Sintonizzazione dell'indice basata su query autonome

Il nostro approccio non può battere il consulente indice se l'intero carico di lavoro è noto in anticipo. Tuttavia, in ambienti dinamici con carichi di lavoro in evoluzione e in evoluzione, l'approccio basato su query produce risultati migliori.

Il design dell'indice che hai messo in atto è qualcosa di più un'arte che una scienza. RDBMS non è abbastanza intelligente da gestire carichi di lavoro comuni e progettare una strategia di indicizzazione intelligente. Spetta all'intervento umano (leggi: DBA) analizzare il carico di lavoro e determinare qual è l'approccio migliore.

Se non ci fosse penalità per avere indici, sarebbe un approccio con fucile da caccia aggiungere semplicemente un numero infinito di indici. Ma poiché la modifica dei dati (INSERTI, AGGIORNAMENTI e CANCELLA) ha un impatto sugli indici abilitati su una tabella, allora ci sarà quel sovraccarico variabile di questi indici.

Ci vuole progettazione e strategia umana per creare in modo intelligente indici che massimizzino le prestazioni di lettura, pur avendo il minor numero di costi di modifica dei dati.

In effetti, ci sono alcuni database che lo fanno. Ad esempio, BigTable di Google e SimpleDB di Amazon creano automaticamente indici (sebbene nessuno dei due sia RDBMS) . C'è anche almeno un motore RDBMS MySQL che lo fa. SQL Server tiene inoltre traccia degli indici che pensa di dover creare , anche se non si spinge fino al punto di crearli.

Il problema è sorprendentemente difficile da correggere, quindi non sorprende che la maggior parte dei database non li crei automaticamente (BigTable / SimpleDB se la cava perché non consente un join arbitrario, il che rende le cose significativamente più facili) . Inoltre, la creazione di indici al volo è un processo che richiede tempo e richiede l'accesso esclusivo a tutto il tavolo - sicuramente non è qualcosa che vuoi che accada mentre il tavolo è online.

Tuttavia, dato il numero di applicazioni web LAMP là fuori che sono stati scritti da dilettanti che non sanno nemmeno che cosa un indice è , penso ancora che questa funzione sarebbe utile per alcune persone.

Sebbene esistano già alcune risposte estese, sembrano aggirare la vera risposta: gli indici non sono sempre desiderabili.

Con l'analogia delle auto menzionata nei commenti, sarebbe meglio dire perché non tutte le auto sono dotate di pacchetti sportivi estremi? In parte è una spesa, ma dipende anche dal fatto che molte persone non hanno bisogno o vogliono pneumatici a basso profilo e sospensioni hard rock; è inutilmente scomodo.

Quindi forse hai 1.000 letture per ogni inserto, perché non avere un indice creato automaticamente? Se la tabella è ampia e le query sono varie, perché non averne diverse? Forse il commit è critico in termini di tempo e le letture no; in tali circostanze potrebbe essere inaccettabile rallentare l'inserto. Forse stai lavorando con uno spazio su disco limitato e non puoi permetterti di avere indici aggiuntivi che consumano lo spazio che hai.

Il punto è che gli indici non vengono creati automaticamente perché non sono la risposta a tutto. Progettare gli indici non è semplicemente un caso di dire "ehi questo accelererà le mie letture", ci sono altri fattori da considerare.

Possono analizzare le query passate e suggerire / creare indici, ma ciò non funziona in modo ottimale perché gli indici raggiungono un equilibrio per accelerare ciò che si desidera ottimizzare a un costo e il server non può conoscere le proprie intenzioni.

Non sono intelligenti, sono un pezzo di codice. Ogni volta che si immettono nuovi dati in un database, è necessario trovare un nuovo percorso e una mappa per trovarli quando viene richiesto. L'indicizzazione suona più facile di quanto non sia, basta dare un nuovo numero a un nuovo blocco di dati? Bene, che ne dici se la prossima query non riguarda l'ultimo blocco di dati ma circa 36271 blocchi precedenti? Puoi trovarlo facilmente con il tuo indice, giusto? Ma cosa succede se la query include una parola come "pesca" che si trova nel vecchio pezzo 36271 realizzato nel 1997? Ho? Non una parola sulla pesca nel vecchio articolo.

Se i dati arrivano al database uno per uno, potrebbero essere indicizzati in questo modo. Ma l'indicizzazione semplice ti darà risultati sbagliati e / o prestazioni lente prima o poi ...