IBM Cloud Docs
Learning Center

Learning Center

Das IBM® Cloudant® for IBM Cloud® Learning Center bietet eine Videoserie an, die Ihnen bei der Verwendung von IBM Cloudant hilft. Die Videos beginnen mit den Grundlagen von IBM Cloudant. Die Videos führen Sie dann durch die Dokumentstruktur, die API, die Indexierung und die Abfrage und enthalten einen Abschnitt Under the Hood, in dem die Architektur hervorgehoben wird, die den Service unterstützt.

Sie können die Wiedergabeliste verwenden, um die Kurse durchzugehen, oder direkt zum Thema Ihrer Wahl navigieren.

Einführung in das IBM Cloudant-Video

Informieren Sie sich über die 17-teilige Videoserie IBM Cloudant, die einen Überblick über die IBM Cloudant Datenbank als Service bietet.

Einführung in das Script zum IBM Cloudant-Video

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 1 – Was ist IBM Cloudant?

IBM Cloudant ist eine Datenbank, die als Service in der IBM Cloud®ausgeführt wird. Der Zweck besteht darin, die Daten Ihrer Anwendung sicher zu speichern und es Ihnen zu ermöglichen, sie schnell und effizient abzurufen. Die Schlüsselfunktionen von IBM Cloudant werden in der folgenden Liste angezeigt:

Datenbank
Speichert Daten und ruft diese ab. Genauer gesagt handelt es sich um einen JSON-Dokumentspeicher. JSON (JavaScript Object Notation) wird zum Darstellen einfacher Objekte in einem universellen Dateiformat verwendet.
"Dokument"
Die Einheit des Speichers in IBM Cloudant. Dokumente werden in ihrer Gesamtheit hinzugefügt, aktualisiert und gelöscht.
HTTP-API
Jeder IBM Cloudant Vorgang kann über HTTPS ausgeführt werden. HTTP ist das Protokoll, auf dem das World Wide Web läuft und IBM Cloudant ist eine Datenbank, die für das Web erstellt wurde. Die meisten Datenbanken sind in einem privaten Netz verborgen und nur für eine Handvoll Maschinen zugänglich. IBM Cloudant befindet sich (hauptsächlich) im öffentlichen Internet, wo er von jedem mit einer Internetverbindung (und der entsprechenden Berechtigung) aufgerufen werden kann.

IBM Cloudant wurde nicht vollständig von IBM geschrieben. Die Basis ist Apache CouchDB, ein Open-Source-Projekt der Apache Foundation. IBM Cloudant beschäftigt eine Reihe von CouchDB-Mitwirkenden, aber nach den Regeln von Apache können sie seine Entwicklung nicht monopolisieren.

Vieles von dem, was Sie in diesem Kurs sehen, gilt in gleichem Maße für Apache CouchDB und IBM Cloudant. Die APIs sind zu 99 % identisch – ich weise darauf hin, wenn es Abweichungen gibt.

IBM Cloudant kann man sich als "as-a-service" ausgeführtes CouchDB vorstellen. IBM Cloudant-Services lassen sich einfach implementieren und werden rund um die Uhr von IBM Ingenieuren verwaltet. Der Dienst muss keine Software installieren, keine Server verwalten und keine Konfiguration verstehen. Benutzer müssen für die Verwendung und Verwaltung keine CouchDB-Experten sein.

Sie können sicher sein, dass Ihre Datenebene nicht von einer bestimmten Plattform, Cloud oder einem bestimmten Anbieter abhängig ist, da IBM Cloudant auf wirklich offenen Open-Source-Grundlagen erstellt wird. IBM Cloudant kann zusammen mit CouchDB verwendet werden, um Hybridanwendungen zu erstellen, die Daten über die Replikation gemeinsam nutzen, wie zu sehen ist.

Später im Kurs sehen wir unter der Haube nach, um zu verstehen, wie IBM Cloudant funktioniert, aber zunächst behandeln wir IBM Cloudant als "Funktionseinheit".

Cloudant basiert also auf Apache CouchDB, einem Open-Source-Projekt. Es speichert JSON-Dokumente. Da für den Zugriff eine HTTP-API verwendet wird, kann von jeder Einheit im Internet darauf zugegriffen werden, von der HTTP verwendet wird: Anwendungscode, Web-Browser, IoT-Gerät oder Mobiltelefon. IBM Cloudant ist ein hoch verfügbarer verwalteter Service, der den Betrieb auch bei mehreren Hardwarefehlern aufrechterhält.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt trägt den Titel Das Dokument.

Video 'Das Dokument'

Hier erfahren Sie mehr zur Funktionsweise von IBM Cloudant-Datenbanken und -Dokumenten.

Script zum Video 'Das Dokument'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dieses Video ist Teil 2 – * IBM Cloudant*.

Im vorherigen Abschnitt haben wir gesehen, dass IBM Cloudant ein JSON-Dokumentspeicher ist. Betrachten wir genauer, was dies in der Praxis bedeutet und wo die Unterschiede zu anderen Datenbanktypen liegen.

Die meisten Datenbanken speichern ihre Daten in Objektgruppen, die als Tabellen bezeichnet werden, wobei jede Dateneinheit eine Zeile mit jeweils identischen, festen Spalten ist. Das Schema jeder Tabelle ist vordefiniert: eine Liste mit Spalten mit ihrem Namen, Datumstyp, Wertbeschränkungen und Beziehungen zu anderen Tabellen, die sorgfältig definiert sind. Jeder neue Datensatz stellt eine Zeile in einer Tabelle dar.

IBM Cloudant ist anders!

Ein IBM Cloudant Service umfasst Sammlungen, die als Datenbanken (anstelle von Tabellen) bezeichnet werden, die jeweils eine beliebige Anzahl von Dokumenten enthalten.

Das Beispiel dieser Folie zeigt dieselben Daten, die in einer herkömmlichen tabellarischen Datenbank ausgedrückt werden, und wie dieselben Daten in IBM Cloudant als JSON-Dokumente gespeichert würden.

Wenn Sie also relationale Datenbanken gewohnt sind: in IBM Cloudant sind Tabellen "Datenbanken" und Zeilen sind "Dokumente".

Ein IBM Cloudant Dokument muss ein JSON-Objekt sein, das mit geschweiften Klammern beginnt und endet und eine Reihe von Schlüsselwertattributen enthält.

JSON-Objekte müssen kleiner als 1 Megabyte sein und enthalten eine beliebige Anzahl an Zeichenfolgen, Zahlen, booleschen Werten, Arrays und Objekten. Objekte können in Objekten bis zu einer beliebigen Verschachtelungstiefe verschachtelt werden.

Die verwendeten Schlüssel können so kurz oder ausführlich sein, wie Sie möchten.

Die folgende Liste enthält einige einfache Beispieldokumente, die zeigen, wie jeder Datentyp verwendet wird.

  • Das erste Beispiel ist ein Personenobjekt, in dem Zeichenfolgen, boolesche Werte und ein Array aus Tags gespeichert sind.
  • Das zweite Beispiel zeigt kurze Attributnamen, die bei der Speicherung gespeichert werden sollen, und stellt ein Webereignis dar, wie z. B. auf eine Website klicken.
  • Das letzte Beispiel zeigt, wie das Dokument selbst Themen enthalten kann.

Eine Anmerkung zu Datumsangaben. JSON hat keinen nativen Datumstyp, so dass Datumsangaben normalerweise in 30-Oktober-2018 oder ähnlichen Formaten gespeichert werden. Mit Datumsangaben beschäftigen wir uns zu einem späteren Zeitpunkt.

Nun, zu Ihrer ersten praktischen Übung, greifen Sie auf www.ibm.com/cloud zu. Registrieren Sie ein Konto bei der IBM Cloud, wenn Sie nicht bereits über eines verfügen.

Sobald Sie registriert sind, können Sie auf Services klicken, nach der Datenbank Cloudant suchen und einen neuen Service bereitstellen.

Der Service IBM Cloudant Lite stellt einen kostenlosen Plan bereit, mit dem Benutzer IBM Cloudant in einer begrenzten Kapazität während der Entwicklung ausprobieren können. Sein größerer Bruder, der Standard Plan, ist ein kostenpflichtiger Service, bei dem Sie die Lesevorgänge, Schreibvorgänge sowie Abfragen pro Sekunde für Ihre Anwendung angeben und die entsprechende Kapazität für Sie reserviert wird. Sie zahlen für die von Ihnen angegebene Kapazität und die Datenspeichernutzung.

Der Lite-Plan funktioniert ähnlich. Dabei wird nur eine geringe Kapazität bereitgestellt und eine feste Speichergröße, es ist aber für das Testen des IBM Cloudant Service gut geeignet.

IBM Cloudant wird oft als eine "schemalose" Datenbank bezeichnet – aber wir müssen bei dieser Begriffsdefinition vorsichtig sein.

Es stimmt, dass Sie Ihr Schema (Feldnamen, Typen, Einschränkungen und Beziehungen) nicht im Voraus in IBM Cloudant definieren müssen. Sie können einfach ein JSON-Dokument mit eigenem Design in eine Datenbank schreiben.

Entwickler schätzen diese Flexibilität, weil sie ihre Daten in ihrem Code entwerfen können, sie in JSON umwandeln und in die Datenbank schreiben können.

Es ist immer noch wichtig, über die Form Ihrer Daten nachzudenken, insbesondere in Bezug auf die Art und Weise, wie Sie sie abfragen und indexieren, wie wir später sehen.

Somit ist also ein Datendesign erforderlich, genau genommen ist es für die Datenbank aber nicht nötig, das Schema der Daten zu kennen.

Angenommen, es soll eine Datenbank der US-Präsidenten erstellt werden. Wir können einfach unser "Modell" der Daten in unserer App ausarbeiten, es in JSON umdrehen und in die Datenbank schreiben. In diesem Fall verwenden wir eine gemeinsame CouchDB-Konvention: Das Feld "type" gibt den Datentyp des Dokuments an.

Wenn wir zu einem späteren Zeitpunkt entscheiden, dass wir mehr Daten zu unserem "Schema" hinzufügen wollen, können wir einfach ein neues Objekt in die Datenbank schreiben, ohne dass es Beschwerden von IBM Cloudantgibt. Wir könnten beschließen, das Objekt "Adresse" nur zu den folgenden Dokumenten hinzuzufügen:

  • Dokumente, die von jetzt an erstellt werden.
  • Nur Dokumente, für die wir Adressen haben.

Mit anderen Worten können in Dokumenten desselben Typs Felder vorhanden sein oder fehlen.

Das Schema Ihrer Datenbank kann sich im Laufe der Zeit entwickeln, um den Anforderungen Ihrer Anwendung gerecht zu werden. Sie müssen (unbedingt) nicht die Datenbank über das Schema ändern-neue Dokumente in das neue Format schreiben.

Wir können sogar mehrere "Typen" von Dokumente in der selben Datenbank speichern. In diesem Fall befinden sich Personen, Bücher und Orte in derselben Datenbank. Wir wissen, was wegen des Feldes "type" (dieses Feld ist eine Konvention und nicht etwas, das etwas zu IBM Cloudantbedeutet).

Eine Alternative zu dieser Konfiguration besteht darin, drei Datenbanken Personen, Bücher und Bereiche zu verwenden und jeden Datentyp in einer eigenen Datenbank zu halten. Beide Ansätze sind in Ordnung. Sie können auswählen, dass mehrere Typen zusammen in derselben Datenbank vorhanden sind, wenn Sie Abfragen für verschiedene Typen ausführen müssen oder wenn Sie alle Datentypen gemeinsam replizieren müssen. Andernfalls könnte der separate Datenbankansatz besser sein.

Zusammenfassend lässt sich sagen, dass IBM Cloudant zwar "schemaless" ist, Sie jedoch nicht von der Notwendigkeit, detaillierte Daten zu entwerfen, um die beste Leistung zu erhalten, freigesprochen werden.

Diese Tipps sind besonders relevant, wenn Sie eine Erfahrung mit einer relationalen Datenbank haben.

  • Vermeiden Sie das Denken in Joins-ein IBM Cloudant Dokument muss alles enthalten, was Sie für dieses Objekt benötigen, damit es in einem API-Aufruf abgerufen werden kann.
  • In einem JSON-Speicher gibt es keine Normalisierung, einige wiederholte Werte können toleriert werden, wenn dadurch der Datenabruf effizienter wird.
  • Obwohl wir einen Grenzwert von 1 MB für die Dokumentgröße haben, müssen Ihre Dokumente sehr viel kleiner sein-ein paar KB ist typisch.
  • Wenn Ihre Anwendung ein "Schreib-only" * -Design-Muster umfassen kann, wo Daten nur je einer Datenbank hinzugefügt werden, dann kann es Ihr Leben einfacher machen. Sie müssen auf jeden Fall Muster vermeiden, die sich darauf verlassen, dass dasselbe Dokument in einem kleinen Zeitfenster immer und immer aktualisiert wird.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Die Dokument-ID.

Video 'Die Dokument-_id'

Hier erfahren Sie, wie _ids in IBM Cloudantarbeiten, wie sie sich von relationalen Datenbanken unterscheiden und wie Sie Ihre eigene _iddefinieren können.

Das _id video script

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dieses Video ist Teil 3- Das Dokument _id.

Im vorherigen Abschnitt haben wir gesehen, wie Daten in IBM Cloudant Dokumenten mit Flexibilität in der Art und Weise gespeichert werden, wie Ihre Anwendung JSON-Objekte in IBM Cloudant Datenbanken speichert. Allerdings gibt es ein paar harte und schnelle Regeln.

Eine Regel ist, dass jedes Dokument eine eindeutige Kennung mit dem Namen _identhalten muss, die eine Zeichenfolge ist. Zwei Dokumente in derselben Datenbank können dasselbe _id-Feld haben. In anderen Datenbanken geben Sie an, welche Spalte die eindeutige Kennung ist, aber in IBM Cloudantist es immer _id und kann nicht geändert werden.

Im Gegensatz zu relationalen Datenbanken verfügt IBM Cloudant nicht über "automatisch inkrementierende IDs", d. h. ein ID-Feld, das bei 1 beginnt und für jedes hinzugefügte Dokument inkrementiert wird.

Das Feld _id für IBM Cloudant ist eine der folgenden Zeichenfolgen:

  • Eine von IBM Cloudantgenerierte 32-stellige Zeichenfolge. Die ID ist eine bedeutungslose Folge von Zahlen und Buchstaben, die garantiert einzigartig sind.
  • Eine von Ihnen definierte Zeichenkette (wenn Sie etwas Unikes über Ihre Daten wissen).

In den folgenden Beispielen wird gezeigt, wie das eigene Dokument _idbereitgestellt wird:

Mit ihr, um etwas zu speichern, was Sie wissen, ist einzigartig, das ist, die E-Mail-Adresse eines Benutzers. Vom Registrierungsmechanismus kann die Richtlinie durchgesetzt werden, dass jeder Benutzer nur über eine E-Mail-Adresse verfügen darf. Einige Benutzer wählen den Dokumenttyp in der _id, z. B. user:56, book:55, aus. Das letzte Beispiel zeigt mit einer 32-stelligen Zeichenfolge (generiert in Ihrer App), die so konzipiert ist, dass sie in der ungefähren Datums-und Zeitreihenfolge sortiert wird. Diese Methode macht es einfach, die neuesten Dokumente aus der Datenbank abzurufen, ohne einen sekundären Index zu verwenden.

IBM Cloudant nimmt das Dokument _idss und speichert sie in einem Index (wie die Inhaltsseite des Buches). Dieser Primärindex befindet sich in der Reihenfolge _id und wird verwendet, damit IBM Cloudant Dokumente mit ihrer _id abgerufen werden können-also wie ein Keystore mit Schlüsselwerten.

Durch sorgfältiges Design des Felds _id können Sie den Primärindex verwenden, um Daten zusammen zu halten, die im primären Index sinnvoll sind. Diese Methode macht es schneller, diese Daten später abzurufen. Wir haben gesehen, dass die Verwendung von zeitsortierbaren _idss bedeutet, dass Daten in der ungefähren Datums-und Zeitreihenfolge abgerufen werden können.

Wir sehen ein Beispiel später, wenn es um das Abrufen von Bereichen von Dokumenten-IDs geht.

Abschließend muss jedes Dokument über ein Feld _id verfügen, das in der Datenbank eindeutig ist. Sie kann von IBM Cloudantautomatisch generiert werden oder von Ihrer Anwendung bereitgestellt werden. In diesem Fall müssen Sie die Verantwortung für die Eindeutigkeit des Felds _id übernehmen.

Das Feld _id ist die Basis für den Primärindex der Datenbank, der, wie wir später sehen, für Suchvorgänge im Schlüsselwert und für Bereichsabfragen verwendet werden kann.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Das Token 'rev'.

Video 'Das Token 'rev''

Hier erfahren Sie, wie von IBM Cloudant ein Revisionstoken erstellt wird, wenn Sie ein Dokument hinzufügen, bearbeiten oder löschen.

Script zum Video 'Das Token 'rev''

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video für Teil 4- Das rev-Token.

Die zweite grundlegende IBM Cloudant Regel lautet, dass jeder Dokumentüberarbeitung ein eigenes, eindeutiges Revisionstoken zugeordnet wird. Dies wird nachfolgend erklärt.

Wenn Sie ein Dokument, das die API verwendet, hinzufügen, aktualisieren oder löschen, müssen Sie nie ein Revisions-Token generieren-eine Token-Eins wird für Sie erstellt.

Ein Revisionstoken besteht aus zwei Teilen:

Eine Zahl 1, 2, 3 usw. und ein kryptographischer Hashwert des Dokumentenkörpers. (Für Uneingeweihte: ein Hashwert ist ein digitaler "Fingerabdruck" bestimmter Daten. Wenn sich die Daten ändern, ändert sich auch der Fingerabdruck. Es sind keine 2 Fingerabdrücke identisch, d. h. es können keine 2 Dokumente mit unterschiedlichem Inhalt denselben Hashwert haben.)

Wie Sie dem Beispiel auf dem Bildschirm entnehmen können, verfügt unser Dokument über ein Revisionszeichen (der Schlüssel beginnt mit _rev ), das mit 1 beginnt, gefolgt von einem Bindestrich. Dies deutet darauf hin, dass diese Revision die erste Revision des Dokuments ist. Die Ziffern, die mit 04aa8... beginnen, sind der kryptografische Hash des Dokuments.

Wenn wir den Lebenszyklus eines Dokuments verfolgen, beginnt er mit revision 1. Wenn es später geändert wird, ist dies revision 2 usw. Bei jeder inkrementierenden Revisionsnummer ändert sich der Hashwert, da der Inhalt des Dokuments ebenfalls geändert wird.

Es ist möglich, dass es für ein Dokument mehrere Revisionen mit derselben Nummer gibt, In diesem Fall ist revision 3s zweimal vorhanden. Dieses Szenario wird als Konflikt bezeichnet und ist unter bestimmten Umständen "normal". Den Grund erfahren wir später im Kurs, aber bis auf Weiteres können wir davon ausgehen, dass die Revisionsnummer sich mit jeder Aktualisierung eines Dokuments erhöht.

Folgen wir nun dem Lebenszyklus eines IBM Cloudant-Dokuments als Beispiel:

Wenn ein neues Dokument erstellt wird (unabhängig davon, ob mit einer automatisch generierten _id oder einer vom Benutzer bereitgestellten _id), wird ihm revision 1 zugeordnet. Sie erhalten das Token in der Antwort auf Ihre API-Anforderung. Normalerweise können Sie das rev verwerfen (es sei denn, Sie beabsichtigen, das Dokument bald zu ändern).

Wenn wir ein Dokument ändern, dessen _rev bei revision 1liegt, wird das Dokument gespeichert und es wird ein revision 2 -Token generiert und in der API-Antwort an Sie zurückgegeben. Beachten Sie, dass wir den Namen in dem Dokument von Liz zu Elizabeth ändern.

Soweit ist alles noch ganz einfach.

Wenn das Dokument später gelöscht wird, wird eine revision 3 erstellt.

Im Gegensatz zu fast jeder anderen Datenbank behält IBM Cloudant einen Verweis auf gelöschte Dokumente bei. Ein Löschvorgang ist nur eine andere Dokumentüberarbeitung-eine spezielle Version, bei der _deleted: true den Dokumenthauptteil ersetzt.

Der aktuelle Revisionsverlauf des Dokuments wird also aufbewahrt (die Baumstruktur der Revisionen - wie Sie sich erinnern, kann eine Revisionsnummer mehrfach vorhanden sein).

Sie können IBM Cloudant' s revision tree as a version control system to retrieve or roll back in einer älteren Version nicht verwenden. Sobald eine Revision abgelöst wird, wird der Dokumenttext der älteren Revision gelöscht und der Speicherplatz wird in einem Prozess namens "Komprimierung" wiederhergestellt. Die Komprimierung erfolgt automatisch in IBM Cloudant, so dass es nicht sicher ist, dass alte Revisionen abgerufen werden können.

Um eine Zusammenfassung zu erstellen, werden Revisionstoken von der Datenbank beim Hinzufügen, Bearbeiten und Löschen generiert. (Sie müssen niemals Ihre eigenen Revisionsmarken erstellen.) Im Allgemeinen wird die Revisionsnummer jeweils um eins erhöht, aber es sind komplexere Szenarien möglich (wir decken diese Szenarien später ab). Ältere Dokumenthauptteile werden gelöscht oder komprimiert (verlassen Sie sich nicht darauf, dass sie später wiederhergestellt werden können). Alle IBM Cloudant Operationen, die ein Dokument ändern, benötigen das Dokument _id und dessen _rev (dieses Szenario unterscheidet sich von den meisten Datenbanken).

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Authentifizierung.

Video 'Authentifizierung'

Hier erfahren Sie, wie die traditionelle Authentifizierung und die IAM-Authentifizierung funktionieren. Außerdem wird erklärt, wie von IBM Cloudant Berechtigungsnachweise generiert und wie die Authentifizierung von den drei offiziellen IBM Cloudant-Bibliotheken abgewickelt wird.

Script zum Video 'Authentifizierung'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 5 – Authentifizierung.

Wir haben vorhin festgestellt, dass IBM Cloudant ein webbasierter Dienst im öffentlichen Internet ist. Wie können wir sicher sein, dass unsere Daten geschützt sind und nur von unserem Code auf sie zugegriffen werden kann? In diesem Szenario wird die Authentifizierung ausgeführt.

IBM Cloudant unterstützt zwei Typen von Authentifizierung.

Bei der Legacy-Authentifizierung werden bei jeder Anfrage, die HTTP verwendet, ein Benutzername oder API-Schlüssel und ein Passwort bereitgestellt oder gegen ein Cookie ausgetauscht, das einen einmaligen Sitzungs-API-Aufruf verwendet. Ein Sitzungscookie wird regelmäßig zyklisch getaktet, so dass Ihr Clientcode das aktualisierte Cookie erfassen und für nachfolgende Anforderungen speichern muss. Bei der IAM-Authentifizierung handelt es sich um das Zugriffsverwaltungssystem, das alle IBM Cloud Services untermauert. Um sich mit IAM zu authentifizieren, benötigen Sie einen IAM-API-Schlüssel und den Hostnamen IBM Cloudant. Der API-Schlüssel wird durch Verwendung der IAM-API für ein Trägertoken ausgetauscht und das Trägertoken wird an IBM Cloudant mit jeder Anforderung übergeben. Das Bearer-Token dauert nur eine Stunde, muss also regelmäßig mit dem IAM-Service erneuert werden. Wenn IBM Cloudant bereitgestellt wird, können Sie entweder nur IAM-Anmeldeinformationen oder sowohl IAM- als auch Legacy-Anmeldeinformationen generieren – Sie entscheiden.

Wie werden Berechtigungsnachweise generiert?

Klicken Sie im IBM Cloud Dashboard unter Ihrem IBM Cloudant Service auf der Registerkarte Service Credentials auf New Credential(Neuer Berechtigungsnachweis). Es wird ein JSON-Dokument erstellt, das den IAM-Schlüssel, den Benutzernamen und das Passwort für die Basisauthentifizierung sowie IBM Cloudant enthält.

Sehen Sie sich die Beispielgruppe der Berechtigungsnachweise an:

Für IAM benötigen Sie den apikey und den Host. Für Legacy oder Basic-Auth oder beide benötigen Sie URL (die den Benutzernamen und das Passwort enthält, die in URL eingebettet sind).

IBM Cloudant hat drei offizielle Client-Bibliotheken: Java™, Node.js und Python.

Von allen drei Bibliotheken wird die Authentifizierung automatisch abgewickelt. Sie brauchen sich nicht darum kümmern, wie der API-Schlüssel gegen ein Sitzungstoken ausgetauscht wird oder wie die IAM-Authentifizierung funktioniert - die Authentifizierung wird automatisch durchgeführt.

Wenn wir über die API in der Dokumentation diskutieren, verwenden wir Basic Auth als Bequemlichkeit. Wir empfehlen jedoch, dass Sie die IAM-Authentifizierung verwenden, wenn dies möglich ist, da sie eine bessere Integration mit der IBM Cloud -Plattform und den differenzierteren Berechtigungen ermöglicht.

Jetzt ist der Zeitpunkt für die nächste praktische Übung gekommen.

Melden Sie sich IBM Cloud an und suchen Sie IBM Cloudant, den wir beim letzten Mal erstellt haben. Klicken Sie in der Registerkarte Serviceberechtigungsnachweise auf die Schaltfläche Neuer Berechtigungsnachweis, um einen Satz Berechtigungsnachweise für die Variante aus IAM-Authentifizierung und traditioneller Authentifizierung (IAM+Legacy) zu generieren. Notieren Sie sich die zurückgegebene JSON-Datei – wir benötigen sie für die nächste Übung.

Rufen Sie anschließend die URL auf, die im JSON-Code mit den Berechtigungsnachweisen angegeben ist - Was wird angezeigt?

Zum Zusammenfassen werden Berechtigungsnachweise aus dem IBM Cloud -Dashboard generiert. Sie können entweder die IAM-Authentifizierung oder die Kombination aus IAM-Authentifizierung und traditionellen Berechtigungsnachweisen verwenden. Bei beiden Authentifizierungsmethoden werden die Berechtigungsnachweise gegen ein zeitlich begrenzt gültiges Token (zur Authentifizierung) ausgetauscht - anschließend wird das Token laufend aktualisiert, wenn Sie den Service verwenden. Die offiziellen Bibliotheken bearbeiten alle diese Aufgaben für Sie.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt trägt den Titel The Dashboard.

Video 'Das Dashboard'

Hier erfahren Sie mehr über das IBM Cloudant-Dashboard und was es bietet; außerdem werden die Grundlagen seiner Verwendung erläutert.

Script zum Video 'Das Dashboard'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dieses Video ist Teil 6- Das Dashboard.

Die einfachste Methode, um gestartet zu werden, Datenbanken zu erstellen und Dokumente hinzuzufügen, ist die Verwendung von IBM Cloudant Dashboard.

Das IBM Cloudant Dashboard ist eine Web-App, die in den Service integriert wird. Damit können grundlegende Datenmanipulationen über eine grafische Benutzerschnittstelle ausgeführt werden: Datenbanken können erstellt und gelöscht werden. Dokumente, die hinzugefügt, aktualisiert, gelöscht und Replikationsjobs verwaltet werden. Es ist auch ein praktischer Ort, um einmalige Abfragen durchzuführen und Sekundärindizes einzurichten (wie wir später sehen werden).

Außerdem bietet es auch einfache Überwachungstools, die eine Visualisierung der Anforderungsraten möglich machen.

Es ist wichtig zu beachten, dass jede Aufgabe, die im IBM Cloudant Dashboard erreicht werden kann, auch mit der IBM Cloudant HTTP-API möglich ist. In der Tat stellt das IBM Cloudant Dashboard einfach die Standard-API-Aufrufe selbst dar.

Um ein IBM Cloudant Service-Dashboard zu öffnen, melden Sie sich bei IBM Cloudan, suchen Sie Ihren IBM Cloudant Service und klicken Sie auf ** IBM Cloudant Dashboard starten** . Daraufhin wird ein neues Fenster geöffnet, in dem Sie sich in Ihrem IBM Cloudant Dashboard anmelden.

Wenn Sie das Dashboard-Fenster für eine bestimmte Zeit nicht mehr besucht haben, finden Sie sich selbst abgemeldet (zu Sicherheitszwecken) und müssen erneut auf Starten klicken.

Das Dashboard verfügt über eine Reihe von Registerkarten. Auf der Standardregisterkarte Datenbankenwerden die Datenbanken aufgelistet, die Sie in Gruppen von 20 erstellt haben. Jede Datenbank wird mit der Anzahl der darin gespeicherten Dokumente und dem belegten Speicherplatz angezeigt. Klicken Sie auf einen Datenbanknamen, um den Inhalt zu untersuchen.

Wenn Sie eine Datenbank erstellen möchten, klicken Sie auf Datenbank erstellen und geben Sie den Namen der zu erstellenden Datenbank an.

Sie verfügen jetzt über eine leere Datenbank. Die Dokumente der Datenbank werden hier in der ID-Reihenfolge aufgelistet. Da diese Datenbank jedoch neu ist, sind keine Dokumente vorhanden. Wenn Sie ein Dokument hinzufügen möchten, klicken Sie auf Dokument erstellen.

Das IBM Cloudant Dashboard erstellt ein Vorlagendokument für Sie mit einer vorab generierten _id. Füllen Sie den Rest der Attribute selbst aus, um das JSON-Dokument abzuschließen, und klicken Sie auf Dokument erstellen , um das Dokument zu speichern.

Jetzt ist die Zeit für eine weitere praktische Übung gekommen. Erstellen Sie eine Datenbank mit dem Namen booksund erstellen Sie in dieser Datenbank drei oder mehr Dokumente mit Feldern: Titel, Autor, Datum, Publisher und ISBN-jeweils für ein Buch Ihrer Wahl.

Bearbeiten Sie nach der Erstellung eines der Dokumente und ändern Sie das Veröffentlichungsdatum.

Löschen Sie anschließend eines der Dokumente.

Zusammenfassend lässt sich sagen, dass das IBM Cloudant Dashboard eine Web-App ist, die in den Service IBM Cloudant integriert ist und Teil des Open-Source-Angebots von CouchDB ist. Es wird verwendet, um Datenbanken, Dokumente, Indizes, Abfragen und Replikationsjobs zu verwalten. Es kann auch zum Überwachen des Servicedurchsatzes verwendet werden. Das Dashboard ist einfach ein API-Client-alles, was mit dem Dashboard erreicht werden kann, kann von Ihnen über die HTTP-API geschrieben werden.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Grundlagen der HTTP-API.

Video 'Grundlagen der HTTP-API'

Hier erfahren Sie, wie Sie die Befehlszeile verwenden, um HTTP-Anforderungen zu erstellen und Dokumente hinzuzufügen, zu bearbeiten und zu löschen.

Script zum Video 'Grundlagen der HTTP-API'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 7- HTTP-API-Basics.

Im vorherigen Abschnitt haben wir das IBM Cloudant Dashboard, das eine Web-App ist, die HTTP-Aufrufe an IBM Cloudant' s API macht, gesehen. In diesem Schritt verwenden wir die Kommandozeile, um HTTP-Anforderungen zu erstellen und einige Dokumente von dort hinzuzufügen, zu bearbeiten und zu löschen.

Auch wenn Sie beabsichtigen, die fortgeschritteneren Clientbibliotheken zu verwenden, ist es wichtig, die HTTP-API von Grund auf zu verstehen.

Der Vorteil einer Datenbank, die über eine HTTP-API verfügt, ist, dass jedes Gerät im Internet Daten lesen und schreiben kann, wenn Sie es wollen. Eine besondere Software ist nicht erforderlich. Keine Treiber, die ein angepasstes Protokoll verwenden. Nur eine normale HTTP-Bibliothek. Zum Beispiel wird immer HTTP verwendet:

  • Web-Browser
  • Beliebige Programmiersprache
  • Tools, die Sie zum Schreiben von Scripts über die Befehlszeile verwenden können, z. B. 'curl'
  • Mobile Geräte

Wir werden die API lernen, indem wir curl verwenden, ein kostenloses, Open-Source-Befehlszeilentool, das HTTP-Anforderungen versenden kann. Auf den meisten Mac-Systemen und UNIX-ähnlichen Betriebssystemen ist curl bereits vorinstalliert. Wenn der Computer nicht auf Ihrem Computer vorhanden ist, klicken Sie auf Google curl und befolgen Sie die Installationsanweisungen.

Verwenden Sie curl zunächst zum Abrufen einer Webseite - der Homepage von Google.

  1. Geben Sie in einem Befehlszeilenterminal curl https://www.google.comein.

    Sie erhalten eine Seite von HTML in der Antwort.
    Wenn diese Methode funktioniert, dann wird curl installiert, und Sie können mit den nächsten Tasks fortfahren. Da wir die URL unseres IBM Cloudant-Dienstes nicht jedes Mal eingeben möchten, speichern wir die IBM Cloudant URL in einer Umgebungsvariable namens URL.

  2. Führen Sie den Befehl export URL aus, um eine Variable mit dem Namen URLzu erstellen, auf die wir später zugreifen können.

    export URL=https://username:password@host

  3. Erstellen Sie einen alias.

    alias acurl="curl -sgH 'Content-type: application/json'"

    Dieser alias ist eine Verknüpfung, die als acurl bezeichnet wird und die uns weitere Typisierungen erspart. Dieser acurl-Befehl ist ein Alias für curl, aber mit dem Header des Typs "JSON content" und einigen nützlichen Befehlszeilen-Switches.

  4. Testen Sie den alias , indem Sie acurl $URL/abrufen. Wir erhalten eine JSON-Rückseite von IBM Cloudantzurück.

    Sie haben Ihren ersten IBM Cloudant API-Aufruf abgeschlossen. Jetzt wird unser Aliasname acurl eingerichtet. Wir können mit der Erkundung der API beginnen. Wir beginnen mit dem Endpunkt _all_dbs , der eine Liste von Datenbanken zurückgibt.

  5. Geben Sie acurl $URL/_all_dbs ein, um ein Array von Datenbanken anzuzeigen.

Eine kurze Anmerkung zum Formatieren von JSON in der Befehlszeile. Wir können die Ausgabe des Befehls acurl an ein anderes Tool senden, das die Daten auf dem Terminal schön formatiert. Die folgenden Tools sind für Ihre Verwendung verfügbar:

  • Jq ist über URL auf der Seite verfügbar und ist mehr als nur ein JSON-Formatierer – er ermöglicht auch das Parsen, Abfragen und Bearbeiten von JSON.
  • python -m json.tool ist ein einfaches JSON-Formatierungsprogramm, wenn Python auf Ihrem Computer installiert ist.

Also: acurl $URL/_all_dbs | jq bedeutet Pipe the output of acurl into jq und was Sie sehen, ist eine schön formatierte, farbige Ausgabe.

Die IBM Cloudant API-Pfade sind hierarchisch mit der ersten Ebene, die Ihnen Informationen über den Service gibt, und dann sitzt jede Datenbank auf einer Ebene darunter.

Also gibt uns acurl $URL/books Informationen über die Buchdatenbank, die wir zuvor erstellt haben.

Sie sehen Informationen dazu, wie viele Dokumente es hat, wie viele gelöschte Dokumente und wie viel Plattenspeicherplatz sie belegt.

Vergessen Sie nicht, die Ausgabe an jq oder Python zu verwenden, um eine prettier-Ausgabe zu erhalten.

Wenn die in der Datenbank enthaltenen Dokumente angezeigt werden sollen, können wir den Endpunkt _all_docs verwenden.

Daher bedeutet acurl $URL/books/_all_docs , dass alle Dokumente aus der Buchdatenbank aus dem IBM Cloudant Service an der angegebenen URL abgerufen werden.

Die Ergebnisse dieses Befehls geben eine Liste mit den Werten _id und _rev für jedes Dokument zurück. Wenn auch die Dokumenthauptteile abgerufen werden sollen, fügen Sie ?include_docs=true Ihrem API-Aufruf hinzu.

Wenn ein einzelnes Dokument aus einer Datenbank abgerufen werden soll, befinden sich die Dokumente eine Ebene unterhalb der Datenbank in der Hierarchie der URL.

Also bedeutet acurl $URL/books/id "die Dokument-ID aus der Datenbank books aus dem IBM Cloudant Service an der angegebenen URL abrufen".

Beachten Sie die Hierarchie: Service, Datenbank und Dokument.

Bisher haben wir nur die GET -HTTP-Methode verwendet, bei der es sich um die Standardmethode für curl handelt und die Methode, die verwendet wird, wenn Sie eine URL in Ihren Web-Browser eingeben.

IBM Cloudant' s API verwendet häufig die HTTP-Methode als verb , um die Aktion zu beschreiben, die von der Datenbank gefragt wird: GET zum Abrufen von Daten.

Mit curl können wir die Methode angeben, die mit der Befehlszeilenoption -X verwendet werden soll.

Um also ein neues Dokument in unsere books-Datenbank zu schreiben, die die API verwendet, werden wir die POST-Methode verwenden, um ein Dokument als Hauptteil der HTTP-Anforderung zu maskieren.

acurl -X POST gibt an, dass wir die HTTP-Methode POST verwenden. -d gibt das Dokument an, das wir schreiben möchten, das als Hauptteil der Anforderung gesendet wird, und schließlich die URL, an die wir schreiben, $URL/books - die Buchdatenbank.

Alternativ dazu können wir die Methode PUT verwenden, wenn wir die ID des Dokuments angeben, das geschrieben wird. Die URL wird zu $URL/books/, gefolgt von der ID des Dokuments, in das geschrieben werden soll.

Beide Schreibmethoden liefern identische Antworten. OK: Um zu zeigen, dass die Übertragung erfolgreich war. ID, die als Dokument-ID geschrieben wurde, und rev ist das Revisionstoken, das von der Datenbank generiert wurde.

Zum Ändern eines Dokuments können wir die PUT-Methode verwenden, um den neuen Hauptteil in die URL zu schreiben, die auf die Dokument-ID verweist, die überschrieben werden soll. -d stellt den neuen Dokumenthauptteil bereit und die URL enthält nicht nur die Datenbank und die ID des Dokuments, sondern vor allem die Revision des Dokuments, das wir mutieren wollen.

Wenn wir den rev-Parameter vergessen und weglassen, erhalten wir eine Fehlerantwort.

HTTP-Antwortcodes zeigen, ob eine Anforderung erfolgreich ist oder nicht. Antworten in der 200-Reihe sind erfolgreich. Die Antworten im Bereich 400 sind Benutzerfehler (z. B. ungültige Parameter), und Antworten im Bereich 500 sind serverseitige Fehler. Darüber hinaus können Sie die vollständige HTTP-Anforderung und -Antwort anzeigen, indem Sie die Befehlszeilenoption -v auf curl/acurlangeben.

Auch die Aktualisierung von Dokumenten erfolgt in ihrer Gesamtheit oder gar nicht. Es gibt kein API-Konstrukt, um einen Teil eines Dokuments zu ändern. Es muss ein komplettes Dokument angegeben werden, um eine vorherige Revision zu überschreiben.

Um schließlich ein Dokument zu löschen, verwenden wir die DELETE-Methode, also -X DELETE. Wir richten die Anfrage an die URL, die den Datenbanknamen und das Dokument enthält, gelöscht zu werden, und kritisch, wir liefern auch die rev-die Revision des Dokuments zu löschen.

Wenn wir das Revisionstoken weglassen, wird ein Fehler zurückgegeben, und die Anforderung schlägt fehl.

Zusammenfassend können Sie die HTTP-API verstehen, um die Beziehung zwischen Ihrem Code und dem IBM Cloudant Service zu erfassen.

Die URLs sind hierarchisch: service/database/document oder service/database/endpoint.

Die HTTP-Methoden fungieren als verbs, von denen die Aktion definiert wird, die ausgeführt werden soll.

Alle Aktionen können durch einfache HTTP-API-Aufrufe, von der Befehlszeile oder von Ihrem Code ausgelöst werden und können so einfach geschrieben werden.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt wird als Bulk-APIbezeichnet.

Video 'Die Massendaten-API'

Hier erfahren Sie, wie Sie mit zwei API-Aufrufen alle grundlegenden IBM Cloudant-Operationen ausführen und eine solche Operation für mehrere Dokumente pro API-Aufruf ausführen können.

Script zum Video 'Die Massendaten-API'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 8- Die Massenzuweisungs-API.

Im vorherigen Teil haben wir gesehen, wie Dokumente einfach mit der IBM Cloudant HTTP-API hinzugefügt, aktualisiert und gelöscht werden konnten. In diesem Abschnitt sehen wir, wie zwei API-Aufrufe verwendet werden können, um alle grundlegenden IBM Cloudant Operationen zu erreichen. Der zusätzliche Vorteil, der in der Lage ist, auf mehr als ein Dokument pro API-Aufruf zu reagieren.

Der Endpunkt _all_docs wurde bereits diskutiert. Wir haben es verwendet, um eine Liste aller Dokumente in einer Datenbank zu holen, aber es hat auch andere Funktionen.

Der Schlüsselparameter kann verwendet werden, um ein einzelnes Dokument anzugeben, das abgerufen werden soll und das dem API-Aufruf GET /db/id entspricht. In ähnlicher Weise nimmt der Schlüssel-Parameter eine Reihe von Dokument-IDs an und gibt sie alle zurück. Die Parameter startkey und endkey rufen eine Schicht des Primärindex zwischen den angegebenen Grenzwerten ab. Wenn Sie include_docs=true hinzufügen, werden IBM Cloudant auch die Dokumentkörper zur Verfügung stellen. Und Grenzwert gibt an, wie viele Dokumente in einem API-Aufruf zurückgegeben werden sollen.

Der Endpunkt _bulk_docs ermöglicht mehrere Einfügungen, Aktualisierungen und Löschoperationen, die in einem API-Aufruf ausgeführt werden sollen. Sie erwartet ein Objekt, das ein docs-Array enthält-jedes Element dieses Arrays ist eine Operation, die für ein einzelnes Dokument ausgeführt werden soll. Der Anforderungshauptteil wird in IBM Cloudantgepostet, sodass viele Operationen in einen einzelnen API-Aufruf gepackt werden können.

In diesem Beispiel ist das erste Dokument eine Einfügung, weil kein Revisionstoken bereitgestellt wird. Das zweite Dokument ist eine Aktualisierung für ein Dokument, weil ein Revisionstoken mit einem neuen Dokumenthauptteil angegeben ist. Das dritte Dokument ist ein Löschvorgang. Es wird ein Revisionstoken bereitgestellt, aber der Hauptteil ist einfach _deleted: true, was IBM Cloudant sagt, dass das Dokument als gelöscht markiert werden soll.

Es ist wichtig zu beachten, dass dieses Szenario nicht wie eine Transaktion in einer relationalen Datenbank ist-alle oder keine dieser Operationen könnten einzeln erfolgreich sein oder ausfallen. Die Antwortdaten auf diese Anforderung zeigen Ihnen die Antwort für jede Operation an.

Zusammenfassend lässt sich sagen, dass mit zwei API-Aufrufen _bulk_docs und _all_docs alle Erstellungs-, Lese-, Aktualisierungs- und Löschoperationen für IBM Cloudant-Dokumente ausgeführt werden können und dies auch in einer Massenoperation möglich ist. _all_docs ruft Dokumente nach _id oder ID-Bereichen ab. _bulk_docs erstellt, aktualisiert und löscht Dokumente in großen Mengen. In der Regel empfehlen wir, Massenschreibvorgänge in Batches von 500 auszuführen; mehr für winzige Dokumente und weniger für große Dokumente.

Sehen Sie sich eine Bildschirmaufnahme der Verwendung von IBM Cloudant von einem Befehlszeilen-Terminal aus an:

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt wird als Zugriff auf IBM Cloudant programmgesteuertbezeichnet.

Auf IBM Cloudant Programmatisches Video zugreifen

Hier erfahren Sie, wie Sie programmgesteuert auf IBM Cloudant zugreifen.

Auf IBM Cloudant Programmatisches Videoscript zugreifen

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 9- Auf IBM Cloudant programmgesteuertzugreifen.

Unsere API-Interaktionen wurden bisher durch das Dashboard oder durch die Verwendung von curl aus der Befehlszeile ausgelöst. Im folgenden Abschnitt wird beschrieben, wie IBM Cloudant über das Programm zugegriffen wird.

Die Beispiele verwenden Node.js. Wenn Sie also den Code selbst ausprobieren möchten, müssen Sie Knoten und npm von nodejs.org installieren.

Anschließend können wir die offizielle IBM Cloudant Node.js-Bibliothek mit npm install @cloudant/cloudantinstallieren. (npm ist der Paketmanager, der im Lieferumfang von Node.js enthalten ist und Ihnen den Zugriff auf Tausende an Open-Source-Projekten sowie ihre kostenfreie Erstellung in einer eigenen Anwendung ermöglicht).

Sobald die Bibliothek IBM Cloudant installiert ist, können wir einen Quellcode erstellen. Sehen wir uns diesen Codeausschnitt Zeile für Zeile an:

URL des Dienstes IBM Cloudant wird aus der Umgebungsvariablen entnommen, die wir zuvor erstellt haben.

Die Bibliothek @cloudant/cloudant wird mit den integrierten erforderlichen Funktionen in Ihre Node.js-App geladen. Anschließend erstellen wir eine Instanz der Bibliothek, die mit den Berechtigungsnachweisen konfiguriert ist, die wir in der ersten Zeile gespeichert haben. Wir verwenden das Objekt IBM Cloudant , um einen Verweis auf die books -Datenbank zu erhalten und es in einer Variablendatenbank zu speichern. Wir haben keine API-Aufrufe getätigt, sondern nur Datenstrukturen erstellt, in denen Anmeldedaten und die Datenbank, mit der wir arbeiten, gespeichert werden. Die Hauptfunktion ruft db.listauf, die das 1-1 mit dem Endpunkt _all_docs zuordnet, den wir zuvor gesehen haben. Die an db.list übergebenen Parameter müssen mit den Optionen vertraut sein, die _all_docs erwartet, um die Ergebnismenge zu begrenzen und die Dokumentenkörper für jede ID zurückzugeben.

Sehen Sie sich einen weiteren Codeausschnitt an, der ein Dokument schreibt.

Sie können von der ersten Zeile aus sehen, dass Standard-JavaScript-Objekte in Ihrem Code verwendet werden können und an IBM Cloudant ohne Konvertierung gesendet werden können, da sie in JavaScript in nativem JSON-Format einschalten.

Beim Schreiben eines Dokuments handelt es sich lediglich um den Aufruf von db.insert, der einem API-Aufruf PUT/POST oder _bulk_docszugeordnet ist.

Zusammenfassend lässt sich sagen, dass die offiziellen Bibliotheken für IBM Cloudant Java™, Python und Nodejs sind. Dabei handelt es sich um dünne Wrapper um die IBM Cloudant HTTP-API-es lohnt sich also, die zugrunde liegende API zu verstehen, um alle Parameter zu verstehen.

Die Bibliotheken behandeln zwei Dinge für Sie, was nützlich ist:

Authentifizierung
Die Schlüssel für Token werden unabhängig davon ausgetauscht, ob es sich um eine traditionelle Authentifizierung oder um IAM handelt.
Wiederholungslogik
Die Bibliotheken können so konfiguriert werden, dass sie API-Aufrufe wiederholen, die Ihre bereitgestellte Kapazität überschritten haben. Wenn diese Methode konfiguriert ist, halten sie den API-Aufruf mehrmals mit exponentiellem Back-off an und wiederholen den Versuch.

Die erneute Verwendung solcher API-Aufrufe ist sinnvoll, wenn Sie eine temporäre und unerwartete Erhöhung im Datenverkehr haben. Wenn Sie routinemäßig Ihre bereitgestellte Kapazität überschreiten, wird die Datenbankarbeit nicht erneut versucht, sondern Sie benötigen mehr Kapazität!

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Abfragen.

Video 'Abfragen'

Hier erfahren Sie Informationen zu den unterschiedlichen Möglichkeiten zum Abfragen von Daten in IBM Cloudant.

Script zum Video 'Abfragen'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 10- Abfragen.

Bisher haben wir CRUD-Operationen (Erstellen, Abrufen, Aktualisieren und Löschen) über die Befehlszeile, das Dashboard und den Code ausgeführt. Diese Operationen verwenden die _id des Dokuments:

  • Dokument mit der _id abrufen.
  • Dokument aktualisieren, dessen _id = 'x' ist.
  • Dokument löschen, dessen _id = 'x' ist.
  • Dokumente im _id-Bereich von 'a' bis 'z' abrufen.

Diese Operationen sind die Bausteine einer Datenbank, doch sie reichen nicht aus. Was ist, wenn Sie eine Teilmenge von Dokumenten zurückgeben müssen, die mit Feldern innerhalb des Dokuments übereinstimmen? Das Geburtsdatum einer Person? Der Titel eines Buchs? Der Wert einer Bestellung?

Die Abfrage kommt hier rein.

IBM Cloudant verfügt über mehrere Methoden zum Abfragen von Daten. Das erste, das wir betrachten, heißt IBM Cloudant Abfrage.

IBM Cloudant Die Abfragesprache von Query ist von der MongoDB-Abfragesprache inspiriert. Abfragen werden im JSON-Format ausgedrückt, wobei vom Attribut selector die Teilmenge der Daten beschrieben wird, die zurückgegeben werden. Die JSON-Abfrage wird an den Endpunkt _find der Datenbank gesendet, um eine Abfrage auszuführen.

Die einfachste Form der Abfrage ist das Suchen von Dokumenten, bei denen ein Attribut einen festen Wert hat, z. B. author == J Smith.

Das zweite Beispiel zeigt zwei Klauseln in der Abfrage. Beide Klauseln müssen für ein Dokument erfüllt sein, damit es in die Suchergebnisse aufgenommen werden kann. Beispiel: isbn === 6725252 AND date = 2018-01-01.

Am dritten Beispiel wird veranschaulicht, wie logische Operatoren hinzugefügt werden können. Die $gt-Operation bedeutet greater than (Sie können auch gte für Vergleiche mit "größer oder gleich" und lt/lte für die entsprechenden Vergleiche mit "kleiner als" verwenden). Der Operator $or ist eine OR -Operation, daher muss ein entsprechendes Dokument über ein Datum verfügen, das größer als der in der Abfrage ist, entweder ein Autor von J Smith OR oder Titel von "Mord".

Wenn Sie auf Objekte in Dokumenten zugreifen müssen, können Sie die Standardpunktschreibweise verwenden, z. B. address.zipcode , um auf eine Postleitzahlenzeichenfolge innerhalb eines Adressobjekts zuzugreifen.

Wir können auch die folgenden Parameter hinzufügen:

Felder
Gibt die Dokumentattribute an, die zurückgegeben werden sollen (der Standardwert ist das gesamte Dokument).
Sortieren
Definiert, wie die Daten sortiert werden sollen. Da zum Sortieren ein Array verwendet wird, kann der Sortiervorgang für mehrere Attribute berechnet werden.
Grenzwert
Die Anzahl der zurückzugebenden Dokumente.

Wenn Sie bereits mit relationalen Datenbanken vertraut sind, handelt es sich bei dieser Abfrage um die äquivalente SQL-Abfrage für dieses letzte IBM Cloudant Abfragebeispiel.

Die Klausel WHERE entspricht SELECTOR in IBM Cloudant Query. ORDER und LIMIT sind absolut äquivalent und die IBM Cloudant Query-FIELDS-Liste entspricht der durch Kommas getrennten Liste von Attributen nach dem Schlüsselwort SELECT.

Die JSON-Syntax kann zwar ein wenig gewöhn werden, aber die MongoDB-Benutzer finden es vielleicht vertraut.

IBM Cloudant Abfragen können in der IBM Cloudant Statusübersicht ausgeführt werden. Wählen Sie die Datenbank aus, mit der Sie arbeiten (z. B. books ), und wählen Sie dann die Registerkarte Abfrage aus.

Geben Sie Ihre IBM Cloudant JSON-Abfrage in das bereitgestellte Feld ein und klicken Sie auf Abfrage ausführen , wenn Sie bereit sind. Die Ergebnismenge wird auf der Seite angezeigt.

Mit der Schaltfläche 'EXPLAIN bearbeiten' wird erläutert, wie die Datenbank die angegebene Abfrage interpretiert. Diese Erklärung wird wichtiger, wenn wir im nächsten Teil die Indexierung erreichen.

Abfragen können auch von curl ausgelöst werden. Die JSON-Abfrage wird in diesem Fall in einer Datei gespeichert, und wir POST verwenden den Endpunkt _find mit der Syntax -d@ command-line.

Der Node.js-Code ist ähnlich. Bei der Abfrage handelt es sich um ein Standard-JavaScript-Objekt, das an die Funktion db.find übergeben wird, die es POSTs für den Endpunkt _find in Ihrem Namen verwendet.

Nun ist es an der Zeit für eine praktische Übung. Entwerfen Sie Ihre eigene IBM Cloudant Abfrage, die die Titel von Büchern findet, die im 20. Jahrhundert geschrieben wurden. Die IBM Cloudant Abfrage-Dokumentation finden Sie falls benötigt mittels URL auf dem Bildschirm.

Halten Sie die Präsentation hier an, wenn Sie die Antwort nicht wissen möchten.

Siehe eine Lösung:

Ich verwende den Operator $and , um zwei Klauseln zu dem Datumsattribut zu kombinieren. Eine Klausel zum Suchen von Dokumenten mit einem Datum >= 1900, eine weitere zum Suchen von Dokumenten mit einem Datum < the year 2000. Beide Klauseln müssen erfüllt sein, damit ein Dokument ausgewählt wird Da wir nur den Titel der passenden Bücher benötigen, können wir ein Feld-Attribut angeben, anstatt das gesamte Dokument zurückgegeben zu werden.

Zusammenfassend ist IBM Cloudant Query eine Abfragesprache, die von MongoDB inspiriert wird, in der die Syntax in JSON-Form ausgedrückt wird.

Abfragen wählen Untergruppen von Dokumenten aus der Datenbank aus, indem Sie Klauseln verwenden, die für Daten innerhalb des Dokuments verwendet werden-nicht nur die _iddes Dokuments.

Abfragen werden über das Programm an den Endpunkt _find der Datenbank gesendet, entweder über curl oder über das Dashboard.

Vom Selektor der Abfrage wird entschieden, welcher Ausschnitt der Daten erforderlich ist.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt wird als Indexingbezeichnet.

Video 'Indexierung'

Hier erfahren Sie, wie die Indexierung den Abfrageprozess beschleunigen kann.

Script zum Video 'Indexierung'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dieses Video ist Teil 11- Indexieren.

Die Abfragen, die wir im vorherigen Teil ausgeführt haben, waren nicht optimal: Um die Antwort zu erhalten, musste IBM Cloudant jedes Dokument in der Datenbank wieder einspulen, um festzustellen, ob es mit den Suchkriterien erfüllt wurde.

Um Abfragen, die auf performante und skalierbare Weise ausgeführt werden, zu erstellen, benötigen wir Indexieren.

Mit IBM Cloudantkönnen Sie eine beliebige Anzahl von Indizes (oder Indizes) angeben.

Ein Index ist eine Sekundärdatenstruktur, die aus der Dokumentliste erstellt wird. Sie enthält Daten, die nach den von Ihnen angegebenen Feldern sortiert sind, z. B. Bücher, die nach Datum und Titel sortiert sind. Wenn Sie eine Abfrage ausführen, die nach Daten fragt, die mit dem Datum und dem Titel eines Dokuments übereinstimmen, kann die indexierte Datenstruktur verwendet werden, um den Abfrageprozess zu beschleunigen. Statt jedes Dokument wiederum zu scannen, kann IBM Cloudant zu dem relevanten Teil des Index springen (sagen wir, der Abschnitt über Bücher des 20. Jahrhunderts) und die Daten viel schneller abrufen.

IBM Cloudant Abfrageindizes umfassen zwei Typen von Indizes: type=json und type=text. Diese Indizes werden durch zwei zugrunde liegende Indexierungstechnologien unterstützt, die wir in den folgenden Teilen dieses Kurses kennenlernen werden.

Ein Index wird definiert, wenn Sie einen POST -JSON-Endpunkt in den _index -Endpunkt einer Datenbank eingeben.

Das Indexobjekt enthält ein Feldarray, das angibt, welche Dokumentattribute indexiert werden sollen. In der Regel entsprechen die Felder, die Indexierung benötigen, den Attributen, die im selector einer Abfrage verwendet werden, die Sie zum Abrufen der Daten verwenden. Das heißt, wenn Sie nach dem Datumsfeld abfragen müssen, müssen wir das Datumsfeld indexieren.

Obwohl der name eines Index optional ist, hat sich dies bewährt und wir folgen dieser Konvention. Es ist gut, IBM Cloudant eine Frage zu stellen und den Namen des Index anzugeben, den Sie verwenden möchten. Diese Praxis speichert IBM Cloudant von der Auswahl, welcher Index aus den verfügbaren Indizes verwendet werden soll, und macht es Ihnen leicht, sich daran zu erinnern, welcher Index das ist.

Erstellen wir nun einen Index für unsere books -Datenbank aus dem Dashboard. Wählen Sie die Datenbank aus und wählen Sie dann die Registerkarte Dokumente entwerfen und Abfrageindizes aus dem Menü aus.

Alle vorhandenen Indizes werden auf der Seite aufgelistet: Es muss ein special-Index vorhanden sein, der den primären Index darstellt, basierend auf dem _id des Dokuments.

Führen Sie die Indexdefinition mit dem JSON-Code aus:

Klicken Sie auf Index erstellen, wenn Sie fertig sind.

Durch Klicken auf die Schaltfläche wird eine POST -Anforderung an den Endpunkt _index gesendet (andere API-Aufrufe sind verfügbar, um vorhandene Indizes zu aktualisieren und zu löschen).

Indizes werden asynchron von IBM Cloudant im Hintergrund erstellt. Bei großen Datenbanken kann es IBM Cloudant einige Zeit dauern, bis der Index zum ersten Mal erstellt wird. Der Index kann die Datenbank erst verwenden, wenn der ursprüngliche Build bereit ist.

Wir können unsere Suche nach Büchern im 20. Jahrhundert wiederholen. Dieses Mal geben wir den Indexnamen mit dem Feld use_index an. Die Antwort kehrt zurück-dieses Mal powered by our index. Eine Verbesserung der Geschwindigkeit für eine kleine Datenbank wird möglicherweise nicht bemerkt, aber der Nutzen ist definitiv zu spüren, wenn Ihre Datengröße und das Abfragevolumen größer werden. Die Indexierung trägt dazu bei, dass Abfragen leistungsfähig bleiben, wenn eine Anwendung größer wird.

Wenn Sie IBM Cloudant zum Erstellen eines sekundären Index angeben, startet er eine Hintergrundtask, die alle Dokumente wiederum betrachtet und eine neue Datenstruktur auf der Platte erstellt: den Index. Der Index ist ein ausgewogener Baum, der die Schlüssel (das Attribut oder die Attribute, die Sie indizieren müssen) mit dem Dokument _id verknüpft, aus dem sie stammen.

Der Index kann verwendet werden, um bekannte Schlüssel und Schlüsselbereiche effizient nachzuschlagen, ohne die gesamte Datenbank erneut durchsuchen zu müssen.

Ein weiterer Trick, den Sie bei der Indexzeit verwenden können, ist der Teilfilter. Sie können optional einen Teilfilter in Ihrer Indexdefinition angeben. Dieser IBM Cloudant Abfrageselektor wird zur Indexzeit ausgeführt, um zu entscheiden, welche Daten des Dokuments den Index zum Index machen und die ignoriert werden.

In diesem Beispiel wird ein Selektor verwendet, der nur Daten zulässt, die an einem Wochenende fallen, um es an den Index zu machen. Kleinere Indizes sind schneller und effizienter. Wenn Sie einen Anwendungsfall haben, der nur eine Teilmenge der zu indexierenden Daten benötigt, kann ein partieller Filterselektor zur Indexzeit dazu beitragen, den Index kleiner und effizienter zu machen. Beispielsweise möchten Sie möglicherweise nur abgeschlossene Bestellungen oder nur abgelaufene Konten oder nur veröffentlichte Blogbeiträge indexieren.

Zusammenfassend lässt sich sagen, dass der Endpunkt _index zum Definieren des Index verwendet wird und ein optionaler Teilfilter zur Abfragezeit angewendet werden kann, um kleinere, sparse Indizes zu erstellen.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel MapReduce.

Video 'MapReduce'

Hier erfahren Sie mehr über MapReduce, eine weitere Möglichkeit zum Konfigurieren eines sekundären Index.

Script zum Video 'MapReduce'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 12- MapReduce.

Wir haben gesehen, wie eine Kombination der Endpunkte _find und _index ermöglicht, dass Abfragen für den Inhalt von JSON-Dokumenten ausgeführt werden. Sie werden durch sekundäre Indizes unterstützt, um den Umfang der Abfragen zu skalieren, wenn Ihre Anwendung wächst.

In diesem Teil stellen wir eine andere Methode zur Konfiguration von sekundären Indizes vor, die MapReduce genannt werden.

MapReduce war einmal die einzige Möglichkeit zum Konfigurieren sekundärer Indizes in CouchDB und ist immer noch eine gängige Methode zum Abfragen von Daten aus dem Dokumenthauptteil.

Um einen MapReduce-Index zu erstellen, müssen Sie eine JavaScript-Funktion bereitstellen, die in ein spezielles Dokument eingeschlossen ist, das als Entwurfsdokument für IBM Cloudantbezeichnet wird. Entwurfsdokumente ' _id Felder beginnen mit _design/ , z. B. _design/mydesigndoc.

Wenn IBM Cloudant das Entwurfsdokument empfängt, wird eine Task zum Indexieren von Hintergrundinformationen eingerichtet, die jedes Dokument aus der Datenbank an Ihre JavaScript-Funktion übergibt. Die Schlüssel-Werte, die von Ihrer JavaScript-Funktion ausgegeben werden, bilden die Basis des Index, der persistent gespeichert wird.

Kommen wir nun zu einigen Beispielen von JavaScript-Funktionen.

Die Funktion akzeptiert einen Parameter – das Dokument, das durch den IBM Cloudant-Indexer an sie übergeben wird. Jedes Mal, wenn Ihre Funktionsaufrufe die Parameter ausgeben, die Sie aus dem Schlüsselwert des Index übergeben.

Das erste Beispiel gibt einen Schlüssel von doc.nameaus, d. h. in diesem Fall ist es ein Index für Suchvorgänge nach dem Namensfeld. Für den Wert ist nichts (null) vorhanden.

Im zweiten Beispiel werden die Daten vor dem Ausgeben vorverarbeitet. Diese Vorverarbeitung ist eine nützliche Methode zum Aufräumen von Zeichenfolgen, zum Trimmen von Leerzeichen, zum unteren und zum oberen Gehäusetext, zum Anwenden von Standardwerten auf fehlende Daten oder zum Eingrenzen von Werten in bestimmte Bereiche usw.

Im dritten Beispiel wird eine Logik hinzugefügt: Ein Index soll nur aus Dokumenten bestehen, die bereits published wurden. Diese Logik entspricht dem Teilfilterselektor, den wir bei der Abfrage IBM Cloudant gesehen haben.

Indizes werden asynchron erstellt und können erst dann verwendet werden, wenn sie vollständig erstellt werden. Nach der Erstellung können sie für die Auswahl nach Schlüssel, Schlüssellisten, Schlüsselbereichen und Datenaggregation verwendet werden. Beispiel: Suchen Sie Bestellungen zwischen zwei Datumsangaben und berechnen Sie den Gesamtwert der Bestellungen, gruppiert nach Monat.

IBM Cloudant enthält die vier integrierten Reduktoren (oder fünf, wenn Sie none).

_count
Zum Zählen von Sachen.
_sum
Zum Summieren von Werten.
_stats
Zum Bereitstellen von Zählungen und Summen, die für die Berechnung von Mittelwerten, Varianzen und Standardabweichungen geeignet sind.
_approx_count_distinct
Für die ungefähre Zählung der eindeutigen Werte des Schlüssels.

Die Funktion MAP des Entwurfsdokuments wird an einen doc übergeben. Die Funktion wird einmal pro Dokument in der Datenbank aufgerufen. Alle Schlüssel/Wert-Paare, die emit werden von der Funktion MAP, erstellen den Index.

Der KEY ist das Element (oder die Elemente), nach denen Sie select möchten (z. B. Datum).

Der VALUE ist das Element, über das Sie einen Bericht benötigen (z. B. Gesamtverkäufe).

Der Reducer ist _sum , sodass der VALUE für übereinstimmende Schlüssel aufsummiert wird (z. B. Bestellungen zum selben Datum).

Sehen Sie sich im IBM Cloudant an, wie die Definition MapReduce aussieht.

Wenn die MapReduce-Ansicht erstellt wird, kann sie abgefragt werden, um jedes im Index gespeicherte KEY-VALUE -Paar anzuzeigen.

Oder, wenn der Reduzierer eingeschaltet ist, kann die Ergebnismenge nach dem Wert jedes Schlüssels gruppiert werden. In diesem Fall summieren wir die Verkäufe jedes Tages.

Die Sicht kann für einzelne Schlüssel (z. B. Verkäufe an einem bestimmten Datum), für alle Schlüssel oder für eine Reihe von Schlüsseln (z. B. zwischen zwei Datumsangaben) abgefragt werden.

MapReduce-Ansichten werden asynchron erstellt und können einige Zeit in Anspruch nehmen, um für große Dateien bereit zu sein.

Beachten Sie einige Tipps:

Verwenden Sie Logik in Ihrem JavaScript, um nur Daten einzuschließen, die sinnvoll sind, z. B. nur abgeschlossene Bestellungen aufsummieren. Indexierte Schlüssel müssen nicht Zeichenfolgen sein. Ein allgemeines Muster besteht darin, Array-Schlüssel zu verwenden, z. B. ein Array von Jahr, Monat, Tag. Diese Indexschlüssel ermöglichen eine Abfrage-Zeit-Gruppierung nach Elementen in der Feldgruppe. Sie können zum Beispiel Bestellungen nach Jahr, Bestellungen nach Jahr und Monat, Bestellungen nach Jahr und Monat und Tag gruppieren. Ideal für zusammenfassende Berichte, die es dem Benutzer ermöglichen, sich in das Detail zu bohren. Der Wert kann durch eine Zeichenfolge, eine Zahl oder manchmal ein kleines Objekt, das eine Teilmenge des Dokuments enthält, angegeben werden. Das Objekt kann anstelle des Hinzufügens von include_docs=trueverwendet werden. Dies würde auch den Hauptteil des Dokuments in der Ergebnismenge zurückgeben.

MapReduce ist also eine Low-Level-Methode zum Definieren von Indizes, die das Auswählen und Aggregieren von Daten ermöglichen.

Verwenden Sie die JavaScript-Logik, um zu entscheiden, welche Daten in den Index aufgenommen werden. Wählen Sie aus, wie der Index durch die Ausgabe von Schlüsselwerten gebildet wird.

Daten können mit den integrierten Reducern zusammengefasst werden. Effiziente Erstellung kompakter Berichte aus großen Datenmengen.

MapReduce ist ideal für Boilerplate-Abfragen, die von Ihrer Anwendung immer wieder ausgeführt werden müssen. Nicht für einmalige, Ad-hoc-Abfragen zur Datenerkundung.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt trägt den Titel Datumsangaben bezeichnet.

Video 'Datumsangaben'

Hier erfahren Sie mehr über die unterschiedlichen Optionen zum Speichern eines Datums oder eines Werts für Datum und Uhrzeit.

Script zum Video 'Datumsangaben'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 13- Datumsangaben.

Wir haben in diesem Kurs bereits gesehen, dass JSON nur Zeichenfolgen, Zahlen, boolesche Werte, Objekte und Arrays nativ modelliert. Ein allgemeiner Anwendungsfall ist die Speicherung eines Datums bzw. eines Wertes für Datum und Uhrzeit in einer Datenbank. Hier finden Sie einige Ideen, wie dies mit IBM Cloudant erreicht werden kann.

Das Format ISO-8601 für die Darstellung einer Zeit besteht aus dem Jahr y-m-dTh:m:s.msTIMEZONE , einem Monat, einem Tag, einem ' T' -Zeichen, einer Stunde, einer Minute, einer Sekunde, einer Millisekunde und einer Zeitzone.

Ich empfehle immer, Daten in der Zeitzone UTC zu speichern, auch wenn Sie Daten aus verschiedenen Regionen sammeln. Das in dieser Form gespeicherte Datum kann im Frontend einfach in die lokale Zeitzone umgewandelt werden. Es ist in der Regel wichtig, die Daten jedes Benutzers in den "gleichen Einheiten" zu speichern.

Dieses Zeichenfolgeformat sortiert in Datums-und Uhrzeitreihenfolge (da sich die wichtigsten Datumseinheiten an der Vorderseite der Zeichenfolge befinden) und kann in MapReduce-Funktionen einfach geparst werden.

Eine weitere Möglichkeit ist das Speichern der Anzahl der Millisekunden seit dem 1. 1. 1970. Diese Option ist auch eine Standard-, maschinenlesbare Art, ein Datum und eine Uhrzeit darzustellen.

Auch sie kann in MapReduce-Funktionen geparst werden und ist für den Vergleich von zwei Terminen nützlich: einfach eine Zeitmarke aus einem anderen.

Zusammenfassend lässt sich sagen, dass es kein natives Datumsformat in JSON gibt, sodass Sie Daten und Zeiten nach Belieben speichern können. ISO-8601 ist kompakt, gut lesbar und gut sortiert, ebenso wie eine Zeitmarke (Millisekunden seit 1970).

Wenn Sie IBM Cloudant Query on one of the component parts (Abfrage an einem der Komponenten-Teile) verwenden müssen, muss dies explizit in dem Dokument ausgebrochen werden.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Replikation.

Video 'Replikation'

Hier erfahren Sie, was Replikation in IBM Cloudant bedeutet, welche unterschiedliche Replikationstypen es gibt und wie sie funktionieren.

Script zum Video 'Replikation'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 14- Replikation.

Die Replikation ist ein Kernfeature von IBM Cloudant. Es handelt sich hierbei um die Übertragung der Daten aus einer Datenbank (der Quelle) in eine andere (das Ziel).

Die Quell- und Zieldatenbanken können sich auf demselben IBM Cloudant befinden oder geografisch getrennt sein, z. B. IBM Cloudant, die auf eine in Europa repliziert wird.

Das IBM Cloudant Replikationsprotokoll wird mit Apache CouchDB gemeinsam genutzt, sodass die Replikation häufig von Unternehmen verwendet wird, die Daten aus einer Cloud-basierten Datenbank in eine aktive CouchDB an ihrem eigenen Standort kopieren.

PouchDB, ein JavaScript-basierter CouchDB-Klon, der in Node.js-Stacks oder im Web-Browser ausgeführt wird, kann auch verwendet werden, um Daten zwischen IBM Cloudant oder CouchDB, auf jede Art und Weise, zu replizieren, entweder zu oder von.

Bei den IBM Cloudant Sync-Bibliotheken handelt es sich um native iOS-oder Android-Apps, die Daten mit einem IBM Cloudant Service synchronisieren.

Die Replikation ist ein einseitiger Vorgang von der Quelle zum Ziel, bei dem alle Daten (Löschungen, Konflikte, Anhänge sowie Dokumente) übertragen werden und der auf zwei verschiedene Arten ausgelöst werden kann:

  1. Führen Sie den Befehl aus, bis alle Daten aus der Quelle das Ziel erreicht haben, und stoppen Sie anschließend.
  2. Die gleiche wie eine, aber die Replikation läuft kontinuierlich für immer, die Übertragung neuer Daten von der Quelle auf das Ziel, wie es ankommt.

Die Replikation kann auch an der Stelle fortgesetzt werden, an der sie zuletzt gestoppt wurde. Von IBM Cloudant wird ein Datensatz mit checkpoints zwischen den replizierenden Parteien aufbewahrt, damit eine Wiederaufnahme einer bereits existierenden Replikation von ihrer letzten bekannten Position möglich ist.

Das IBM Cloudant Dashboard enthält eine Replikationsregisterkarte. Eine Replikation wird gestartet, indem die Quellen-und Zieldatenbanken, die Authentifizierungsnachweise enthalten, angegeben werden und ob diese Replikation eine einmalige Operation oder ein kontinuierlicher Betrieb ist.

Für eine Replikation kann auch ein Namen festgelegt werden; dies ist beim Unterscheiden der Replikationsjobs von Vorteil.

Jetzt ist die Zeit für eine praktische Übung gekommen.

  1. Rufen Sie das IBM Cloudant-Dashboard auf.
  2. Erstellen Sie eine Datenbank mit dem Namen books2.
  3. Starten Sie eine kontinuierliche Replikation von books zu books2.
  4. Besuchen Sie die Datenbank books2, um zu überprüfen, ob Dokumente aus books jetzt in books2enthalten sind.
  5. Fügen Sie der Datenbank books ein Dokument hinzu.
  6. Stellen Sie sicher, dass die Änderung an der Datenbank books2 erfolgt.

Die Replikation kann verwendet werden, um Daten aus einer IBM Cloudant -Datenbank in eine On-Premises-CouchDB-Instanz zu versetzen. Die Replikation kann von IBM Cloudant oder CouchDB gesteuert werden. Sie können beispielsweise IBM Cloudant bitten, seine Änderungen an 'CouchDB' zu senden, oder Sie können CouchDB auffordern, die Änderungen von IBM Cloudantzu ziehen. Der Replikationscontroller muss über die Netzsichtbarkeit der beiden HTTP-APIs verfügen.

PouchDB spricht auch das gleiche Replikationsprotokoll, so dass es verwendet werden kann, um Daten an und von PouchDB und IBM Cloudantzu übertragen. In diesem Fall ist es am wahrscheinlichsten, dass die Replikation von PouchDB gesteuert wird.

PouchDB wird häufig verwendet, um offline erste Apps zu erstellen. Diese Apps erfassen Daten auch dann, wenn sie nicht mit dem Internet verbunden sind, und schreiben Daten dann auf IBM Cloudant , wenn sie wieder online sind, und geben ihren Benutzern immer einen Service für den Service.

Die Replikation kann nicht immer erforderlich sein. Wenn Ihre Anwendung Daten speichern und sie dann später auf IBM Cloudant später schreiben muss, ist die Replikation nicht unbedingt erforderlich. Alles, was erforderlich ist, ist, dass Daten auf dem Gerät gespeichert werden, und Massendaten werden in IBM Cloudant geschrieben, wenn die Verbindung wiederhergestellt wird.

Da die Replikation eine Einmaloperation ist, wenn eine primäre primäre Konfiguration zwischen zwei IBM Cloudant -Instanzen in verschiedenen Regionen erforderlich ist, sind zwei Replizierungen in entgegengesetzten Richtungen erforderlich.

Änderungen, die am Standort London vorgenommen werden, werden somit an Dallas gesendet und umgekehrt.

Es sind komplexere Topologien möglich, mit Daten, die in einem Ring um einen Satz IBM Cloudant Service fließen.

Zusammenfassend lässt sich sagen, dass IBM Cloudant Replikation ein Mechanismus zum Kopieren von Daten aus einer Quellendatenbank in eine Zieldatenbank ist.

Replikationen können einmalig oder kontinuierlich sein und können optional mit einer JavaScript-Funktion oder einem IBM Cloudant Abfrageselektor gefiltert werden und von dort aus wieder aufgenommen werden, wo eine vorherige Replikation gestoppt wurde.

Damit ist dieser Teil abgeschlossen. Der nächste Teil trägt den Titel Partitionierte Datenbanken.

Video 'Partitionierte Datenbanken'

Hier erfahren Sie, wie partitionierte Datenbanken in IBM Cloudant arbeiten, wie Dokumente bestimmten Shards zugeordnet werden und warum partitionierte Datenbanken Leistung, Kosten und Skalierbarkeit verbessern.

Script zum Video 'Partitionierte Datenbanken'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 15- Partitionierte Datenbank.

IBM Cloudant es handelt sich um eine verteilte Datenbank, die wir im Folgenden besprechen werden. Viele Speicherknoten bilden einen IBM Cloudant Service, und die Dokumente einer Datenbank werden über die Knoten in Gruppen, sog. shardsverteilt. Eine einzelne Datenbank ist sozusagen "zersplittert" (sharded) und besteht somit aus mehreren Teilen.

In einer normalen IBM Cloudant Datenbank werden Dokumente algorithmisch Shards zugeordnet – im Effekt werden die Dokumente nach dem Zufallsprinzip auf Shards verteilt.

In einer partitionierten Datenbank definieren Sie durch Angeben eines Partitionsschlüssels, in welchem Shard die Dokumente gespeichert werden.

Partitionierte Datenbanken werden nicht mit demselben PUT /<database name>-API-Aufruf erstellt, sondern mit einem zusätzlichen Abfragezeichenfolgenparameter: partitioned=true.

Im ersten Beispiel wird die Produktdatenbank als partitionierte Datenbank, im zweiten Beispiel, als Standard-, nicht partitionierte Datenbank erstellt.

Wenn Sie einer partitionierten Datenbank Dokumente hinzufügen, müssen Sie eine Dokument-ID angeben - (es gibt keine automatisch generierten Dokument-IDs). Ein Dokument _id verfügt über zwei Teile, die durch einen Doppelpunkt voneinander getrennt sind:

Partitionsschlüssel
Eine Zeichenfolge, die definiert, auf welcher Partition das Dokument gespeichert werden soll.
Dokumentschlüssel
Eine Zeichenfolge, die ein Dokument innerhalb der Partition eindeutig identifiziert.

Im ersten Beispiel wird ein Buch der Partition 'book' der Datenbank 'products' hinzugefügt.

Dann wird ein anderes Dokument in die DVD-Partition und ein Drittel in die private Partition eingefügt.

Dies hat zur Folge, dass Dokumente, die einen Partitionsschlüssel gemeinsam nutzen, sich im selben Shard der Datenbanken befinden. Dokumente in derselben Partition werden in der Dokumentschlüsselreihenfolge zusammen gespeichert.

Der Vorteil dieses Konzepts wird beim Abrufen der Daten deutlich. Wir können IBM Cloudant-Abfragen, MapReduce-Anforderungen und Suchvorgänge in einer einzelnen Partition ausführen. In diesem Beispiel wird ein IBM Cloudant Abfrageselektor an die book -Partition gesendet. Diese Aktion bedeutet, dass Sie nur einen Bruchteil der IBM Cloudant -Infrastruktur verwenden (nur der Shard, der die Buchpartition hostet, der Rest des Clusters bleibt inaktiv).

Dieses Szenario ermöglicht eine schnellere Abfrageleistung, kostengünstigere Abfragekosten und eine bessere Skalierbarkeit.

Das Entscheidende für eine gute Abfrageleistung in einer partitionierten Datenbank ist die Auswahl des Partitionsschlüssels:

Es muss sich um einen Wert handeln, der in Ihrer Datenmenge wiederholt vorkommt. Beispiel: In der book -Partition sind mehrere Elemente vorhanden. Es müssen mehrere Partitionen vorhanden sein. Wenn Sie nur ein paar Kategorien haben, dann ist die Kategorie eine schlechte Wahl für Partitionierungsschlüssel. Es muss etwas sein, das viele Werte hat, zum Beispiel deviceId in einer IoT-Anwendung oder orderId in einem E-Commerce-System. Außerdem muss eine Übereinstimmung mit den Abfragen gegeben sein, die von der Anwendung erstellt werden. Wenn der häufigste Anwendungsfall in einer Produktkategorie gesucht wird, kann die Partitionierung nach Kategorie eine gute Passform sein. Vermeiden Sie heiße Partitionen-Datenverkehr muss gleichmäßig über Ihre Partitionen verteilt werden. Wenn Ihre Wahl des Partitionierungsschlüssels wahrscheinlich zu einer großen Zunahme des Datenverkehrs führen wird, der auf ein paar Partitionen trifft, dann ist dieses Szenario für eine schlechte Wahl des Partitionierungsschlüssels erforderlich.

Zum Zusammenfassen werden partitionierte Datenbanken mit dem Flag partitioned=true erstellt, und Dokumente haben eine zweiteilige ID, bei der der Partitionsschlüssel und der Dokumentschlüssel durch einen Doppelpunkt verknüpft werden.

Dokumente in derselben Partition werden in der Dokumentschlüsselreihenfolge in demselben Datenbankshard gespeichert. Wenn wir diese Methode des Speichers kennen, können wir Abfragen, die auf eine einzelne Partition gerichtet sind, schneller und billiger ausführen.

Es ist immer noch möglich, die Partitionen in einer partitionierten Datenbank abzufragen. Wenn Sie einen sekundären Index erstellen, wählen Sie aus, ob sein Zweck pro Partition oder für den globalen Geltungsbereich gilt.

Damit ist dieser Teil abgeschlossen. Der nächste Abschnitt trägt den Titel IBM Cloudant Suchen.

IBM Cloudant Video durchsuchen

Hier erfahren Sie, wie Sie die IBM Cloudant Suche, sowie die Lucene-Abfragesprache und -facettierung verwenden.

IBM Cloudant Videoscript suchen

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dies ist das Video zu Teil 16- IBM Cloudant Suchen.

Wir haben eine andere Methode zum Abfragen und Indexieren in IBM Cloudant namens IBM Cloudant Search, die wir in diesem Teil kurz darlegen.

IBM Cloudant Die Suche basiert auf einem anderen Open-Source-Projekt, Apache Lucene, das die Suchfunktionen vieler Produkte, die Elasticsearch einschließen, unterstützt.

Es ist in erster Linie für die freie Textsuche konzipiert, bei der Textblöcke vor ihrer Indexierung vorverarbeitet werden: Fall, Interpunktion, gemeinsame Rauschwörter und Trimmen gängiger sprachlicher Wortendungen, zum Beispiel wird Landwirt Bauernhof, und Bauernhöfe werden zu landwirtschaftlichen Betrieben.

Diese Textverarbeitung wird von einer Auswahl an Analysefunktionen zur Abfragezeit vor der Suche ausgeführt. Vor dieser Zeit ermöglicht es auch einige Aggregationsfunktionen, die eine Technik verwenden, die als Facettierung bezeichnet wird.

Ein IBM Cloudant Suchindex wird durch die Bereitstellung von JavaScript-Funktion erstellt. Es ist MapReduce nicht unähnlich, nur dass die Ausgabe-Funktion in diesem Fall durch eine Indexfunktion ersetzt wird, die den Namen des Feldes, die Daten selbst und einige Optionen erwartet.

Im vorliegenden Beispiel werden der Name und der Titel des Dokuments mit den Standardoptionen indexiert. Die Kategorie ist für Facettierung nominiert (die Aggregationsfunktionalität) und die ISBN ist im Index gespeichert, aber nicht für die Suche selbst indiziert. Manchmal ist es effizienter, einige Elemente im Index zu speichern, anstatt include_docs=true zur Abfragezeit zu tun.

Lucene verfügt über eine eigene Abfragesprache, die Abfragen erstellt, die Kombinationen von Klauseln mit Logik, Fuzzy-Matching, Bereichen und Term Boosting entsprechen.

Beispiele:

  • Suche nach Dokumenten, deren Titel eine Übereinstimmung mit gastby aufweisen und deren Autor mit fitz beginnt. Beachten Sie den Stern, der als Platzhalter verwendet wird.
  • Suchen Sie Dokumente, deren author im Bereich austen to dickensliegt. In diesem Beispiel wird eine Bereichsabfrage für ein Zeichenfolgenfeld angezeigt.
  • Hier finden Sie Dokumente, deren Preis bei 0 - 100 AND deren Jahr im 19th century liegt oder deren Autor charles dickensentspricht. Dieses Beispiel zeigt, wie Logik in Abfragen eingebaut werden kann.

IBM Cloudant Die Suche ist nicht nur für die Suche nach freiem Text nützlich. Es ist auch nützlich, wenn Sie wissen, nach welchen Attributen Sie suchen möchten, aber die Abfragen sind unterschiedlich, mit unterschiedlichen Kombinationen von Attributen jedes Mal. Diese Flexibilität lässt sich mit MapReduce-Indizes nur schwer erreichen, da sie eine feste Reihenfolge aufweisen.

Die Facettierung ist eine Form der Aggregation. Sie legen einzelne indizierte Felder vorab für die Facettierung zum Indexierungszeitpunkt fest und aktivieren die Aggregation mit den Parametern zur Abfragezeit.

Dies hat einen doppelten Nutzen:

Das Zählen der sich wiederholenden Werte in der Ergebnismenge, zum Beispiel die Anzahl der Produkte, die zu jeder Kategorie in einer Ergebnismenge gehören. Oder das Zählen von Elementen in numerischen Bereichen, zum Beispiel die Produktanzahl in jeder Preisspanne. Beide Formen von Zählungen können einem Frontend-Benutzer als Mittel zur weiteren Filterung einer vorhandenen Suche zur Einengung des Suchbereichs dargestellt werden. Beispiel: Ein Kunde sucht nach Fenderund klickt dann auf Amps und anschließend auf einen Preisbereich von under $500. Alle diese Such-und Filtervorgänge können über IBM Cloudant Suchen (Search) aktiviert werden.

Zusammenfassend lässt sich sagen, dass IBM Cloudant Suchindizes mit einer mitgelieferten JavaScript-Funktion definiert sind. Sie basieren auf Apache Lucene und werden hauptsächlich für den Abgleich mithilfe einer Freitextsuche verwendet, die Abfragesprache ist jedoch auch zum Erstellen flexibler Abfragen für eine feste Anzahl an indizierten Feldern nützlich. Sie weist auch einige leistungsfähige Aggregationen für Zählungen auf, die für Benutzerschnittstellen mit Drilldown-Funktion geeignet sind.

IBM Cloudant Die Suchen unterstützt außerdem type=text IBM Cloudant Abfrageindizes, sodass eine Untergruppe der zugehörigen Funktionen mithilfe der API _find exportiert wird.

Damit ist dieser Teil abgeschlossen. Den nächsten Teil nennen wir Unter der Haube.

Video 'Innere Abläufe'

Hier erfahren Sie, wie der IBM Cloudant-Service organisiert ist.

Script zum Video 'Innere Abläufe'

Willkommen zur Einführung IBM Cloudant ", einer 17-teiligen Videoserie, die Ihnen einen Überblick über IBM Cloudant gibt.

Dieses Video ist Teil 17 – Unter der Haube.

Sehen wir uns an, wie ein IBM Cloudant-Service organisiert wird: Diese Übersicht gilt für die IBM Cloudant-Services, die CouchDB 2 und 3 zugeordnet sind. CouchDB 4 basiert auf einer anderen Technologie.

IBM Cloudant ist eine verteilte Datenbank mit Daten, die um einen Cluster von Speicherknoten gespeichert werden. Stellen Sie sich den IBM Cloudant Service als Ring von Knoten, in diesem Fall zwölf, vor. Jeder Knoten kann eingehende API-Aufrufe verarbeiten und jeder Knoten ist zum Speichern einer Reihe von Daten zuständig: Shards und zugeordnete sekundäre Indizes der Datenbanken, die im Cluster vorhanden sind.

Wenn Daten in IBM Cloudantgeschrieben werden, verarbeitet einer der Knoten im Ring die Anforderung: Sein Job ist es, drei Kopien der Daten anzuweisen, die in drei Speicherknoten gespeichert werden sollen. Die Daten werden in IBM Cloudantin dreifacher Ausfertigung gespeichert, so dass jeder Shard einer Datenbank mehrmals gespeichert wird, und zwar häufig in den Verfügbarkeitszonen einer Region.

Wenn Sie einen API-Aufruf zum Schreiben von Daten erstellen und eine Antwort zurückerhalten, schreiben wir die Daten auf mindestens zwei der drei Speicherknoten. Daten werden auf Platte geschrieben und nicht im Hauptspeicher zwischengespeichert, wo sie bereinigt werden würden. Wir betrachten dieses Verfahren als zu risikobehaftet und anfällig für Datenverluste.

Wenn Sie eine Datenbank erstellen, werden mehrere Datenbankshards erstellt (standardmäßig 16), die in einem Cluster verteilt sind. Es gibt drei Kopien von jedem Shard, was 48 Shard-Kopien entspricht.

Sie sehen keine dieser Aktivitäten. Die Aktivität wird für Sie transparent gehandhabt, wenn Sie eine Datenbank erstellen.

Was geschieht, wenn ein Knoten heruntergefahren wird oder aus Wartungsgründen neu gestartet werden muss? Der Rest des Clusters wird weiterhin normal ausgeführt. Die meisten Shards haben noch drei Kopien von Daten, aber einige haben nur zwei. API-Aufrufe funktionieren weiterhin normal, es werden nur zwei Kopien der Daten geschrieben.

Selbst wenn zwei Knoten nach unten gehen, haben die meisten Shards noch drei Kopien, einige haben zwei, und einige haben eine. Schreibvorgänge werden weiterhin ausgeführt, obwohl der HTTP-Antwortcode angibt, dass das Quorum von zwei Knotenbestätigungen nicht erreicht wurde.

Analog verhält es sich mit den Lesevorgängen. Der Service bleibt auch bei einem fehlgeschlagenen Knoten aktiv. Ein fehlgeschlagener Knoten ist kein Problem.

Es können auch weitere Knoten ausfallen. Wenn eine Kopie jedes Knotens vorhanden ist, funktioniert die API weiterhin.

Wenn ein Knoten zurückkehrt, erfasst er alle verpassten Daten von seinen Peers und kehrt dann in den Service zurück, verarbeitet API-Aufrufe und antwortet auf Abfragen für Daten.

Die diese Konfiguration hat zur Folge, dass IBM Cloudant eine mögliche Konsistenz aufweist. Jeder Knoten kann eine Anforderung bearbeiten. Daten werden um Knoten herum verteilt, ohne die Art von Sperren, die man in einer relationalen Datenbank sehen könnte.

IBM Cloudant favorisiert die Verfügbarkeit über Konsistenz: Es wäre eher ein Up-und Antwort-API-Aufruf als inaktiv zu sein, weil es keine Konsistenzgarantien bieten kann. (Eine relationale Datenbank wird häufig auf die entgegengesetzte Weise konfiguriert: Sie arbeitet in einer konsistenten Weise oder überhaupt nicht.) Das Ergebnis einer möglichen Konsistenz für einen Entwickler ist, dass Ihre App in kurzer Zeit nicht read its writes darf. Möglicherweise gibt es ein kleines Zeitfenster, in dem eine ältere Version eines Dokuments als die von Ihnen aktualisierte Version angezeigt werden kann. Schließlich fließen die Daten um den Cluster herum, und in den meisten Fällen stellt der Quorummechanismus die Illusion der Konsistenz dar, aber es ist am besten, sich nicht darauf zu verlassen.

In CouchDB 4 und in IBM Cloudant Services, die auf dieser Codeversion basieren, wird ein anderes Konsistenzmodell verwendet.

Wenn in Ihrem Datenmodell ein Dokument über und über in einem kurzen Zeitfenster aktualisiert werden muss, ist es möglich, dass mehrere Schreibvorgänge für dieselbe Revisionsnummer akzeptiert werden. Diese Schreibvorgänge führen zu einer Verzweigung im Revisionsbaum-bekannt als Konflikt. Im vorliegenden Beispiel wurde Revision 2 auf zwei Arten geändert, was dazu führt, dass Revision 3 zweimal vorhanden ist. Es ist möglich, Konflikte programmgesteuert aufzulösen, aber sie müssen vermieden werden, da sie unter extremen Umständen zu Leistungsproblemen führen können.

Konflikte können auch auftreten, wenn Sie die Replikation verwenden und ein Dokument auf unterschiedliche Weise geändert wird. Anschließend werden die in Konflikt stehenden Revisionen mithilfe der Replikation zusammengeführt. IBM Cloudant entfernt in diesem Szenario keine Daten. Eine winning-Revision wird ausgewählt, aber auf die nicht ausgewählten Revisionen kann zugegriffen werden und Ihre Anwendung kann den Konflikt lösen, indem sie einen neuen Gewinner auswählt, unerwünschte Revisionen löscht oder jede andere von Ihnen gewünschte Aktion ausführt. Ein Konflikt ist keine Fehlerbedingung. Er ist ein Nebeneffekt, der sich daraus ergibt, dass es nicht miteinander verbundene Kopien von Daten gibt, die ohne Sperrung geändert werden können. IBM Cloudant behandelt Konflikte, indem die Änderungen nicht gelöscht werden, sondern sie als Konflikt gespeichert werden.

Wenn Sie ein Dokument auf Konflikte überprüfen möchten, fügen Sie einfach ?conflicts=true beim Abrufen eines einzelnen Dokuments hinzu. Im Array _conflicts sind alle Konfliktrevisionen aufgelistet.

Unerwünschte Revisionen können mit der normalen Operation DELETE entfernt werden. Geben Sie dabei das rev-Token der zu löschenden Revision an. Zum Beseitigen von kollidierenden Revisionen kann auch die Massendaten-API verwendet werden, sogar zum Entfernen mehrerer Konflikte in demselben Dokument.

Zusammenfassend lässt sich sagen, dass IBM Cloudant ein verteilter Service ist, der Datenbanken speichert, die in mehrere Shards aufgeteilt sind, wobei drei Kopien jedes Shards auf einen Ring von Speicherknoten verteilt sind. IBM Cloudant ist sukzessive konsistent, das heißt, die hohe Verfügbarkeit hat Priorität gegenüber einer hohen Konsistenz.

Vermeiden Sie das Schreiben in dasselbe Dokument über und über, um Konflikte nicht zu erstellen. Obwohl Konflikte in Replikationssituationen manchmal unvermeidlich sind.

Machen Sie sich die sukzessive Konsistenz zu Nutzen – versuchen Sie nicht, IBM Cloudant konsistent zu machen.

IBM Cloudant Produkte, die auf CouchDB 4 basieren, können ein anderes Konsistenzmodell aufweisen.

Damit ist dieser Kurs abgeschlossen. Weitere Informationen finden Sie in der IBM Cloudant-Dokumentation und im Blog.