Comprendere l'API di destinazione

Puoi utilizzare Java™, Python, Goo Node.js o qualche altro linguaggio o piattaforma specifici del caso di utilizzo. Una di queste lingue viene probabilmente fornita con comode librerie lato client che integrano l'accesso IBM Cloudant, seguendo le convenzioni che ti aspetti per i tuoi strumenti. Questi linguaggi sono ottimi per l'efficienza del programmatore, ma nascondono anche l'API dalla vista.

Questa astrazione è ciò che si desidera, l'intero motivo per utilizzare una libreria client è quello di salvare te stesso ripetuto, tedioso caldaia - placcatura. Tuttavia, è necessario comprendere che l'API sottostante è fondamentale quando si risolvono i problemi e si riportano i problemi. Quando riferisci un problema sospetto a IBM Cloudant, ci aiuta se puoi fornirci un modo per riprodurre il problema.

Questa richiesta non significa tagliare e incollare una porzione elevata dell'origine Java™ dell'applicazione in un ticket di supporto, poiché probabilmente non siamo in grado di crearla. Inoltre, il tuo codice lato client introduce incertezze su dove potrebbe essere il problema, il tuo lato o il nostro lato?

Invece, i team di IBM Cloudantdi supporto di solito richiedono la serie di chiamate API, idealmente come una serie di comandi curl che possono eseguire, che dimostra il problema. L'adozione di questo approccio alla risoluzione dei problemi come regola rende anche più facile individuare i problemi che stanno fallendo. Se il tuo codice sta comportando in modo imprevisto, prova a riprodurre il problema utilizzando solo l'accesso diretto all'API.

Se non puoi, il problema non è con il servizio IBM Cloudant stesso.

Se stai indagando su un problema di prestazioni, consulta i log forniti da IBM Cloud®. Se i log mostrano che la tua richiesta viene gestita rapidamente da IBM Cloudant, ma la tua applicazione è lenta, la radice di questo problema risiede nel codice dell'applicazione lato client. Vedi la regola relativa alla registrazione e monitoraggio.

Se si sospetta che un problema risieda in una libreria client supportata ufficialmente, provare a creare un piccolo esempio di codice autonomo che dimostri il problema. In questo esempio di codice autonomo, utilizzare il minor numero possibile di altre dipendenze. Se stai utilizzando Java™, è utile per noi se puoi utilizzare un test harness minimo per evidenziare i problemi della libreria.

Occasionalmente, IBM Cloudant riceve ticket di supporto che affermano che "IBM Cloudant è interrotto perché la mia applicazione è lenta" senza molte prove di supporto. Quasi sempre questo caso può essere ricondotto a problemi nel codice dell'applicazione sul lato client o a equivoci su come funziona IBM Cloudant.

Non sempre, ma quasi sempre.

Comprendendo meglio l'API, ottieni anche esperienza su come IBM Cloudant si comporta, specialmente in termini di prestazioni. Se si utilizza una libreria client, bisogna almeno sapere come scoprire quali richieste di HTTP sono generate da una specifica chiamata di funzione. Per ulteriori informazioni, consultare i seguenti siti web:

• IBM Cloudant Documentazione API
• Registrazione integrazione
• Post del blog su logging

I documenti devono raggruppare i dati che per lo più cambiano insieme

Quando inizi a modellare i tuoi dati, prima o poi, ti impari il problema di come potrebbero essere strutturati i tuoi documenti. Ora sai che IBM Cloudant non applica alcuna normalizzazione e che non ha transazioni del tipo a cui sei abituato, ad esempio, Postgres. La tentazione può essere quella di inserire il più possibile in ogni documento, risparmiando anche sull'utilizzo del sito HTTP.

Questa pratica è spesso una cattiva idea.

Se il tuo modello raggruppa le informazioni che non cambiano insieme, è più probabile che tu soffra di conflitti di aggiornamento.

Si consideri una situazione in cui sono presenti utenti, ciascuno con una serie di ordini associati. Un modo potrebbe essere quello di rappresentare gli ordini come un array nel documento utente:

{ // DON'T DO THIS
  "customer_id": 65522389,
  "orders": [
    {
      "order_id": 887865,
      "items": [
        {
          "item_id": 9982,
          "item_name": "Iron sprocket",
          "cost": 53.0
        },
        {
          "item_id": 2932,
          "item_name": "Rubber wedge",
          "cost": 3.0
        }
      ]
    }
  ]
}

Per aggiungere un ordine, ho bisogno di recuperare il documento completo, annullare il marshalling del JSON, aggiungere l'elemento, eseguire il marshalling del nuovo JSON e inviarlo di nuovo come aggiornamento. Se sono l'unico a farlo, potrebbe funzionare per un po '. Se il documento è in fase di aggiornamento simultaneo o è in fase di replica, potrebbero verificarsi conflitti di aggiornamento.

Invece, mantenere gli ordini separati come tipo di documento, facendo riferimento all'ID cliente. Ora il modello è immutabile. Per aggiungere un ordine, creo un nuovo documento di ordine nel database, che non può generare conflitti.

Per essere in grado di recuperare tutti gli ordini per un cliente specifico, possiamo utilizzare una vista, che copriamo in seguito.

Evitare costrutti che si basano su aggiornamenti di parti di documenti esistenti, laddove possibile. I modelli di dati errati sono spesso difficili da cambiare dopo che sei in produzione.

Il modello precedente può essere risolto in modo efficiente utilizzando i database partizionati, che sono trattati in modo più dettagliato in seguito.

Per ulteriori informazioni, consulta la seguente documentazione:

• IBM Cloudant guida alla modellazione dati
• Partizioni database

Conserva documenti di piccole dimensioni

IBM Cloudant impone una dimensione massima del documento di 1 MB. Questo limite non significa che una dimensione del documento close-to-1-MB sia una buona idea. Al contrario, se si scopre che si stanno creando documenti che superano i KB a una cifra, è probabilmente necessario rivedere il modello. Diverse cose in IBM Cloudant diventano meno performanti man mano che i documenti crescono. La decodifica JSON, ad esempio, è costosa.

Si esaminino le sezioni seguenti: I documenti devono raggruppare i dati che per lo più cambiano e Conserva i documenti in piccolo. Vale la pena sottolineare che i modelli che si basano su aggiornamenti hanno un limite di volume massimo di 1 MB, il limite per la dimensione dei documenti. Questa taglia non e'quella che vuoi.

Evita di utilizzare gli allegati

IBM Cloudant ha il supporto per memorizzare gli allegati insieme ai documenti, una funzione di lunga data che eredita da CouchDB. Se utilizzi IBM Cloudant come backend per un'applicazione web, puoi anche memorizzare piccole icone e altri asset statici come i file CSS e JavaScript con i dati.

Devi considerare alcune cose prima di utilizzare gli allegati in IBM Cloudant oggi, soprattutto se stai guardando asset più grandi come immagini e video:

1. IBM Cloudant è costoso come un archivio blocchi.
2. L'implementazione interna di IBM Cloudantnon è efficace nella gestione di grandi quantità di dati binari.

Quindi, lento e costoso.

IBM Cloudant è accettabile per piccoli asset e per utilizzi occasionali. Di regola, se devi archiviare i dati binari insieme ai documenti IBM Cloudant, è meglio utilizzare una soluzione separata più adatta a questo scopo. Devi archiviare solo i metadati dell'allegato nel documento IBM Cloudant. Sì, questo significa che devi scrivere del codice extra per caricare l'allegato in un block store adatto a tua scelta. Verificare che l'operazione sia riuscita prima di memorizzare il token o URL all'allegato nel documento IBM Cloudant.

I database sono più piccoli, più economici, più veloci e più facili da replicare. Per ulteriori informazioni, consultare i seguenti siti web:

• Documenti IBM Cloudant su allegati
• Scollegamento di IBM Cloudant allegati a Object Storage

Meno database sono migliori di molti

Se puoi, limita il numero di database per account IBM Cloudant a 500 o meno. Anche se questo particolare numero non è magico (IBM Cloudant può gestirne di più in modo sicuro), esistono diversi casi di utilizzo che sono influenzati negativamente da un numero elevato di database in un account.

Il programma di pianificazione del replicatore ha un numero limitato di lavori di replica simultanei che è pronto ad eseguire. Con l'aumento del numero di database, è probabile che la latenza di replica aumenti se tenti di replicare tutto ciò che è contenuto in un account.

Il rovescio della medaglia è l'aspetto operativo: il team operativo di IBM Cloudantsi affida anche alla replica per spostarsi tra gli account. Mantenendo basso il numero di database, ci aiuti ad aiutarti se hai bisogno di spostare il tuo account da una sede all'altra.

Quindi, quando è necessario utilizzare un singolo database e distinguere tra diversi tipi di documenti utilizzando le visualizzazioni e quando è necessario utilizzare più database per modellare i dati? IBM Cloudant non è in grado di federare le viste su più database. Se si dispone di dati non correlati che non possono mai essere "uniti" o interrogati insieme, tali dati possono essere un candidato per la suddivisione tra più database.

Se hai un set di dati in continua crescita (come un log, letture di sensori o altri tipi di serie temporali), non è nemmeno una buona idea creare un unico, sempre più grande, database. Questo tipo di caso d'uso richiede tempo - boxe, che copriamo più in dettaglio in seguito.

Evitare l'anti - pattern database per utente come la peste

Se stai creando un servizio multiutente su IBM Cloudant, è allettante consentire a ogni utente di archiviare i propri dati in un database separato nell'account dell'applicazione. Questo funziona bene, soprattutto, se il numero di utenti è piccolo.

Aggiungere ora la necessità di derivare l'analisi tra utenti. Il modo in cui si esegue questa operazione è replicare tutti i database utente in un singolo database di analisi. Tutto bene. Questa applicazione ha improvvisamente avuto successo, e il numero di utenti è cresciuto nell'intervallo di 150-20.000. Hai 20.000 repliche solo per mantenere aggiornato il database di analisi. Se si desidera eseguire anche una configurazione di ripristino di emergenza active - active, aggiungere altre 20.000 repliche e il sistema smette di funzionare.

Invece, i dati utente multiplex in un numero minore di database, o gli utenti shard in una serie di database o account, o entrambi. In questo modo, non hai bisogno di replicare per fornire un database di analisi, ma l'autenticazione diventa più complicata in quanto IBM Cloudant fornisce solo l'autenticazione a livello di database.

Vale la pena affermare che l'approccio "database - per - utente" è allettante perché le autorizzazioni IBM Cloudant sono "per database", ma non è in realtà l'errore degli utenti che questo pattern è emerso.

Evitare di scrivere funzioni di riduzione JavaScript personalizzate

Le viste MapReduce in IBM Cloudant sono fantastiche. Tuttavia, con grande potere viene una grande responsabilità. La parte della mappa di una vista MapReduce viene creata in modo incrementale, quindi il codice scadente nella mappa influisce solo sul tempo di indicizzazione, non sul tempo di query. La parte di riduzione, purtroppo, viene eseguita al momento della query. IBM Cloudant fornisce una serie di funzioni di riduzione integrate implementate internamente in Erlang. Queste funzioni sono performanti in scala, mentre le riduzioni JavaScript create manualmente non lo sono.

Se ci si trova a scrivere funzioni di riduzione, arrestare e considerare se è possibile riorganizzare i dati in modo che la scrittura funzioni di riduzione non sia necessaria. O in modo che tu possa fare affidamento sui riduttori incorporati.

Le viste sui database con partizioni non supportano le riduzioni personalizzate, che è un fattore che contribuisce alle query più rapide che solo tali viste possono offrire.

Per ulteriori informazioni, vedi IBM Cloudant docs on reduce.

Utilizzare i database time boxed per insiemi di dati in continua espansione

In genere non è una buona idea avere un database in continua crescita in IBM Cloudant. I database di grandi dimensioni possono essere difficili da eseguire il backup, richiedono un "resharding" per mantenere buone prestazioni man mano che crescono e soffrono di lunghi tempi di creazione dell'indice.

Un modo per mitigare questo problema consiste invece nell'avere diversi database più piccoli, con uno schema comune che è database con finestre temporali: un dataset di grandi dimensioni viene suddiviso in database più piccoli, ognuno dei quali rappresenta una finestra temporale, ad esempio un mese.

• orders_2019_01
• orders_2019_02
• orders_2019_02

Nuovi dati vengono scritti nel database di questo mese e le query per i dati cronologici possono essere indirizzati ai database dei mesi precedenti. Quando i dati di un mese non sono più di interesse, possono essere archiviati in Object Storage, il database mensile IBM Cloudant viene eliminato e lo spazio su disco ripristinato. Per ulteriori informazioni, consultare il seguente sito web.

• Blog di Time - series Data Storage