Prestazioni di ID lunghi

Question

Mi sono chiesto per un po 'di tempo. In CouchDB abbiamo alcuni ID piuttosto log ... ad esempio:

"000ab56cb24aef9b817ac98d55695c6a"

Ora, se stiamo cercando per questo articolo e passare attraverso la struttura ad albero creato dalla vista. Sembra un intero semplice come un ID sarebbe molto più veloce. Se usassimo interi a 64 bit sarebbe un semplice CMP seguito da un JMP (supponendo che il codice di Erlang stia usando JIT, ma ottieni il mio punto).

Per le stringhe, presumo che generiamo un hash dall'ID o qualcosa del genere, ma a un certo punto dobbiamo fare un confronto di caratteri su tutti i 33 caratteri ... non influirà sulle prestazioni?

Answer 1

La risposta breve è, sì, ovviamente influirà sulle prestazioni, poiché la lunghezza della chiave avrà un impatto diretto sul tempo necessario per percorrere l'albero.

Influisce anche sull'archiviazione, poiché i tasti più lunghi richiedono più spazio, lo spazio richiede tempo.

Tuttavia, la sfumatura che ti manca è che mentre Couch CAN (e lo fa) ha assegnato nuovi ID per te, non è necessario. Sarà più che felice accettare i tuoi ID anziché generarli. Quindi, se la lunghezza della chiave ti infastidisce, sei libero di usare le chiavi più corte.

Tuttavia, data la natura "json" del divano, è praticamente un database basato su "testo". Non c'è un sacco di dati binari memorizzati in un'istanza di Couch normale (gli allegati non resistono, ma anche quelli che penso siano memorizzati in BASE64, potrei sbagliarmi).

Quindi, sì, un 64 bit sarebbe il più efficiente, il semplice fatto è che Couch è progettato per funzionare per qualsiasi chiave, e "qualsiasi chiave" è più facilmente espressa nel testo.

Infine, a dire il vero, il costo del confronto delle chiavi è sminuito dai tempi di recupero I/O del disco e dal marshalling dei dati JSON (soprattutto sulle scritture). Qualsiasi guadagno reale ottenuto con la conversione in un tale sistema probabilmente non avrebbe alcun impatto sul "mondo reale" sulle prestazioni complessive.

Se si desidera veramente accelerare il sistema di chiavi Couch, codificare la routine chiave per bloccare la chiave in byte a 64 bit, e riprenderli (come hai detto tu). 8 byte di testo sono gli stessi di "long int" a 64 bit. Ciò ti darebbe, in teoria, un aumento delle prestazioni di 8 volte su confronti chiave. Se erlang può creare tale codice, non posso dire.

Answer 2

Dal CouchDB: La guida libro definitivo:

Ho bisogno di tracciare un quadro di questo a un certo punto, ma la ragione è che se si pensa alla btree idealizzata, quando si uso UUID del potresti ricevere un numero di nodi radice in quell'albero, quindi con l'unica natura di aggiunta che hai per scrivere ciascuno di questi nodi e tutto sopra di esso nell'albero. ma se si utilizza l'aumento monotonico degli ID , si sta invalidando lo stesso percorso sul lato destro dell'albero , riducendo al minimo il numero di nodi che è necessario riscrivere. sarebbe essere lo stesso per monotonicamente diminuendo pure. e dovrebbe tecnicamente funzionare se si è in grado di effettuare gli aggiornamenti essere sicuri di colpire uno o due nodi nella parte interna dell'albero, anche se è molto più difficile da dimostrare.

Quindi ID sequenziali offrono un vantaggio in termini di prestazioni, tuttavia, è necessario ricordare che questo non è gestibile quando si dispone di più di un database, poiché gli ID si scontrano.