Interrogare l'impatto degli UUID

Naviga le tue risposte
0

Quando ho giocato per la prima volta con un database NoSQL, ho preso coscienza dell'impatto degli UUID in un sistema distribuito.

MongoDB è impostato su ObjectIDs, ma ho sempre chiesto in quali casi UUID (RFC4122) sarebbe una scelta migliore.

Ho scoperto che gli ObjectID sono fantastici. Non solo sono più piccoli degli UUID risparmiando spazio su disco, ma sono nel complesso più efficienti:

Una volta Mi è stato detto :

contrary to UUIDs, ObjectIds are monotonic ... Monotonic indexes will cause the B-Tree to be filled more efficiently, it allows paging by id and allows a 'default sort' by id to make your cursors stable, and of course, they carry an easy-to-extract timestamp. These are the optimizations you should be aware of, and they can be huge.

Improvvisamente, ho pensato che, mentre UUID potrebbero essere aa YAGNI caso, Mongo objectIds potrebbe essere ottimizzazione della precisione .

Se per prima cosa assegno agli UUID, qualcuno potrebbe affermare che sto sprecando prestazioni / spazio su disco. Tuttavia, se prima scelgo ObjectID, potrei scoprire in seguito che ho bisogno di un ID meno rischioso per la collisione. Il primo riguarda le prestazioni, il secondo le limitazioni del design.

A causa della mia mancanza di esperienza con gli UUID, non sono sicuro se dovrei preoccuparmi di più delle prestazioni o della libertà.

Quale dovrebbe essere la strategia ID predefinita nei progetti in cui i requisiti non sono ancora chiari?

Aggiorna

Sono preoccupato che una caratteristica del fornitore di database (ID) passi nel mio livello di applicazione. Sono troppo paranoico sacrificando l'efficienza per l'indipendenza / l'astrazione?

    
posta SystematicFrank 04.06.2017 - 12:16
fonte

2 risposte

2

Sulla questione se non utilizzare gli UUID perché "Non hai bisogno di Gona"

Data l'ampia accettazione dello standard UUID e delle numerose librerie standard che possono generarle; L'UUID è in genere il modo più semplice per generare un ID univoco.

A causa di questo UUID dovrebbe essere l'opzione predefinita per qualsiasi ID. Puoi prendere questa decisione in fase di progettazione senza considerare la tecnologia o l'architettura del database.

Qualsiasi altro formato di identificazione deve essere una scelta forzata a causa di prestazioni o costi.

Data la natura distribuita di no-sql e il basso costo dello spazio su disco, generalmente questi sono problemi che difficilmente incontrerai.

    
risposta data 04.06.2017 - 13:37
fonte
0

Quindi un oggetto mongo è un numero semi casuale generato lato client

  • 4 byte secondi da unix epoch
  • ID macchina a 3 byte
  • ID processo a 2 byte
  • contatore a 3 byte

Ma se consideriamo il caso in cui ogni cliente crea un record ogni secondo, (e il contatore è implementato come un contatore piuttosto che casuale) che garantisce una collisione su 7 dei 12 byte.

Lasciandoti solo 5 byte di numeri casuali. 3 per id macchina (16mil) che presumibilmente rimangono gli stessi per ogni cliente

e 2 (65k) che sono presumibilmente "rilanciati" ogni volta che il client si avvia.

Quindi hai una possibilità bassa e prevedibile di collisione con il cliente. Ma se non si possiede il computer client è incontrollabile.

L'ID del processo quasi certamente andrà a scontrarsi a un certo punto a seconda di quanto spesso viene rigenerato.

Quindi, in questo senario sei davvero giù a vedere collisioni intermittenti, e quindi errori, in cui la corrispondenza dell'ID della macchina.

Se stai distribuendo su molte macchine, diciamo che è un'app per telefoni cellulari con una base di clienti a migliaia. Dovresti considerare il rischio che penso.

    
risposta data 04.06.2017 - 13:04
fonte

Leggi altre domande sui tag

Progetta e configura una registrazione centralizzata con microservizi / finestra mobile Software User Personas [chiuso]