Evita conflitti

IBM Cloudant è progettato per trattare i conflitti come uno stato naturale dei dati in un sistema distribuito. Questa funzione è una funzione potente che aiuta un cluster IBM Cloudant a mantenere sempre l'alta disponibilità. Tuttavia, l'ipotesi è che i conflitti siano ancora ragionevolmente rari. I conflitti di traccia nel core di IBM Cloudanthanno un costo significativo associato ad essi.

È perfettamente possibile (ma una cattiva idea!) ignorare i conflitti. Il database continua allegramente a funzionare scegliendo una revisione casuale, ma deterministica, dei documenti in conflitto. Tuttavia, con l'aumento del numero di conflitti non risolti, le prestazioni del database diminuisce di un buco nero, specialmente quando si esegue la replica.

Come sviluppatore, è tua responsabilità controllare e risolvere i conflitti, o ancora meglio, utilizzare modelli di dati che rendono i conflitti impossibili.

Se si creano conflitti di routine, è necessario considerare le modifiche del modello: anche se si risolvono i conflitti con diligenza, i rami dei conflitti nell'albero di revisione rimangono senza un modo semplice per riordinarli. Per ulteriori informazioni, consultare i seguenti siti web:

• IBM Cloudant guida ai conflitti
• Guida IBM Cloudant alle versioni e MVCC
• Serie di blog in tre parti su conflitti

L'eliminazione dei documenti non li elimina

L'eliminazione di un documento da un database IBM Cloudant non lo elimina. L'eliminazione viene implementata scrivendo una nuova revisione del documento in fase di eliminazione, con un campo aggiunto _deleted: true. Questa revisione speciale è chiamata tombstone. Le tombe occupano ancora spazio e vengono anche passate dal replicatore.

I modelli che si basano su eliminazioni frequenti di documenti non sono adatti per IBM Cloudant. Per ulteriori informazioni, vedi IBM Cloudant tombstone docs.

Fai attenzione con gli aggiornamenti

Alla fine è più costoso mutare i documenti esistenti piuttosto che crearne di nuovi. IBM Cloudant deve sempre mantenere la struttura ad albero del documento struttura intorno. Questa regola si applica anche se i nodi interni nella struttura ad albero vengono rimossi dai relativi payload. Se si crea una struttura ad albero di revisione lunga, le proprie prestazioni di replica ne risentono. Inoltre, se la frequenza di aggiornamento è maggiore di, ad esempio, una o due volte ogni pochi secondi, è più probabile che si verifichino conflitti di aggiornamento.

Preferire modelli che sono immutabili.

Quando si leggono le seguenti sezioni, L'eliminazione dei documenti non li elimina e Attenzione agli aggiornamenti, provocano una domanda ovvia. Vale a dire, il dataset cresce senza limiti se il mio modello è immutabile? Se si accetta che le eliminazioni non eliminano completamente i dati eliminati e che gli aggiornamenti non vengono aggiornati in termini di crescita del volume di dati, non esiste molta differenza. La gestione del volume di dati nel tempo richiede tecniche differenti.

L'unico modo per recuperare spazio è quello di eliminare i database, piuttosto che i documenti. È possibile replicare solo le revisioni vincenti in un nuovo database ed eliminare il vecchio per eliminare le eliminazioni e i conflitti persistenti. Oppure puoi inserirlo nel tuo modello per avviare regolarmente nuovi database (ad esempio, "dati annuali") e archiviare (o rimuovere) dati obsoleti, se il tuo caso d'uso lo consente.

La consistenza finale è un duro taskmaster (noto anche come non leggere le tue scritture)

L'eventuale coerenza è una grande idea su carta e un contributo chiave alla capacità di IBM Cloudantdi scalare in pratica. Tuttavia, è giusto dire che la mentalità richiesta per svilupparsi rispetto a un archivio dati eventualmente coerente non si sente naturale per la maggior parte delle persone.

Spesso si viene punti quando si scrivono test simili ai seguenti:

1. Crea un database.
2. Inserire alcuni dati di test nel database.
3. Interrogare il database per alcune sottoserie di questi dati di verifica.
4. Verificare che i dati che si sono ottenuti siano i dati che si prevedeva di ottenere.

Non c'e ' niente di male in quel test? Funziona su ogni altro database che hai mai usato, giusto?

Non su IBM Cloudant.

O meglio, funziona 99 volte su 100.

Il motivo di questa differenza è una piccola finestra di incongruenza (principalmente) tra la scrittura dei dati nel database e la disponibilità di questi dati su tutti i nodi del cluster. Poiché tutti i nodi in un cluster hanno la stessa statura, non esiste alcuna garanzia che una scrittura e una successiva lettura siano servite dallo stesso nodo. Quindi, in alcune circostanze, la lettura potrebbe raggiungere un nodo prima che i dati scritti lo raggiungano.

Quindi perché non metti un breve ritardo nel tuo test tra la scrittura e la lettura? Questo ritardo rende il test meno probabile di fallire, ma il problema è ancora lì.

IBM Cloudant non ha garanzie transazionali. Mentre le scritture di documenti sono atomiche (è garantito che un documento può essere letto nella sua interezza o non può essere letto affatto), non esiste alcun modo per chiudere la finestra di incongruenza. E'li ' per progetto.

Un serio problema che ogni sviluppatore deve considerare è che non puoi presumere in modo sicuro che i dati che scrivi siano disponibili a chiunque altro in un determinato momento. Questo stato richiede un po' di tempo per abituarsi se si proviene da un tipo diverso di tradizione del database.

Suggerimento per il test: ciò che puoi fare per evitare la finestra di incongruenza nel test è verificare rispetto a un'istanza a singolo nodo di IBM Cloudant o CouchDB in esecuzione say in Docker (informazioni docker). Un singolo nodo rimuove l'eventuale problema di coerenza, ma attenzione che si sta eseguendo il test su un ambiente che si comporta in modo diverso da quello di destinazione in produzione. Caveat Emptor.

La replica non è magia

“So let’s set up three clusters across the world, Dallas, London, Sydney, with bi-directional synchronization between them to provide real-time collaboration between our 100,000 clients.”

Num. Solo ... Num. IBM Cloudant è valido per la replica. Potrebbe sembrare una magia, ma si noti che non fa alcuna garanzia di latenza. Infatti, l'intero sistema è progettato con un'eventuale coerenza in mente. Trattare la replica di IBM Cloudantcome un sistema di messaggistica in tempo reale non finisce in un luogo felice. Per questo caso d'uso, metti un sistema tra quello progettato per questo scopo, come Apache Kafka.

È difficile mettere un numero sulla velocità di trasmissione della replica. La risposta è sempre: "Dipende". Gli elementi che influiscono sulle prestazioni di replica includono, ma non sono limitati a:

1. Modifica frequenza
2. Dimensione documento
3. Numero di lavori di replica simultanei sull'intero cluster
4. Strutture ad albero dei documenti estese (in conflitto)
5. Impostazioni della capacità produttiva riservata

Per ulteriori informazioni, consultare i seguenti siti web:

• Post del Blog su topologia di replica
• IBM Cloudant guida alla replica

Utilizza l'API di massa

IBM Cloudant ha degli endpoint API per il caricamento di massa (e la lettura) di molti documenti in una sola richiesta. La lettura di molti documenti in una singola richiesta può essere molto più efficiente della lettura e della scrittura di molti documenti uno alla volta. L'endpoint di scrittura viene mostrato nel seguente esempio:

${database}/_bulk_docs

Il suo scopo principale è quello di essere una parte centrale nell'algoritmo del replicatore, ma è disponibile anche per il tuo uso, ed è fantastico.

Con '_bulk_docs, oltre a creare PouchDB, si possono implementare le operazioni di creazione, aggiornamento e cancellazione anche per i singoli documenti, riducendo così i percorsi di codice.

Il seguente esempio crea un nuovo documento, aggiorna un secondo documento esistente ed elimina un terzo documento:

curl -XPOST 'https://ACCT.cloudant.com/DB/_bulk_docs' \
     -H "Content-Type: application/json" \
     -d '{"docs":[{"baz":"boo"}, \
         {"_id":"463bd...","foo":"bar"}, \
         {"_id":"ae52d...","_rev":"1-8147...","_deleted": true}]}'

Puoi anche recuperare molti documenti in una singola richiesta emettendo un POST a _all_docs (esiste anche un endpoint relativamente nuovo denominato _bulk_get, ma questo endpoint probabilmente non è quello che desideri. È lì per uno scopo interno specifico).

Per recuperare una serie fissa di documenti utilizzando _all_docs, POST con un corpo keys, esegui questo comando:

curl -XPOST 'https://ACCT.cloudant.com/DB/_all_docs' \
     -H "Content-Type: application/json" \
     -d '{"keys":["ab234....","87addef...","76ccad..."]}'

IBM Cloudant (al momento in cui scriviamo) impone una dimensione massima di richiesta di 11 MB. _bulk_docs richieste che superano questa dimensione vengono rifiutate con un 413: Payload Too Large error.

Per ulteriori informazioni, consultare i seguenti siti web:

• IBM Cloudant documenti di operazioni di massa
• IBM Cloudant limiti di dimensione della richiesta e del documento

Non si scherza con Q, R e N a meno che non si sappia davvero cosa si sta facendo

Non modificare Q, R e N a meno che non si sappia davvero cosa si sta facendo. I parametri di quorum e frammentazione di IBM Cloudant, dopo averli rilevati, sembrano opzioni allettanti per modificare il comportamento del database.

Più coerenza, è possibile impostare il quorum di scrittura sul conteggio di repliche?

No, Ricordare che non esiste alcun modo per chiudere la finestra di incongruenza in un cluster.

Non andare lì. Il comportamento può essere molto più difficile da comprendere, soprattutto durante le partizioni di rete. Se stai usando il servizio Cloudant, i valori predefiniti sono validi per la maggior parte degli utenti.

A volte, modificare il conteggio dei frammenti per un database è essenziale per ottenere le migliori prestazioni possibili. Se non riesci a spiegarne il motivo, probabilmente peggiorerai la tua situazione.

IBM Cloudant è limitato - lascia che questo limite di frequenza informi il tuo codice

Cloudant-the - service (a differenza di CouchDBdi base) viene venduto su un modello di "capacità produttiva riservata". Ciò significa che si paga il diritto di utilizzare fino a una determinata velocità effettiva, piuttosto che la velocità effettiva che si finisce per utilizzare. Il metodo right to use impiega un po' di tempo per eseguire il sink. Un confronto sfacciato potrebbe essere quello di un contratto di telefono cellulare in cui si paga per un certo numero di minuti indipendentemente dal fatto che li si utilizza o meno.

Sebbene il confronto del contratto del telefono cellulare non cattura l'intera situazione, non esiste alcun vincolo sulla somma delle richieste che puoi effettuare a IBM Cloudant in un mese. Il vincolo è la velocità con cui vengono effettuate le richieste.

È davvero una promessa che fai a IBM Cloudant, non una promessa che IBM Cloudant ti fa. Prometti di non fare più richieste al secondo di quanto tu abbia accettato di fare in anticipo. Un limite massimo di velocità, se ti piace. Se trasgredi, IBM Cloudant non riesce a soddisfare le tue richieste con uno stato di 429: Too Many Requests. È tua responsabilità fare attenzione a questo caso e affrontarlo, il che può essere difficile quando esistono più server di applicazioni. Come possono coordinarsi per garantire che restino collettivamente al di sotto del limite delle richieste al secondo?

Le librerie client ufficiali di IBM Cloudanthanno alcune disposizioni integrate per questo caso di utilizzo che è possibile abilitare, seguendo una strategia di "backoff e nuovo tentativo".

Questo provisioning integrato è disattivato per impostazione predefinita per obbligarti a pensarci.

Tuttavia, se ci si affida solo a questa struttura, si potrebbe alla fine essere delusi. La strategia di back-off e nuovi tentativi aiuta solo nei casi di trasgressione temporanea, non un abbottonamento persistente rispetto ai limiti di capacità produttiva fornita.

La logica aziendale deve essere in grado di gestire questa condizione. Un altro modo per esaminarlo è quello di ottenere l'assegnazione per la quale si paga. Se tale assegnazione non è sufficiente, l'unica soluzione è quella di pagare una quota più elevata.

La capacità produttiva fornita è suddivisa in tre diversi bucket: Ricerche, Scritturee Query. Una Ricerca è una lettura di "chiave primaria", che richiama un documento basato sul relativo _id. Una Scrittura sta memorizzando un documento o un allegato su disco e una Query sta ricercando i documenti utilizzando un indice secondario (qualsiasi endpoint API che contiene un _design o _find ).

Si ottengono allocazioni differenti di ciascuna e i rapporti tra di esse sono fissi. Questo fatto può essere utilizzato per ottimizzare i costi. Si ottengono 20 Ricerche per ogni Query (al secondo). Potresti scoprire che stai principalmente raggiungendo il limite di Query, ma hai un sacco di spazio in Ricerche. Potrebbe essere possibile ridurre l'affidamento su Query tramite un rimodellamento dei dati o forse eseguendo più operazioni sul lato client.

Il corollario qui però è che non si può presumere che qualsiasi libreria o framework di terze parti ottimizzi per costi in anticipo rispetto alla convenienza. I framework lato client che supportano più livelli di persistenza utilizzando i plug-in difficilmente sono a conoscenza di questa situazione o potrebbero non essere in grado di raggiungere tali compromessi.

La verifica della compatibilità del framework o della libreria di terze parti prima di eseguire il commit su uno strumento particolare è una buona idea.

È inoltre importante capire che le tariffe non sono direttamente equivalenti alle chiamate all'endpoint API di HTTP. È necessario prevedere che, ad esempio, un aggiornamento di massa conti in base alle scritture del relativo documento costituente.

• IBM Cloudant documentazione su piani e prezzi su IBM cloud pubblico

La registrazione ti aiuta a vedere cosa sta succedendo

i log di IBM Cloudantche indicano ogni chiamata API effettuata, cosa è stato richiesto e quanto tempo è stato necessario per rispondere possono essere inviati automaticamente in spool a IBM Cloud Logs per l'analisi e la reportistica dei servizi IBM Cloud. Questi dati sono utili per tenere d'occhio i volumi di richiesta, le prestazioni e se la tua applicazione supera la capacità di provisioning per il tuo servizio IBM Cloudant.

IBM Cloud Logs è un servizio a pagamento che offre diversi periodi di conservazione e livelli di consumo dei registri. I livelli consentono di conservare i dati per archiviarli su COS, di effettuare ricerche a freddo o a caldo e di ricevere avvisi a costi variabili. Le sezioni e le aggregazioni dei dati possono essere integrate in dashboard visivi per fornirti una vista immediata del tuo traffico IBM Cloudant. Per ulteriori informazioni, consulta la seguente documentazione:

• Come iniziare con IBM Cloud Logs
• Per iniziare con IBM Cloud Logs Routing
• Ottimizzatore del costo totale di proprietà dei registriIBM Cloud

Comprimere il traffico di HTTP

IBM Cloudant comprime le risposte JSON se si fornisce un'intestazione HTTP nella richiesta, che indica che il codice può gestire dati in questo formato:

Request:

> GET /cars/_all_docs?limit=5&include_docs=true HTTP/2
> Host: myhost.cloudant.com
> Accept: */*
> Accept-Encoding: deflate, gzip

Response:                                                                   

< HTTP/2 200
< content-type: application/json
< content-encoding: gzip

Il contenuto compresso occupa una frazione della dimensione dell'equivalente decompresso, il che significa che impiega un tempo più breve per trasportare i dati dai server di IBM Cloudantalla propria applicazione.

Si può anche scegliere di comprimere i corpi delle richieste di HTTP utilizzando l'intestazione Content-encoding. Questa pratica consente di ridurre i tempi di trasferimento dei dati quando si scrivono documenti su IBM Cloudant.