Gestione delle chiavi in ​​NoSQL - dummies

Le capacità di lettura veloce dei negozi di valori-chiave derivano dal loro uso di chiavi ben definite. Queste chiavi sono tipicamente hash, il che fornisce all'archivio dei valori-chiave un modo molto prevedibile per determinare su quale partizione (e quindi sul server) risiedono i dati. Un server particolare gestisce una o più partizioni.

Una buona chiave consente di identificare in modo univoco il singolo record che risponde a una query senza dover guardare i valori all'interno di quel record. Una chiave errata richiede che il codice dell'applicazione interpreti il ​​record per determinare se, di fatto, corrisponde alla query.

Se non si progetta bene la chiave, si può finire con un server con un carico sproporzionato rispetto agli altri, che porta a prestazioni scadenti. Ad esempio, l'utilizzo del tempo di sistema corrente come chiave, spinge tutti i nuovi dati sull'ultimo nodo nel cluster, il che porta a uno scenario da incubo di ribilanciamento.

Partizionamento

La progettazione delle partizioni è importante perché alcuni negozi di valori-chiave, come Oracle NoSQL, non consentono il numero di partizioni da modificare una volta creato un cluster. La loro distribuzione tra i server, tuttavia, può essere modificata. Quindi inizia con un numero elevato di partizioni che puoi distribuire in futuro.

Un esempio di partizionamento è l'approccio di hashing coerente di Voldemort, come mostrato. Qui si vedono le stesse partizioni distribuite su tre server inizialmente e successivamente su quattro server in un secondo momento. Il numero di partizioni rimane lo stesso, ma la loro allocazione è diversa tra i server. Lo stesso è vero per le loro repliche.

Accesso ai dati sulle partizioni

Gli archivi a valori-chiave sono altamente distribuiti senza un singolo punto di errore. Ciò significa che non è necessario che un nodo di coordinamento principale tenga traccia dei server all'interno di un cluster. La gestione dei cluster viene eseguita automaticamente da un protocollo di chat tra i nodi nel server.

È possibile utilizzare un trucco nel driver client per spremere le massime prestazioni dal recupero e dall'archiviazione di chiavi e valori - il driver client tiene traccia di quali server detengono quale intervallo di chiavi. Quindi il driver client sa sempre a quale server comunicare.

La maggior parte dei database, incluso NoSQL, passa una richiesta a tutti i membri di un cluster. Quel cluster accetta la scrittura internamente o la passa al nodo corretto. Questa configurazione significa che è possibile un ulteriore viaggio di rete tra i nodi, che può aumentare la latenza.

Al fine di evitare la latenza di individuazione, la maggior parte dei driver client degli archivi di valori-chiave gestisce un elenco di metadati dei nodi correnti in un cluster e gli intervalli di chiavi di partizione gestiti da ciascun nodo.In questo modo, il driver client può contattare il server corretto, il che rende le operazioni più veloci.

Se un nuovo nodo viene aggiunto a un cluster e i metadati non sono aggiornati, il cluster informa il driver client, che quindi scarica gli ultimi metadati del cluster prima di inviare nuovamente la richiesta al nodo corretto. In questo modo il throughput massimo viene mantenuto con un minimo di overhead durante lo sviluppo. Un altro vantaggio collaterale è che non è necessario che un servizio di bilanciamento del carico trasmetta le query al successivo server disponibile o meno occupato: solo un server (o server di lettura in lettura) riceve una richiesta client, quindi non è necessario il bilanciamento del carico.