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