Dovrei generare l'id dei documenti in un CouchDB o dovrei dipendere da CouchDB per generarlo? Quali sono i vantaggi o gli svantaggi di questi approcci? Ci sono implicazioni di prestazioni su una di queste opzioni?Qual è il migliore: id generato automaticamente o assegnazione id manuale nei documenti couchdb?
Per quanto riguarda CouchDB non c'è differenza. Federico ha ragione che gli ID sequenziali sono leggermente più veloci. Se si esegue una query su /_uuids?count=10, si noterà che gli UUID sono sequenziali (per impostazione predefinita).
Tuttavia, anche con ID casuali, una volta eseguito il compaction, saranno tutti nell'ordine "giusto" internamente nel file .couch ea quel punto non c'è differenza. Quindi, a lungo termine, di solito non mi preoccupo.
La cosa principale è che è necessario utilizzare per lo più ID sequenziali. Come this article e questo bit dello couchdb book spiegano, l'uso di ID casuali si traduce in una struttura molto meno efficiente internamente, sia in termini di velocità sia in termini di spazio utilizzato sul disco.
[wiki ufficiale] (http://wiki.apache.org/couchdb/HttpGetUuids) è l'acronimo di "sequenza" dell'algoritmo se si utilizzano gli ID CouchDB generati. Nel nostro progetto abbiamo deciso di generare ID in modo indipendente come questo: ** sha1 (uuid()) ** per ridurre le richieste GET a CouchDB –
Signore, per quanto riguarda il problema emerso dagli ID sequenziali? Non è possibile utilizzare ID sequenziali negli URL delle applicazioni a causa della prevedibilità di altri ID utilizzando un ID e utilizzando ID lunghi poiché l'autenticazione non è possibile, –
Gli ID auto generati sono quasi impossibili da gestire se si dispone di due o più istanze separate della propria app. Perché la sincronizzazione tra le diverse istanze non è istantanea. Una soluzione per questo può essere quella di avere un server dedicato a generare (o verificare la disponibilità di) gli id, ad esempio utilizzando un database SQL, e agire come un gate per la creazione di documenti.
D'altra parte, se si dispone di un solo server e non sarà mai necessario altro, c'è un vantaggio che trovo interessante per gli auto-generati: poiché devono essere unici, è possibile utilizzarli in url. Ad esempio, prendi lo slug del titolo di un post sul blog come _id.
Per quanto riguarda le prestazioni, gli ID generati da CouchDB sono piuttosto lunghi, quindi se i tuoi ID sono più brevi, risparmierai spazio su disco significativo (ammesso che tu abbia un sacco di documenti).
Si intende l'utilizzo di BigCouch (più istanze)? –
@DmitrySorin Intendevo attraverso la replica bidirezionale. Non so molto di BigCouch ma da quello che ho appena letto, potrebbe risolvere il problema ... – Simon
Entrambe le risposte sopra indicano PROS di ID sequenziali. Ecco un problema importante emerso dagli ID sequenziali.
Predicibilità di altri ID nei documenti utilizzando un ID singolo.
A causa di questo, non possiamo usare gli ID sequenziali negli URL applicativi come identificatori a causa di altri ID essere prevedibile utilizzando uno ID, e utilizzando come l'autenticazione URL non è possibile. (Come fatto da servizi di condivisione di file).
Per sequenziale intendi 'aumentare in ordine', giusto? Non incrementato di 1 o di un altro numero costante? –
Giusto. Gli ID sono stringhe, quindi per ottenere un incremento delle prestazioni, si desidera che ogni "maggiore" rispetto all'altro, utilizzando un confronto di stringhe. Tuttavia, come ho detto, quando si esegue la compattazione, CouchDB crea un albero bilanciato indipendentemente dagli ID, in modo che l'aumento delle prestazioni sia solo temporaneo. – JasonSmith