IBM Cloudant verwenden

Falls Sie bisher weder IBM Cloudant noch NoSQL-Datenbanken verwendet haben, lesen Sie zunächst diese Einführung und einige bewährte Verfahren, bevor Sie tiefer in die Materie eindringen. Diese Einführung beschreibt die wichtigsten Punkte zu IBM Cloudant und zu dessen Verwendung. In der übrigen Dokumentation werden diese Grundlagen vorausgesetzt.

Weitere Informationen zu IBM Cloudant finden Sie in den folgenden Abschnitten:

Verbindung zu IBM Cloudant herstellen

Für den Zugriff auf IBM Cloudant, müssen Sie über ein IBM Cloud®-Konto verfügen.

HTTP-API

Alle Anforderungen an IBM Cloudant werden über das Web übermittelt. Dies bedeutet, dass alle Systeme, die über das Web kommunizieren, auch mit IBM Cloudant kommunizieren können. Alle sprachspezifischen Bibliotheken für IBM Cloudant sind letztlich nur Wrapper, die Ihre Arbeit mit einer simplen API komfortabler und sprachlich einfacher gestalten. Viele Benutzer möchten unformatierte HTTP-Bibliotheken für die Arbeit mit IBM Cloudant verwenden.

Weitere Informationen zur Verwendung von HTTP in IBM Cloudant finden Sie unter HTTP in der API-Referenz.

IBM Cloudant unterstützt die folgenden HTTP-Anforderungsmethoden:

GET
Anforderung des angegebenen Elements. Wie bei normalen HTTP-Anforderungen definiert das Format der URL, was zurückgegeben wird. Mit IBM Cloudant kann diese Definition statische Elemente, Datenbankdokumente und Konfigurations- sowie statische Informationen einschließen. In den meisten Fällen werden die Informationen in Form eines JSON-Dokuments zurückgegeben.
HEAD
Die Methode HEAD ruft den HTTP-Header einer GET-Anforderung ohne den Hauptteil der Antwort ab.
POST
Hochladen von Daten. In der API von IBM Cloudant werden mit der Methode POST Werte festgelegt, Dokumente hochgeladen, Dokumentwerte festgelegt und einige Verwaltungsbefehle gestartet.
PUT
Speichern einer bestimmten Ressource. In der API von IBM Cloudant werden mit PUT neue Objekte erstellt, darunter Datenbanken, Dokumente, Ansichten und Entwurfsdokumente.
DELETE
Löscht die angegebene Ressource, z. B. Dokumente, Ansichten und Entwurfsdokumente.
COPY
Eine spezielle Methode, die Dokumente und Objekte kopiert.

Wenn der Client (z. B. manche Web-Browser) keine Unterstützung für die Verwendung von HTTP-Methoden bieten, kann stattdessen POST mit dem Anforderungsheader X-HTTP-Method-Override verwendet werden, der auf die tatsächliche HTTP-Methode gesetzt ist.

Fehler aufgrund unzulässiger Methode

Wenn Sie einen nicht unterstützten Anforderungstyp „ HTTP “ bei einem „ URL “ verwenden, der den angegebenen Typ nicht unterstützt, wird ein 405- Fehler zurückgegeben. Dies ist ein Fehler, der die unterstützten HTTP-Methoden auflistet, wie im folgenden Beispiel dargestellt.

Beispiel einer Fehlernachricht als Antwort auf eine nicht unterstützte Anforderung

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

JSON

IBM Cloudant speichert Dokumente, die JSON (JavaScript Object Notation) verwenden, deshalb können alle in JSON codierten Elemente als Dokument gespeichert werden. Dateien, die Medien wie Bilder, Videos und Audio enthalten, werden als BLOBs (Binary Large Objects) bezeichnet. BLOBs können als Anhänge gespeichert werden, die Dokumenten zugeordnet sind.

Weitere Informationen zu JSON finden Sie in der JSON-Anleitung.

Verteilte Systeme

Mithilfe der API von IBM Cloudant können Sie mit einem Zusammenschluss zahlreicher Systeme, auch Cluster genannt, interagieren. Die Systeme in einem Cluster müssen sich zwar im selben Rechenzentrum befinden, können aber in unterschiedlichen Pods in diesem Rechenzentrum untergebracht sein. Der Einsatz unterschiedlicher Pods verbessert die Hochverfügbarkeitsmerkmale von IBM Cloudant.

Ein Vorteil des Clustering: Wenn Sie mehr Rechenleistung benötigen, fügen Sie einfach mehr Systeme hinzu. Diese Methode ist oft kostengünstiger und fehlertoleranter als die Skalierung nach oben oder die Erweiterung eines einzelnen vorhandenen Systems.

Weitere Informationen zu IBM Cloudant und verteilten Systemkonzepten finden Sie in der Anleitung CAP-Theorem.

Replikation

Replikation ist ein Verfahren, das von IBM Cloudant angewendet wird, CouchDB, PouchDB, und anderen verteilten Datenbanken. Die Replikation synchronisiert den Status zweier Datenbanken, damit ihre Inhalte identisch sind.

Sie können fortlaufend replizieren. Eine fortlaufende Replikation bedeutet, dass eine Zieldatenbank jedes Mal aktualisiert wird, wenn sich die Quellendatenbank ändert. Eine fortlaufende Replikation kann zum Sichern und Teilen von Daten verwendet werden, die Daten werden in diesem Fall datenbankübergreifend aggregiert.

Allerdings bedeutet eine fortlaufende Replikation, dass kontinuierlich auf Änderungen der Quellendatenbank geprüft wird. Diese Prüfung erfordert wiederholte interne Aufrufe, die sich auf die Leistung oder die Kosten für die Verwendung der Datenbank negativ auswirken können.

Die fortlaufende Replikation kann viele interne Aufrufe auslösen. Diese Aufrufe können sich negativ auf die Kosten für Multi-Tenant-Benutzer von IBM Cloudant-Systemen auswirken. Eine fortlaufende Replikation ist standardmäßig inaktiviert.

Das richtige Tool für den Job verwenden

IBM Cloudant ist ein skalierbarer, permanenter, hoch verfügbarer, operativer JSON-Dokumentspeicher mit einer HTTP-API. Er eignet sich für die folgenden Zwecke:

  • Grundlage Ihrer stets verfügbaren Webanwendung.
  • Serverseitiger Datenspeicher für mobile Anwendungen.
  • Speicherung von Zeitreihendaten in Datenbanken mit Timebox vor der Archivierung im Objektspeicher und Löschung der ursprünglichen Daten.
  • Speicherung von Anwendungsobjekten als JSON bei gleichzeitiger Übergabe von Abfragen aus sekundären Indizes.
  • Replizieren von Datasets in verschiedenen Regionen für die Disaster-Recovery, für zusätzliche Kapazität oder für das Verschieben von Daten in die Nähe Ihrer Benutzer.

IBM Cloudant enthält nicht die folgenden Features:

  • Speicherinterner Datenspeicher mit niedriger Latenzzeit. Weitere Informationen finden Sie unter IBM Cloud® Databases for Redis.
  • Grenzenloser Objektspeicher für die Archivierung von Daten. Weitere Informationen finden Sie unter IBM Cloud Object Storage.
  • Relationale Datenbank mit SQL-Abfragen, gespeicherten Prozeduren und Integritätsbedingungen und Auslösern. Weitere Informationen finden Sie unter IBM Cloud Databases for PostgreSQL.
  • Eine Warteschlange. Weitere Informationen finden Sie unter IBM MQ.

Weitere Infroamtionen finden Sie im Blog Best and worst practice.

Dokumente und Datenbanken organisieren

IBM Cloudant-Daten werden in einer Hierarchie von Datenbanken und Dokumenten organisiert. Ein Dokument ist ein JSON-Objekt mit einer eindeutigen Kennung (_id). Eine Datenbank ist eine Sammlung von Dokumenten mit einem Primärindex, der das Abrufen von Dokumenten anhand der Dokument-ID (_id) ermöglicht. Eine Datenbank verfügt außerdem über optionale sekundäre Indizes, die das Abrufen von Dokumenten mithilfe anderer Attribute im Objekt ermöglichen.

Wenn ein Entwickler ein Projekt startet, muss er sich manchmal mit den folgenden Fragen beschäftigen:

  • Wie viele Daten kann ein einzelnes Objekt enthalten?
  • Muss ich verschiedene Dokumenttypen in derselben Sammlung oder in einer Datenbank pro Dokumenttyp speichern?

Wichtig: Ein Dokument sollte alle Daten zu einem Objekt enthalten, das von Ihrer Anwendung modelliert wird (z. B. ein Benutzer, eine Bestellung oder ein Produkt). Dieser Ansatz stellt sicher, dass Sie das gesamte Objekt mit einem API-Aufruf aus der Datenbank abrufen. IBM Cloudant verfügt nicht wie eine relationale Datenbank über das Konzept von Joins; Daten werden daher nicht normalisiert. Daten können jedoch über Objekte hinweg wiederholt werden. Ein Dokument des Typs order kann beispielsweise eine Untergruppe der erworbenen product-Dokumente enthalten.

Es ist üblich, mehrere Objekttypen in derselben Datenbank zu speichern: Eine Konvention besteht darin, dass ein Attribut vom Typ type verwendet wird, um den Objekttyp zu bezeichnen. Diese Option ist hilfreich, wenn Sie Abfragen ausführen müssen, die mehrere Objekttypen zurückgeben, oder wenn eine Datenbank an eine andere Position repliziert werden muss. Ansonsten eignen sich andere Datenbanken, wie users, orders und products besser, da bei diesem Ansatz jeder Objekttyp über für ihn spezifische sekundäre Indizes verfügt.

Wenn Sie Arrays von Objekten in einem Dokument speichern, sollten Sie überlegen, ob die Arrayelemente wirklich ein eigenes Dokument bilden müssen. Beispielsweise müssen ein Produkt und jede Produktbewertung jeweils in separaten Dokumenten gespeichert werden, ein Benutzer und die einzelnen Bestellungen dieses Benutzers müssen jedoch ihr eigenes Dokument haben.

Wenn Sie über ein stetig wachsendes Dataset verfügen, möchten Sie wahrscheinlich keine Daten in einer einzigen, ständig wachsenden Datenbank speichern. Die Daten sollten idealerweise in Datenbanken mit Timebox gespeichert werden, bei denen ältere Daten archiviert und sauber gelöscht werden können. Beim Löschen eines IBM Cloudant-Dokuments bleibt ein Tombstone-Dokument (eine Markierung für ein gelöschtes Objekt) zurück; setzen Sie daher bei der Wiederherstellung von Plattenspeicherplatz nicht auf das Löschen von Dokumenten. Stattdessen sollten ganze Datenbanken gelöscht werden.

JSON bietet keine native Möglichkeit, Datumsangaben oder Zeitmarken zu speichern. Wählen Sie Ihr Datumsformat sorgfältig aus, wenn Sie es später abfragen möchten.

Die maximale Dokumentgröße beträgt 1 MB, aber Dokumente sollten viel kleiner als diese Größe sein, in der Regel einige KB.

Weitere Informationen finden Sie in den folgenden Blogbeiträgen:

Optimale Nutzung des Primärindex

IBM Cloudant verfügt über einen Primärindex für das Attribut _id des Dokuments. Mit diesem Index können Dokumente anhand der _id (GET /db/id) oder eines Bereichs von _ids (GET /db/_all_docs?startkey="a"&endkey="z") abgerufen werden. Indem Daten im Primärschlüssel gespeichert werden und sichergestellt wird, dass jede _id eindeutig ist, können mit dem Primärindex Dokumente und Bereiche von Dokumenten ohne eine sekundäre Indexierung abgerufen werden. Nachfolgend sind einige Ideen hierzu aufgeführt:

  • Wenn Sie in Ihrem Objekt einen eindeutigen Wert haben, der sich für eine Abfrage eignen würde, verwenden Sie diesen als Ihr _id-Feld. Beispiel: bob.smith@gmail.com, isbn9780241265543 oder oakland,ca.
  • Wenn Ihre Objekte über eine Hierarchie verfügen, modellieren Sie diese in Ihrer ID (_id): usa:ca:oakland oder books:fiction:9780241265543. Die Hierarchie geht von der größten bis kleinsten Hierarchie aus, sodass Sie den Primärindex verwenden können, um alle Städte in usa oder *alle Städte in usa:ca*ohne sekundäre Indexierung zu suchen.
  • Wenn Sie Zeitreihendaten speichern, sortiert die Codierungszeit am Anfang Ihrer _id den Primärindex nach Zeit. Beispiel: 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ.
  • Partitionierte Datenbanken fassen Dokumente in Gruppen zusammen, die einen Partitionsschlüssel gemeinsam nutzen. Ein Partitionsschlüssel muss viele Werte haben und darf keine Hot-Spots enthalten, um zu vermeiden, dass ein großer Teil des Datenverkehrs der Anwendung an einige wenige Partitionen geleitet wird.

Weitere Informationen finden Sie in den folgenden Blogbeiträgen:

Abfragen und sekundäre Indizes

Mit IBM Cloudant können Abfragen für eine einzelne Datenbank ausgeführt werden, die ein Array mit übereinstimmenden Dokumenten und ein Lesezeichen zurückgeben, wodurch der Zugriff auf den nächsten Block von Suchergebnissen ermöglicht wird. Das Erreichen einer besseren Abfrageleistung hängt davon ab, ob Ihre Abfragen durch geeignete sekundäre Indizes unterstützt werden. Ein Index ermöglicht es der Datenbank, eine Abfrage zu beantworten, ohne jedes Dokument in der Datenbank durchsuchen zu müssen, was zu einer wesentlich schnelleren Leistung führt.

Nachfolgend finden Sie einige hilfreiche Tipps:

  • Es ist manchmal schwierig, die Leistung Ihrer Abfragen zu bewerten; erst wenn Ihr Dataset groß genug ist, werden langsame Operationen messbar. Generieren Sie genügend realistische Daten, damit Sie Ihre Indexierungs- und Abfrageleistung testen können, bevor Sie in die Produktionsumgebung wechseln.
  • IBM Cloudant kann ohne einen Index Daten an Sie zurückgeben, aus denen Sie jedoch nie Rückschlüsse für Produktionsworkloads ziehen dürfen. Wenn Ihre Ergebnismenge eine Warnung darüber enthält, dass kein entsprechender Index gefunden wurde und Sie zur Optimierung der Abfragezeit einen Index erstellen sollten (No matching index found. Create an index to optimize query time,), müssen Sie Ihre Strategie für die Indexierung überdenken. Verwenden Sie das Feature explain, um zu sehen, welcher Index für eine Abfrage ausgewählt wird.
  • Bei mehreren Objekttypen in derselben Datenbank können viele Anwendungsfälle durch ein paar Indizes für festgelegte Attribute bedient werden. Weitere Informationen finden Sie unter Optimale Indexierung in IBM Cloudant.
  • Geben Sie Ihren Indizes aussagekräftige Namen und geben Sie den Indexnamen zur Abfragezeit an, sodass es offensichtlich ist, welcher Index welcher Abfrage Ihrer Anwendung entspricht.

Weitere Informationen finden Sie in den folgenden Blogbeiträgen: