Utilizzando IBM Cloudant

Se non utilizzi mai IBM Cloudant o i database NoSQL in genere, esegui la scansione di questa introduzione e di alcune procedure ottimali prima di leggere ulteriormente. Descrive le cose più importanti che devi sapere su IBM Cloudant e su come utilizzarlo al meglio. Il resto della documentazione presuppone che tu conosca questi principi di base.

Puoi trovare ulteriori informazioni su IBM Cloudant nelle seguenti sezioni:

Connessione a IBM Cloudant

Per accedere a IBM Cloudant, devi avere un accountIBM Cloud®.

API HTTP

Tutte le richieste a IBM Cloudant passano attraverso il web. Questa istruzione significa che qualsiasi sistema che può parlare con il web può parlare con IBM Cloudant. Tutte le librerie specifiche della lingua per IBM Cloudant sono solo wrapper che forniscono alcune comodità e sottigliezze linguistiche per aiutarti a lavorare con una semplice API. Molti utenti scelgono di utilizzare le librerie HTTP raw per lavorare con IBM Cloudant.

Per ulteriori informazioni su come IBM Cloudant utilizza HTTP, vedi HTTP nel riferimento API.

IBM Cloudant supporta i seguenti metodi di richiesta HTTP:

GET: Consente di richiedere l'elemento specificato. Come con le normali richieste HTTP, il formato dell'URL definisce ciò che viene restituito. Con IBM Cloudant, questa definizione può includere elementi statici, documenti del database e informazioni statistiche e di configurazione. Nella maggior parte dei casi, le informazioni vengono restituite sotto forma di un documento JSON.
HEAD: Il metodo HEAD richiama l'intestazione HTTP di una richiesta GET senza il corpo della risposta.
POST: Carica i dati. Nell'API di IBM Cloudant, il metodo POST imposta i valori, carica i documenti, imposta i valori dei documenti e avvia alcuni comandi di gestione.
PUT: Utilizzato per "memorizzare" una risorsa specifica. Nell'API di IBM Cloudant, PUT crea nuovi oggetti, inclusi database, documenti, viste e documenti di progettazione.
DELETE: Elimina la risorsa specificata, inclusi i documenti, le viste e i documenti di progettazione.
COPY: Un metodo speciale che copia documenti e oggetti.

Se il client (come alcuni browser Web) non supporta l'utilizzo di metodi HTTP, è possibile utilizzare POST con l'intestazione della richiesta X-HTTP-Method-Override impostata sul metodo HTTP effettivo.

Errore di metodo non consentito

Se si utilizza un tipo di richiesta HTTP non supportato con un indirizzo URL che non supporta il tipo specificato, viene restituito un errore 405 . L'errore che elenca i metodi HTTP supportati, come mostrato nel seguente esempio.

Messaggio di errore di esempio in risposta a una richiesta non supportata

{
    "error":"method_not_allowed",
    "reason":"Only GET,HEAD allowed"
}

JSON

IBM Cloudant memorizza i documenti che utilizzano la codifica JSON (JavaScript Object Notation), quindi qualsiasi cosa codificata in JSON può essere memorizzata come un documento. I file che includono supporti, come immagini, video e audio, sono chiamati BLOB (Binary Large Objects). I BLOB possono essere memorizzati come allegati associati ai documenti.

Ulteriori informazioni su JSON sono disponibili nella Guida JSON.

Sistemi distribuiti

Utilizzando l'API di IBM Cloudant, puoi interagire con la collaborazione di numerose macchine, denominate cluster. Le macchine in un cluster devono trovarsi nello stesso datacenter, ma possono trovarsi all'interno di "pod" differenti in tale datacenter. L'utilizzo di pod diversi aiuta a migliorare le caratteristiche di alta disponibilità di IBM Cloudant.

Un vantaggio del clustering è che quando si ha bisogno di più capacità di elaborazione, si aggiungono più macchine. Questo metodo è spesso più conveniente e fault-tolerant che scalare o migliorare una singola macchina esistente.

Per ulteriori informazioni sui concetti di IBM Cloudant e dei sistemi distribuiti, consulta la guida Teorema CAP.

Replica

Replica è una procedura seguita da IBM Cloudant, CouchDB, PouchDBe altri database distribuiti. La replica sincronizza lo stato di due database in modo che i loro contenuti siano identici.

Puoi replicare in modo continuo. La replica continua significa che un database di destinazione viene aggiornato ogni volta che cambia il database di origine. La replica continua può essere utilizzata per i backup dei dati, aggregando i dati tra più database o per la condivisione dei dati.

Tuttavia, la replica continua significa anche esecuzione di test in modo continuo per ogni modifica del database di origine. Questa esecuzione di test richiede continue chiamate interne, che potrebbero influire sulle prestazioni o sul costo di utilizzo del database.

La replica continua può comportare molte chiamate interne. Queste chiamate potrebbero influire sui costi per gli utenti a più tenant dei sistemi IBM Cloudant. La replica continua è disabilitata per impostazione predefinita.

Utilizzo dello strumento appropriato per il lavoro

IBM Cloudant è un archivio documenti JSON scalabile, durevole, altamente disponibile e operativo con un'API HTTP. È adatto per i seguenti scopi:

Alimentazione dell'applicazione Web sempre attiva.
L'archivio dati lato server per le applicazioni mobili.
Archiviazione di dati di serie temporali in database con caselle temporali prima di archiviarli nell'archivio oggetti ed eliminare l'originale.
Archiviazione degli oggetti dell'applicazione come JSON mentre le query vengono distribuite dagli indici secondari.
Replica dei dataset nelle aree geografiche per il ripristino di emergenza, la capacità aggiuntiva o lo spostamento dei dati più vicini agli utenti.

IBM Cloudant non include le seguenti funzioni:

Bassa latenza, archivio dati in memoria. Per ulteriori informazioni, consultare IBM Cloud® Databases for Redis.
Archivio oggetti senza limiti per l'archiviazione dei dati. Per ulteriori informazioni, vedi IBM Cloud Object Storage.
Database relazionale con query SQL, procedure memorizzate, vincoli e trigger. Per ulteriori informazioni, vedi IBM Cloud Databases for PostgreSQL.
Data warehouse per query ad hoc. Per ulteriori informazioni, vedi IBM® Db2® Warehouse as a Service.
Una coda. Per ulteriori informazioni, consultare IBM MQ.

Per ulteriori informazioni, consultare il blog Pratica migliore e peggiore .

Organizzazione di documenti e database

IBM Cloudant i dati sono organizzati in una gerarchia di database e documenti. Un documento è un oggetto JSON con un identificativo univoco: il suo _id. Un database è una raccolta di documenti con un indice principale che consente di richiamare i documenti da _id. Dispone anche di indici secondari facoltativi che consentono ai documenti di essere interrogati da altri attributi nell'oggetto.

Quando gli sviluppatori avviano un progetto, a volte lottano con le seguenti domande:

Quanti dati è possibile inserire in un singolo oggetto?
Devo memorizzare diversi tipi di documenti nella stessa raccolta o un database per tipo di documento?

È importante che un documento includa tutti i dati su un oggetto modellato dall'applicazione, ad esempio un utente, un ordine o un prodotto. Questa pratica garantisce il recupero dell'intero oggetto dal database in una chiamata API. IBM Cloudant non ha il concetto di join come un database relazionale, quindi i dati non sono normalizzati. Tuttavia, i dati possono ripetersi tra gli oggetti. Ad esempio, un documento di ordine può includere un sottoinsieme di documenti del prodotto ** che sono stati acquistati.

È comune memorizzare diversi tipi di oggetti nello stesso database: una convenzione è che un attributo type viene utilizzato per indicare il tipo di oggetto. Questa opzione è buona se è necessario eseguire query che restituiscono diversi tipi di oggetto o se un database deve essere replicato in un'altra ubicazione. In caso contrario, i database separati, ad esempio, users, orders, products, potrebbero essere migliori in modo che gli indici secondari siano specifici per ciascun tipo di oggetto.

Se si stanno memorizzando array di oggetti all'interno di un documento, considerare se gli elementi dell'array devono essere realmente il proprio documento. Ad esempio, un prodotto ** e ogni revisione prodotto devono essere memorizzati in documenti separati, ma un utente e ciascuno degli ordini di tale utente devono avere il proprio documento.

Se si dispone di un dataset in continua crescita, probabilmente non si desidera archiviare i dati in un unico database in continua crescita. I dati sono archiviati al meglio in database time - boxed che consentono di archiviare ed eliminare in modo pulito i dati più vecchi. L'eliminazione di un documento IBM Cloudant lascia indietro un documento tombstone , quindi non fare affidamento sull'eliminazione di documenti per recuperare spazio su disco. Invece, è necessario fare affidamento sull'eliminazione di interi database.

JSON non offre un modo nativo per memorizzare date o timestamp. Scegliere con attenzione il formato data se si intende eseguire la query in un secondo momento.

La dimensione massima del documento è 1 MB, ma i documenti devono essere molto più piccoli di tale dimensione, in genere pochi KB.

Per ulteriori informazioni, consultare i seguenti post del blog:

Sfruttare al massimo l'indice primario

IBM Cloudant ha un indice primario nell'attributo _id del documento. Questo indice consente ai documenti di essere richiamati da _id (GET /db/id) o da un intervallo di _ids (GET /db/_all_docs?startkey="a"&endkey="z"). Memorizzando i dati nella chiave primaria e garantendo che ogni _id sia univoco, è possibile utilizzare l'indice principale per recuperare documenti e intervalli di documenti senza indicizzazione secondaria. Vedi il seguente elenco di idee:

Se si dispone di un oggetto univoco che potrebbe essere utile per eseguire una query, utilizzarlo come campo _id , ad esempio, bob.smith@gmail.com, isbn9780241265543o oakland,ca.
Se gli oggetti contengono una gerarchia, modellarla in _id: usa:ca:oakland o books:fiction:9780241265543. La gerarchia va dal più grande al più piccolo, quindi è possibile utilizzare l'indice primario per trovare tutte le città in usa o tutte le città in usa:ca, senza indicizzazione secondaria.
Se stai memorizzando i dati delle serie temporali, la codifica dell'ora all'inizio del tuo _id ordina l'indice primario per ora, ad esempio 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ.
I database partizionati raggruppano documenti che condividono una chiave di partizione. Una chiave di partizione deve avere molti valori e non deve includere punti di scelta rapida per evitare di indirizzare una grande percentuale del traffico dell'applicazione a poche partizioni.

Per ulteriori informazioni, consultare i seguenti post del blog:

Query e indici secondari

IBM Cloudant consente l'esecuzione di query su un singolo database che restituisce un array di documenti corrispondenti e un segnalibro, che consente l'accesso al blocco successivo dei risultati della ricerca. Il raggiungimento di migliori prestazioni di query dipende dal fatto che le query siano supportate da indici secondari appropriati. Un indice consente al database di rispondere a una query senza dover sfogliare ogni documento del database, ottenendo prestazioni molto più veloci.

Consultare i seguenti suggerimenti:

A volte è difficile misurare le prestazioni delle query fino a quando il dataset non è abbastanza grande da esporre operazioni lente. Generare dati realistici sufficienti in modo da poter verificare le prestazioni dell'indicizzazione e della query prima di passare alla produzione.
IBM Cloudant potrebbe restituirti i dati senza un indice, ma non devi mai fare affidamento su questi dati per i carichi di lavoro di produzione. Se la serie di risultati include l'avvertenza, No matching index found. Create an index to optimize query time, è necessario rivedere la strategia di indicizzazione. Utilizzare la funzione explain per vedere quale indice viene selezionato per ogni query.
Con diversi tipi di oggetto nello stesso database, molti casi di utilizzo possono essere gestiti da pochi indici su attributi fissi. Per ulteriori informazioni, vedi Optimal IBM Cloudant Indexing.
Assegnare nomi significativi agli indici e specificare il nome dell'indice al momento della query, in modo che sia ovvio quale indice corrisponde a quale query della propria applicazione.

Per ulteriori informazioni, consultare i seguenti post del blog: