Data Points: Mein erster Eindruck von Azure Search (kurze exemplarische Vorgehensweise)

Erstellen eines neuen Suchdiensts

Nachdem Sie das Hinzufügen einer neuen Ressource im Azure-Portal ausgewählt haben, wird Search in der Kategorie „Web und mobil” angezeigt. Das einfachste Verfahren besteht jedoch im Eingeben von „search“ in das Suchfeld. (Ganz schön meta, oder nicht?) Für das Einrichten des Diensts ist es erforderlich, einen Dienstnamen anzugeben, der zum ersten Teil seiner URL wird. Ich verwende „thedatafarm“. Dies führt zur URL „thedatafarm.search.windows.net“. Wie bei jeder Ressource müssen Sie diese Angabe einer vorhandenen Ressourcengruppe hinzufügen oder eine neue Ressourcengruppe erstellen. Noch ist nichts vorhanden, das sich auf meinen Dienst bezieht. Ich erstelle also eine neue Ressourcengruppe mit dem Namen „datafarmsearchgroup“ in „USA, Osten“. Die letzten Informationen, die zum Einrichten der Ressource erforderlich sind, beziehen sich auf das Auswählen eines Tarifs. Für Azure Search ist ein kostenloser Tarif verfügbar, der sich großartig zum Testen des Diensts eignet. Dieser Tarif erlaubt 10.000 Dokumente sowie 50 MB Speicher ohne Skalierung. Sie dürfen einen kostenlosen Search Service in Ihrem Abonnement einrichten. Stellen Sie sicher, dass Sie auf die Schaltfläche „Auswählen“ klicken, nachdem Sie den Free-Tarif ausgewählt haben. Andernfalls erhalten Sie den Standard-Tarif. Raten Sie mal, wie ich das herausgefunden habe.

Wenn Sie auf „Erstellen“ klicken, überprüft Azure Ihre Einstellungen. Wenn alles passt, sollte es nur wenige Sekunden dauern, bis der Dienst live geschaltet ist.

Sie verfügen nun über einen Dienst. Aber nach was möchten Sie suchen? Während meiner ersten Runde mit Azure Search habe ich viel Zeit damit verbracht, nach einem durchsuchenswerten Dataset Ausschau zu halten und dann herauszufinden, wie ich diese Daten mit meinem Dienst teilen kann. Das hat zwar Spaß gemacht, aber zurückblickend wünschte ich, ich hätte für den Einstieg mit einem der Beispieldatasets begonnen, die Azure Search bereitstellt. Dieses Mal bin ich schlauer.

Die Suche wird nicht in Daten, sondern in den Indizes der Daten ausgeführt, und die Indizes liegen in der Form von Dokumenten vor. Für Benutzer relationaler Datenbanken ähnelt ein Index fast einer Tabelle, während ein Dokument einer einzelnen Zeile in einer Tabelle ähnelt: einer einzelnen Dateneinheit. Der erste Schritt besteht daher im Erstellen eines Index der Daten, die Sie durchsuchen möchten. Die Daten können aus einer Vielzahl von Ressourcen stammen. Das Erstellen von Indizes aus Daten, die in einem anderen Azure-Dienst gespeichert sind, ist der schnellste Weg. Am einfachsten geschieht dies jedoch mit Diensten im gleichen Abonnement wie die Suche. Sie können auf eine vorhandene Azure DocumentDB, eine Azure SQL-Datenbank oder einen SQL Server verweisen, der in einem virtuellen Azure-Computer gespeichert ist. Während ich dies schreibe, ist Unterstützung für Azure Table Storage und Azure Blob Storage als Preview verfügbar. Azure Search bietet Ihnen Zugriff auf einige vordefinierte Beispieldaten. Sie beginnen daher nicht, indem Sie auf die Option „Index hinzufügen“ klicken, sondern indem Sie „Daten importieren“ auswählen. Auf diese Weise wird auch der erste Index für Sie erstellt.

Wählen Sie auf dem Blatt „Daten importieren“ (siehe Abbildung 1) die Option „Beispiele“ und dann die Daten „realestate-us-sample“ aus. Während ich diesen Artikel schreibe, ist dies die einzige Option. Es sind aber weitere Beispiele angekündigt. Sie können anhand des Symbols erkennen, dass es sich um eine Azure SQL-Datenbank handelt. Sie erstellen daher einen Index von Dokumenten aus den relationalen Daten. Search transformiert die Daten in die Struktur, die für die Indizierung erforderlich ist. Dieser Vorgang besteht aus drei Schritten. Zuerst wählen Sie die Datenquelle aus, dann definieren Sie den Index, und schließlich importieren Sie die Daten in Ihren Index.

Abbildung 1: Azure Search weiß bereits, wie eine Verbindung mit Daten hergestellt wird, die in Azure gespeichert sind

Definieren eines Index

Nachdem Sie das Beispiel ausgewählt haben, zeigt das Portal ein Raster mit einer Liste aller Felder an, die in der Beispieldatenquelle erkannt wurden. Dies ist der Schritt, in dem Sie Ihren Index definieren. In diesem Fall hat der Assistent des Diensts den Index für Sie vordefiniert (Abbildung 2). Dies ist Ihre einzige Möglichkeit zum Optimieren des Index, bevor die Daten importiert werden. Das erneute Definieren eines Index bedeutet das erneute Importieren Ihrer Daten. Dies kann in einer Produktionsumgebung nicht wünschenswert sein.

Abbildung 2: Erste Zeilen des Standardindex, der aus den Daten „realestate-us-sample“ erstellt wurde

Ein Index für eine Azure SQL-Datenbank oder einen SQL Server kann sich nur auf eine einzelne Tabelle oder Ansicht beziehen. Wenn Sie einen nicht relationalen Datenspeicher als Quelle verwenden, erfasst Search die vollständigen Diagramme, die in einem bestimmten Dokument oder Blob gespeichert sind. Was Sie hier sehen, stammt also aus der einzelnen Tabelle in der Datenbank. Es sind 26 Felder verfügbar, und Sie können im Raster definieren, wie jedes Feld mithilfe der Optionen „Abrufbar“, „Filterbar“, „Sortierbar“, „Facettenreich“ und „Durchsuchbar“ in die Suche involviert wird. Schon jetzt können Sie erkennen, dass Search Flexibilität bietet, die über das einfache Eingeben eines Suchbegriffs hinausgeht. Im Raster finden Sie Spalten, mit denen Sie definieren können, wie das Feld in der Suche verwendet wird. Der Index-Assistent hat einige Standardeinstellungen für Sie ausgewählt.

Gegebenenfalls müssen Sie nicht in der Lage sein, den Suchvorgang für alle Felder auszuführen. Es sind z. B. sieben Beschreibungsfelder vorhanden: eines in englischer Sprache und sechs in anderen Sprachen. Wenn die Anwendung, die diese Ressource nutzt, nur von Personen in Quebec verwendet wird und nur die Unterstützung französischsprachiger und englischsprachiger Suchen geplant ist, könnten Sie die anderen fünf Felder aus dem Suchindex löschen. Klicken Sie zu diesem Zweck im Portal mit der rechten Maustaste auf das Feld, und wählen Sie dann „Löschen“ aus.

Das Definieren von Indizes erfordert Überlegung und Planung. Ich begnüge mich jedoch hier mit der Auswahl, die das Importiertool getroffen hat. Nehmen Sie sich jedoch trotzdem etwas Zeit, um das Raster zu studieren und zu verstehen, was definiert wird. Beachten Sie z. B., dass die Beschreibungsfelder durchsuchbar und abrufbar, nicht jedoch filterbar oder sortierbar sind. Im Gegensatz dazu sind einfache, skalare Felder wie Quadratfuß („sqft“) und Preis sortierbar und filterbar.

Verwenden eines Indexers zum Importieren der Daten

Nachdem der Index definiert wurde, können Sie im nächsten Schritt die Daten importieren. Die Indexdefinition besitzt enorme Auswirkungen darauf, wie die Daten importiert werden. Erinnern Sie sich daran, dass die Daten in den Index abgerufen werden und kein Index auf die Daten angewendet wird. Wie viel Zeit für diesen Vorgang erforderlich ist, hängt von der Größe, der Struktur und dem Speicherort der Daten sowie von der Indexdefinition ab. Für die Indizierung sieben verschiedener Beschreibungsfelder ist z. B. mehr Zeit erforderlich als für die Indizierung von nur zwei Beschreibungsfeldern.

Vielleicht fragen Sie sich schon, was geschieht, wenn sich die Daten in Ihrer Datenquelle ändern. Azure Search verfügt über einige Mechanismen zum Aktualisieren des Index. In vielen Fällen kann dieser Vorgang als Teil der Azure Search-Dienstdefinition automatisiert werden. Die Regeln und Parameter für diese Änderungserkennung und Datenverschiebung sind je nach Datenquelle unterschiedlich. Weitere Informationen dazu finden Sie in der Dokumentation.

Nun fordert der Assistent Sie auf, einen Indexer zu erstellen. Ein Indexer ist ein Crawler, der Daten aus der Datenquelle liest und den Zielindex dann mit Daten auffüllt. Er führt die anfängliche Indizierung aus und aktualisiert außerdem den Index basierend auf einem definierten Zeitplan bzw. bei Bedarf. Da ich als Datenquelle eine Azure SQL-Datenbank ausgewählt habe, verwendet der Assistent einen speziell definierten Indexer, der weiß, wie eine Azure SQL-Datenbank durchforstet wird. Wie jede Ressource benötigt auch der Indexer einen Namen.  Ich habe meinen Indexer „defaultindexer“ genannt. Dies mag keine bewährte Methode bei der Benennung sein, reicht aber für diese Demonstration aus.

Wenn Sie auf „OK“ klicken, beginnt die Indizierung. Das Portal zeigt eine Popupbenachrichtigung an, die Sie informiert, dass der Vorgang gestartet wurde, und Sie können seinen Fortschritt auf dem Blatt „Indexer“ verfolgen. Mein Import wurde so schnell ausgeführt, dass er bereits abgeschlossen war, als ich hinsah. In Abbildung 3 habe ich auf der Seite im Blatt für den thedatafarm-Suchdienst nach unten gescrollt. Wie Sie sehen können, ist das Feld „Indexer“ markiert. Da ich darauf geklickt habe, ist das Blatt „Indexer“ nach rechts geöffnet und zeigt an, dass „defaultindexer“ seinen Auftrag beendet und 4.959 Suchdokumente aus der Datenquelle erstellt hat.

Abbildung 3: Das Blatt „Indexer“ in meinem Search Service zeigt den Status des Datenimports an

Überprüfen der durchsuchbaren Dokumente

Nun ist der Index bereit für die Suche. Der Search-Explorer stellt eine geeignete Möglichkeit dar, ein Gefühl für die Suche zu entwickeln und Suchvorgänge direkt vor dem Implementieren in Ihrem Code zu testen. Wenn Sie schon einmal mit OData gearbeitet haben, fällt Ihnen vielleicht auf, dass für das Ausdrücken von Filterung, Sortierung und Paging OData-Syntax verwendet wird. Die Suche selbst kann mithilfe von zwei Abfragesyntaxen ausgeführt werden. Die Standardsyntax wird als einfache Syntax bezeichnet, die andere Syntax ist die Lucene-Abfragesyntax.

Ich empfehle Ihnen für Ihren ersten Suchvorgang, einfach auf die Schaltfläche „Suchen“ zu klicken, ohne eine Eingabe im Feld „Abfragezeichenfolge“ vorzunehmen. Auf diese Weise werden alle Daten zurückgegeben (auf Seiten mit jeweils 50 Einträgen). Sie sollten einen Blick auf diese Daten werfen, weil es sich um eine nicht vertraute Datenquelle handelt. Außerdem bekommen Sie ein Gefühl für die Strukturierung der Daten.

Die Ergebnisse beginnen mit einem Header, der den Index beschreibt. Das gesamte Array von Dokumenten ist in ein Tag „value” als Wrapper eingeschlossen, und jedes Dokument beginnt mit einem Suchbewertungswert. Anschließend wird jedes Feld mit seinem Wert aufgelistet.

Kombinieren der Suche mit OData-Filter und -Anzahl

Bleiben wir bei der zweiten Suche bei einem reinen Suchvorgang. Geben Sie „condominium“ in das Feld „Abfragezeichenfolge“ ein, und klicken Sie dann auf „Suchen“. Beachten Sie, dass der URI mit „&search=condominium“ endet.

Azure Search gibt standardmäßig Seiten mit Daten mit jeweils 50 Dokumenten zurück. Es ist jedoch recht schwer zu erkennen, was Sie hier erhalten. Fügen wir also einen OData-Parameter hinzu, um die Anzahl zu ermitteln. Da Sie nun mehrere Parameter verwenden, müssen Sie angeben, dass „condominium“ Teil der Suche ist. Dies ist die Abfragezeichenfolge:

$count=true&search=condominium

In den Ergebnissen (siehe Abbildung 4) können Sie nun nach der Indexbeschreibung und vor dem ersten aufgelisteten Wert sehen, dass die Anzahl der Ergebnisse 399 Dokumente umfasst. Die Suche hat jedes Feld überprüft, das der Index für die Suche definiert hat, und dann eine Anzahl für jedes Dokument zurückgegeben, in dem die Zeichenfolge „condominium” gefunden wurde. Anschließend wurden die ersten 50 dieser 399 übereinstimmenden Dokumente zurückgegeben. Wenn Sie bis nach unten scrollen, sehen Sie, dass ein URI Sie beim Abrufen der nächsten 50 Dokumente unterstützt. Dies ist ein Muster, das Ihnen ggf. bekannt vorkommt, wenn Sie bereits mit OData gearbeitet haben.

Abbildung 4: Der Anfang eines Resultsets aus einer Abfrage mit „$count“ von OData in der Anforderung; die Anzahl ist Teil des Ergebnisstamms

Stellen Sie zum Durchsuchen des Ergebnisbereichs zuerst sicher, dass sich Ihr Cursor in den Ergebnissen befindet, und verwenden Sie dann den Suchbefehl des Browsers (z. B. STRG+F). Ein spezielles Suchfeld wird als Popup angezeigt, das sich deutlich vom Suchfeld des Browsers unterscheidet. Geben Sie „condominium“ ein, und klicken Sie durch die Suchergebnisse. Sie sehen dann, dass dieses Wort in den Beschreibungs- und Tagfeldern (vielleicht auch in anderen Feldern, ich habe mir nur einige Felder angesehen) vorkommt.

Erinnern Sie sich daran, dass einige Felder im Index als filterbar definiert wurden. Ändern Sie die Abfrage so, dass ein Filter für Angebote mit drei Schlafzimmern hinzugefügt wird (also das Feld „beds“ den Wert drei aufweist). „Filter“ ist ein OData-Parameter, der ein vorangestelltes Dollarzeichen erfordert. Dies ist die neue Abfragezeichenfolge, die OData-Syntax für die Filterung verwendet:

$count=true&search=condominium&$filter=beds eq 3

Die Anzahl zeigt, dass nur noch 73 Dokumente die Bedingungen erfüllen.

Weitere Untersuchung von Azure Search

An diesem Punkt wurde mir langsam klarer, wie ich meinen Index definieren möchte. Die Aufgabe, die eine App erfüllen soll, besitzt eine großen Einfluss auf diesen Aspekt. Sie verwenden ggf. verschiedene Apps, die auf den gleichen Datenspeicher zugreifen, aber unterschiedliche Funktionen oder andere Daten in den Ergebnissen benötigen. Mit Azure Search können Sie separate Indizes erstellen, um diese unterschiedlichen Anforderungen zu erfüllen. Da jeder Index über einen eigenen Satz von Daten verfügt, verursachen die Apps untereinander keinen Konflikt bezüglich der Ressourcen. Dies könnte die Leistung verschlechtern.

Ich bevorzuge es, einen visuellen Eindruck von meiner Arbeit zu bekommen. Als ich mit meiner Erkundung von Azure Search über das Portal begonnen habe, konnte ich den Index und die Ergebnisse visualisieren. Außerdem konnte ich Abfragen testen. Aufgrund dieser Erfahrungen bin ich zuversichtlich, Azure Search in einer App mithilfe des .NET-Clients oder durch einfaches direktes Ausführen von Abfragen mit REST einsetzen zu können. Ich kann dabei meine eigenen Datenbanken oder andere Beispieldaten verwenden. Ein Experiment, an das ich mich bereits gewagt habe, war das Importieren von Daten aus dem öffentlichen Dataset, das vom Cooper-Hewitt-Museum unter bit.ly/2hrOCej bereitgestellt wird. Ich habe eine Sammlung von JSON-Dokumenten aus dem Objektdataset des Museums in eine Azure DocumentDB hochgeladen und dann einen Suchdienst und einen Index aus diesen Daten erstellt. Nach Abschluss dieses Projekts habe ich herausgefunden, dass eine der Beispielanwendungen des Azure-Teams eine ähnliche Richtung eingeschlagen hat, indem öffentlich verfügbare Daten der Tate Gallery verwendet wurden. Sie können mit der Demo des Teams unter bit.ly/2gxoHQL herumspielen, um sich weiter von der Leistungsfähigkeit von Azure Search zu überzeugen, z. B. vom Einsatz von Facettennavigation. (Facetten stellen eine andere Option dar, die beim Definieren eines Index eingerichtet werden kann.) Das Beispiel verwendet JavaScript und interagiert direkt mit Azure Search über die URIs. Der Code auf GitHub (bit.ly/2gI1ej9) ist daher nicht nur lehrreich, sondern auch ein beeindruckendes Beispiel dafür, wie einfach Ihre eigene Programmlogik sein kann, weil Azure Search die gesamte Schwerstarbeit für Sie erledigt.

Ich hoffe, dass diese ersten Einblicke in Azure Search Ihre Befürchtungen zerstreuen, dass es sich um einen großen, respekteinflößenden Dienst nur für erfahrene Azure-Experten handeln könnte. Azure wurde dafür konzipiert, Ihnen komplexe Aufgaben abzunehmen. Azure Search ist für dieses Ziel ein gutes Beispiel, weil diese Anwendung die schwierigen Aspekte des Hinzufügens von Suchfunktionen zu Ihren Apps übernimmt.

Julie Lerman ist Microsoft MVP, .NET-Mentorin und Unternehmensberaterin. Sie lebt in den Bergen von Vermont. Sie hält bei User Groups und Konferenzen in der ganzen Welt Vorträge zum Thema Datenzugriff und zu anderen .NET-Themen. Julie Lerman führt unter thedatafarm.com/blog einen Blog. Sie ist die Autorin von „Programming Entity Framework“ sowie der Ausgaben „Code First“ und „DbContext“ (alle bei O’Reilly Media erschienen). Folgen Sie ihr auf Twitter: @julielerman, und sehen Sie sich ihre Pluralsight-Kurse unter juliel.me/PS-Videos an.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Pablo Castro
Pablo arbeitet als Software Architect in der Data Group bei Microsoft. Er ist zurzeit Director of Engineering für Azure Search, ein globales Search as a Service-Skalierungsprodukt, das Bestandteil der Azure-Cloudplattform ist.