Velocità di accesso all'indice di tipo MySQL e ricerca di salto binario su un file enorme?

3

Sono pronto a passare a un database MySQL per alcuni enormi set di dati con cui sto lavorando ma in questo momento non ho tempo. Nel frattempo sono curioso di un problema di prestazioni tecniche relativo alla velocità tra i due metodi.

Ovviamente il salto binario su un enorme file ordinato è un brutto colpo alle prestazioni. Le probabilità di trovare i dati che ti servono nella cache dei chip o persino nella memoria sono piuttosto brutte se si presuppone una distribuzione statisticamente normale delle richieste di registrazione attraverso l'enorme file. A meno che l'intero file non sia in memoria, e alcuni di quelli con cui sto lavorando sono 20 GB, questo è impossibile sul sistema Win32 che sto usando, è quasi certo che un gran numero di richieste di registrazione si degraderanno all'operazione di soppressione delle prestazioni di una lettura reale del disco rigido.

Dato che non ho mai fatto alcuna programmazione di indice di database diversa da una semplice indicizzazione di B-tree, mi chiedo quanto siano buoni gli indici creati da database moderni come MySQL per evitare i colpi del disco rigido. Ovviamente un grande vantaggio che hanno è che se le chiavi di indice sono molto più piccole dei record di dati che rappresentano, è possibile bloccare molto più delle pagine indice, se non tutte, in memoria e che evita un sacco di hit su disco. Ma mi stavo chiedendo se il codice dietro questi indici può ottimizzare con successo in altri modi, specialmente quando si tratta di predire l'accesso alle pagine indice, per accelerare ulteriormente le cose assicurandosi che la maggior parte degli accessi alle pagine indice non provochino accessi al disco?

Se qualcuno ha avuto una profonda esperienza con il tipo di codice che sta alla base dell'indicizzazione di MySQL o di entità simili, o ha effettuato alcuni test approfonditi sulle prestazioni, mi piacerebbe saperlo.

- Roschler

    
posta Robert Oschler 25.05.2011 - 02:14
fonte

2 risposte

2

Gli indici tendono ad essere molto più piccoli del tavolo. Se l'intero indice si adatta alla memoria, allora ci sarà una media di 1 ricerca del disco per ricerca casuale. In caso contrario, ci saranno in genere 2 ricerche disco (una volta per l'indice, una volta nella tabella per i dati effettivi). Tieni presente che un disco cerca una media di 1/200 di secondo. Se hai intenzione di fare un milione di ricerche, questo sarà un problema.

In generale, l'approccio corretto se si dispone di un set di dati di tale dimensione è quello di utilizzare l'ordinamento e ricorrere pesantemente. Ciò consentirà il flusso di dati al / dal disco. Qual è un'operazione che le unità disco sono molto buone. Se riesci a capire un algoritmo che evita le ricerche casuali, otterrai in generale miglioramenti all'ordine di grandezza.

Per quanto riguarda MySQL, tieni presente che i database relazionali non sono polvere magica da folletto. Sono uno strato di astrazione in cima a cose come algoritmi e algoritmi di ordinamento. Questo può farti risparmiare molto tempo, ma mai essere più veloce della manipolazione dei dati grezzi se sai cosa stai facendo. Possono accelerare i tempi di sviluppo, ma in linea di principio lo stesso programma contro i dati grezzi andrà a buon fine. Spesso con margini molto grandi.

Con un database intelligente (ad es. PostgreSQL o Oracle) c'è la possibilità che il database sia più veloce di quanto si possa fare perché l'ottimizzatore sa di più su come strutturare l'accesso ai dati e troverà un piano di query che è meglio di quello che avresti inventato. Tuttavia, l'ottimizzatore di MySQL non è altrettanto intelligente, quindi è improbabile che vi salvi lì. (Ti fornisce SQL, costrutti relazionali, transazioni e così via. Non è un buon pianificatore di query per query complesse su molti dati.)

    
risposta data 25.05.2011 - 04:14
fonte
1

Dovresti assolutamente dare un'occhiata alle soluzioni NoSQL là fuori se non vuoi una rappresentazione relazionale dei tuoi dati / query SQL complesse.

Hai già una serie di dati ordinati su file e hai bisogno di accesso casuale, il che significa che si adatta perfettamente a un archivio di valori chiave. E questi negozi di valore chiave sono a loro volta costruiti su indici hash / indici Bree in alcuni casi, ma questo è tutto distratto per te.

Se fossi in te, proverei a utilizzare una di queste soluzioni di set (perché provare a risolvere un problema di accesso casuale sta tentando di reinventare la ruota, a meno che non sia il tuo progetto principale), valutare i benefici perf e poi immergersi in effettivi implementazione se necessario.

Un buon punto di partenza senza problemi di amministrazione / configurazione - Amazon SimpleDB! < / plug >

    
risposta data 25.05.2011 - 05:49
fonte

Leggi altre domande sui tag