Mehrere Ansichten in demselben Entwurfsdokument

Wenn Sie verschiedene Ansichten in demselben Entwurfsdokument definieren, werden sie effektiv zum selben Zeitpunkt erstellt. Jedes Dokument wird nur einmal gelesen und durchläuft die 'map'-Funktion jeder Ansicht. Wenn Sie diesen Ansatz verwenden, beachten Sie, dass durch das Ändern eines Entwurfsdokuments alle vorhandenen MapReduce-Ansichten ungültig werden, die in dem Dokument definiert sind. Durch diesen Prozess werden die MapReduce-Ansichten auch dann ungültig, wenn einige der Ansichten unverändert bleiben.

Falls MapReduce-Ansichten unabhängig voneinander geändert werden müssen, platzieren Sie ihre Definitionen in verschiedene Entwurfsdokumente.

Dieses Verhalten gilt nicht für Lucene-Suchindizes. Sie können innerhalb desselben Entwurfsdokuments geändert werden, ohne dass andere, nicht geänderte Indizes in demselben Dokument ungültig werden.

Änderungen an einem Entwurfsdokument verwalten

Angenommen, zu einem bestimmten Zeitpunkt in der Zukunft möchten Sie das Design der Ansicht ändern. Aber statt zum eigentlichen Zeitmarkenergebnis zurückzukehren, sind Sie nur an der Anzahl der Dokumente interessiert, die den Kriterien entsprechen. Um diese Anzahl zu erreichen, bleibt die 'map'-Funktion unverändert, Sie verwenden jedoch die reduce-Funktion _count.

Beispiel für ein Entwurfsdokument, das eine 'reduce'-Funktion verwendet:

{
    "_id": "_design/fetch",
    "_rev": "2-a2324c9e74a76d2a16179c56f5315dba",
    "views": {
        "by_ts": {
            "map": "function(doc) {
                if (doc.ts) {
                  emit( doc.ts, null);
                }
            }
        }",
        "reduce": "_count"
    },
    "language": "javascript"
}

Wenn dieses Entwurfsdokument gespeichert wird, macht IBM Cloudant den alten Index vollständig ungültig und startet die Erstellung eines völlig neuen Index, wobei jedes einzelne Dokument iteriert wird. Wie bei der ursprünglichen Erstellung hängt die dafür erforderliche Zeit von der Anzahl der Dokumente in der Datenbank ab. Zudem werden alle eingehenden Abfragen dieser Ansicht bis zur Fertigstellung blockiert.

Aber es gibt ein Problem...

Wenn eine Anwendung in Echtzeit auf diese Ansicht zugreift, entsteht möglicherweise ein Bereitstellungsdilemma:

• Version 1 des Codes, die auf dem ursprünglichen Entwurfsdokument basiert, funktioniert unter Umständen nicht mehr, weil die alte Ansicht ungültig gemacht wurde.
• Version 2 des Codes verwendet das neue Entwurfsdokument. Diese Version kann nicht sofort freigegeben werden, da die Erstellung der neuen Ansicht noch nicht abgeschlossen ist. Denken Sie daran, dass der Erstellungsprozess länger dauert, wenn die Datenbank viele Dokumente enthält.
• Ein weniger augenfälliges Problem für den Code ist, dass Versionen 1 und 2 verschiedene Ergebnisdaten von der Ansicht erwarten: Version 1 erwartet eine Liste von passenden Dokumenten, während Version 2 eine durch die 'reduce'-Funktion bearbeitete Anzahl von Ergebnissen erwartet.

Änderungen an Entwurfsdokumenten koordinieren

Dieses Problem mit dem Änderungsmanagement können Sie auf zwei Arten angehen.

Move and switch Tools

Das Node.js-Befehlszeilenscript couchmigrate automatisiert die Prozedur für das Move and switch. Es kann mit dem folgenden Befehl installiert werden:

npm install -g couchmigrate

Um das Skript couchmigrate zu verwenden, definieren Sie zunächst die URL der Instanz CouchDB/{{site. data.keyword.cloudant_short_notm }}, indem Sie eine Umgebungsvariable namens COUCH_URL setzen. Führen Sie den folgenden Befehl aus, um die URL für die IBM Cloudant-Instanz zu definieren:

export COUCH_URL=https://127.0.0.1:5984

Die URL muss mit https:// beginnen und kann Authentifizierungsdaten enthalten. Führen Sie den folgenden Befehl aus, um die URL für die IBM Cloudant-Instanz mit Authentifizierungsnachweisen zu definieren:

export COUCH_URL="https://$ACCOUNT:$PASSWORD@$HOST.cloudant.com"

Wenn Sie ein Entwurfsdokument im JSON-Format haben, das in einer Datei gespeichert ist, können Sie den Befehl 'migrate' ausführen.

In diesem Beispiel verwendet db gibt den Namen der zu ändernden Datenbank an, und dd gibt den Pfad zu der Entwurfsdokumentendatei an. Führen Sie den Befehl couchmigrate aus:

couchmigrate --db mydb --dd /path/to/my/dd.json

Das Script koordiniert die Prozedur Move and switch und wartet, bis die Ansicht erstellt ist, bevor es zurückkehrt. Falls das eingehende Entwurfsdokument dem etablierten entspricht, kehrt das Script praktisch sofort zurück.

Der Quellcode für das Script ist hier verfügbar: couchmigrate.

Parameter stale

Falls ein Index abgeschlossen wurde, aber neue Datensätze zur Datenbank hinzugefügt werden, wird das Update des Index im Hintergrund geplant. Der Status der Datenbank ist im folgenden Diagramm dargestellt:

Beim Abfragen der Ansicht stehen die folgenden Auswahlmöglichkeiten zur Verfügung:

• Beim Standardverhalten wird sichergestellt, dass der Index aktuell ist, d. h. er enthält die aktuellen Dokumente in der Datenbank, bevor die Antwort zurückgegeben wird. Wenn Sie die Ansicht abfragen, indiziert IBM Cloudant zuerst die 250 neuen Dokumente und gibt dann die Antwort zurück.
• Alternativ können Sie den Parameter stale=ok zum API-Aufruf hinzufügen. Der Parameter veranlasst, dass die bereits indizierten Daten zurückgegeben und neue Aktualisierungen nicht berücksichtigt werden. return me the data that is already indexed. I don't care about the latest updates. Mit anderen Worten, wenn Sie die Ansicht mit stale=ok abfragen, gibt IBM Cloudant die Antwort sofort zurück, ohne zusätzliche Neuindexierung.
• Eine zweite Alternative ist das Hinzufügen des Parameters stale=update_after zum API-Aufruf. Der Parameter veranlasst, dass die bereits indizierten Daten zurückgegeben und neue Aktualisierungen nicht berücksichtigt werden. return me the data that is already indexed, and then reindex any new documents. Mit anderen Worten, wenn Sie die Ansicht mit stale=update_after abfragen, gibt IBM Cloudant die Antwort sofort zurück und plant dann eine Hintergrundtask zum Indizieren der neuen Daten.

stale=ok oder stale=update_after hinzuzufügen, kann eine gute Methode sein, Antworten schneller von einer Ansicht zu bekommen, aber sie geht auf Kosten der Aktualität der Daten.

Im Standardverhalten wird die Arbeitslast gleichmäßig auf die Zugriffsknoten im IBM Cloudant-Cluster verteilt. Wenn Sie die alternativen Optionen stale=ok oder stale=update_after nutzen, wird unter Umständen eine Untergruppe von Clusterknoten bevorzugt bedient, um konsistente Ergebnisse aus einer sukzessive konsistenten Gruppe zurückzugeben. Der Parameter stale bietet keine perfekte Lösung für alle Anwendungsfälle. Er kann jedoch zeitgerechte Antworten zu sich schnell ändernden Datengruppen bereitstellen, wenn Ihre Anwendung nicht aktuelle Ergebnisse akzeptiert. Wenn die Änderungsrate Ihrer Daten gering ist, führt das Hinzufügen von stale=ok oder stale=update_after zu keinem Leistungsvorteil, sondern u.U. zu einer ungleichmäßiger verteilten Arbeitslast in größeren Clustern.

Vermeiden Sie nach Möglichkeit die Verwendung von stale=ok oder stale=update_after, da das Standardverhalten die aktuellsten Daten bereitstellt und sie im gesamten Cluster verteilt. Sie können eine Client-App darauf aufmerksam machen, dass eine umfangreiche Datenverarbeitungstask (z. B. eine regelmäßige Massenaktualisierung) in Bearbeitung ist, indem während dieser Zeit temporär zu stale=ok gewechselt wird. Anschließend kann die App zum Standardverhalten zurückkehren.

Obwohl die Option stale weiterhin verfügbar ist, müssen stattdessen die hilfreicheren Optionen stable und update verwendet werden. Weitere Informationen finden Sie im Abschnitt Auf eine veraltete Ansicht zugreifen.