Ripubblica da qui come penso possa essere più adatto a questo scambio.
Sto cercando di implementare DRUM (Disk Repository con Update Management) come per IRLBot paper (le pagine pertinenti iniziano da 4), ma come sintesi rapida è essenzialmente solo un modo efficiente di coppie di aggiornamento (chiave, valore) su un repository persistente. Nel documento collegato viene utilizzato come backbone dietro il test URLSeen del crawler, il controllo RobotsTxt e la cache DNS.
È stato utile implementare in c ++ fatto qui , che espone l'architettura in un modo molto più digeribile. Per facilità di riferimento, questo è il diagramma dell'architettura dall'implementazione c ++:
La parte che sto cercando di capire è il ragionamento alla base della separazione dei secchi (chiave, valore) e dei secchi ausiliari. L'articolo con l'implementazione c ++ afferma quanto segue:
During merge a key/value bucket is read into a separate buffer and sorted. Its content is synchronized with that of the persistent repository. Checks and updates happen at this moment. Afterwards, the buffer is re-sorted to its original order so that key/value pairs match again the corresponding auxiliary bucket. A dispatching mechanism then forwards the key, value and auxiliary for further processing along with the operation result. This process repeats for all buckets sequentially.
Quindi, se l'ordine dei bucket (chiave, valore) deve essere ripristinato a quello dei bucket ausiliari al fine di ricollegare le coppie (chiave, valore) con le informazioni ausiliarie, perché non tenere semplicemente il ( chiave, valore, aux) valori insieme in singoli bucket? Qual è il ragionamento che sta dietro tenerli separati e non sarebbe più efficiente tenerli insieme (dato che non è più necessario ripristinare l'ordine originale non ordinato del bucket)?