Remote AE-Verarbeitung
Die entfernte AE, die an einem AE-Verbindungspunkt lauscht, erhält vom Netezza Meldungen, dass eine neue Instanz einer SQL-Funktion aufgerufen wird. Die entfernte AE erstellt dann einen neuen Thread, holt sich einen Thread aus einem Pool oder forkt einen neuen Prozess, um den SQL-Funktionsaufruf zu bearbeiten. Der Thread oder Prozess, der die SQL-Funktion bearbeitet, erstellt eine Datenverbindung für diese Funktion. Nach erfolgreicher Beendigung der Anfrage ist es wichtig, dass die entfernte ZB die Datenverbindung mit "done" aufruft und sie schließt. Tritt ein Fehler auf, ist es wichtig, dass die ZB die Datenverbindung mit "Fehler" aufruft und sie dann schließt. Ein und derselbe Thread oder Prozess kann für die serielle Verarbeitung von SQL-Funktionsaufrufen verwendet werden, so dass es möglich ist, einen Thread-Pool oder einen Prozess-Pool zu verwenden.
Im Folgenden werden vier mögliche Szenarien beschrieben, die bei der Umsetzung von Agrarumweltmaßnahmen auftreten können.
Szenario 1: Sprachunterstützung für Threads
Unter Verwendung einer Sprache, die Threads unterstützt, möglicherweise Java oder C++ mit POSIX, führen Sie eine Instanz des AE-Daemons auf jeder SPU und eine auf dem Host aus. Jede SQL-Funktion wird über einen Thread aus einem Pool abgewickelt, so dass die Anfragen gleichzeitig bearbeitet werden. In diesem Fall besteht die Adresse des AE-Verbindungspunkts nur aus der Zeichenfolge name und sonst nichts. Die entfernte AE hat einen Hörer an dieser Adresse.
Szenario 2: Die Sprache unterstützt keine Threads
Wenn Sie eine Sprache verwenden, die Threads nicht oder nur unzureichend unterstützt, oder wenn Threads unerwünscht sind, verwenden Sie denselben Verbindungspunkt wie in Szenario 1. Um SQL-Funktionen zu verarbeiten, müssen Sie die SQL-Funktion in dem neuen Prozess aufspalten und bearbeiten. In diesem Fall lauscht der abhörende Prozess auf AE-Umgebungen, d. h. auf Sätze von AE-Umgebungsvariablen, die eine AE-SQL-Funktionsanforderung beschreiben. Nach dem Forking kann die AE-Umgebung verwendet werden, um eine AE-Datenverbindung herzustellen.
Szenario 3: Verwendung einer einzigen Instanz
Die Lösungen für die ersten beiden Szenarien sehen vor, dass Sie bei der Verwendung der Datenbank eine einzige Instanz der entfernten AE pro SPU oder Host verwenden. Wenn Sie aus Sicherheits- oder anderen Gründen nicht möchten, dass andere Personen AEs gemeinsam nutzen, können Sie der Adresse der entfernten AE eine Sitzungs-ID hinzufügen.
Dazu setzen Sie NZAE_REMOTE_NAME_SESSION=1 (oder die register_ae-Option --rsession) bei der Registrierung der SQL-Funktion und geben die Sitzungs-ID an, wenn Sie den Verbindungspunkt in der entfernten AE erstellen.
Beachten Sie, dass Sie weiterhin Threads verwenden oder neue Prozesse forken müssen, da weiterhin mehrere gleichzeitige SQL-Funktionsaufrufe empfangen werden. Dies ist darauf zurückzuführen, dass eine SPU aus mehreren Datenscheiben besteht und die Funktionsaufrufe gleichzeitig von jeder Datenscheibe ausgehen.
Sie müssen die entfernte AE starten, nachdem die Sitzung begonnen hat, und die entfernte AE beenden, bevor sie endet. (Das Starten und Stoppen von entfernten AEs wird in Starten einer entfernten analytischen ausführbaren Datei behandelt) Jede Sitzung verwendet ihre eigene Instanz des entfernten AE-Prozesses.
Szenario 4: Datenscheibe in der entfernten AE-Adresse
Es gibt zwei mögliche Ansätze, die Datenscheiben in der entfernten AE-Adresse verwenden. Die erste besteht darin, auf jeder SPU eine AE pro Dataslice zu starten. Die SQL-Funktion wird mit NZAE_REMOTE_NAME_DATA_SLICE=1 registriert (oder mit der register_ae-Option --rdataslice). Jede entfernte AE kann einen API-Aufruf verwenden, um die Datenscheibe zurückzugeben, für die sie gestartet wurde. Es lauscht dann auf eine entfernte Adresse, die aus Stringname und Datenscheiben-ID besteht. Wenn es auf einer SPU vier Dataslices gibt, dann gibt es auch vier Remote-AE-Prozesse. Jede entfernte AE gibt nur Daten für ihre Datenscheibe ein.
Dieser Ansatz eignet sich gut für eine Programmiersprache wie C++, funktioniert jedoch möglicherweise nicht so gut, wenn jeder entfernte AE-Prozess sehr große Ressourcenanforderungen hat oder in einer Programmiersprache mit einer ressourcenintensiven Laufzeitumgebung geschrieben ist. In dieser Situation gibt es einen schweren AE-Prozess pro Datenscheibe; insgesamt können die mehreren Prozesse zu viele Systemressourcen, insbesondere Speicher, verbrauchen.
Der andere Ansatz ist eine komplexere Methode zur Verwendung von Datenscheiben in der entfernten AE-Adresse. Ein einzelner entfernter AE-Prozess kann mehrere Benachrichtigungsverbindungen gleichzeitig nutzen, solange sie unterschiedliche Adressen haben. In Szenario 1 wurde für den gesamten Prozess ein einziger Benachrichtigungshörer mit dem Namen einer entfernten AE-Adressleiste verwendet. Betrachten Sie für dieses Szenario den Fall, dass Sie eine einzige Abfrage ausführen, die auf den SPUs läuft. Eine entfernte AE, die auf einer SPU läuft, erhält mehrere SQL-Funktionsaufrufe, einen von jeder Datenscheibe, auf der SPU. Die Benachrichtigungen erfolgen gleichzeitig, werden aber vom Hörer seriell verarbeitet. In Szenario 1 wurde jede Meldung empfangen und einem Thread im Pool zugewiesen, um die SQL-Funktion zu bedienen. Die Datenverbindungen werden gleichzeitig verarbeitet, aber einige beginnen vor anderen, da die Meldungen einzeln verarbeitet werden.
Aus Gründen der Effizienz sollten Sie einen Benachrichtigungslistener pro Dataslice verwenden. Bei vier Dataslices auf einer SPU erstellen Sie vier Threads, von denen jeder einen AE-Verbindungspunkt abhört, der mit einer aus Remote String Name und Dataslice ID gebildeten Adresse angegeben wird.
Die SQL-Funktion wird weiterhin mit NZAE_REMOTE_NAME_DATA_SLICE=1 mit der register_ae-Option --rdataslice registriert.
{ name=MY_REMOTEAE, data slice id=17 }
{ name=MY_REMOTEAE, data slice id=18 }
{ name=MY_REMOTEAE, data slice id=19 }
{ name=MY_REMOTEAE, data slice id=20 }Wenn ein Listening-Thread eine Benachrichtigung über einen neuen SQL-Funktionsaufruf erhält, ruft er einen Benachrichtigungs-Thread aus dem Pool ab und weist ihn dieser SQL-Funktionsanforderung für die zugewiesene Datenscheibe zu.
{ name=MY_REMOTEAE }Es gibt keinen direkten API-Aufruf, um festzustellen, wie der einzelne AE-Prozess, der auf der SPU läuft, bestimmt, welche Datenscheiben abgehört werden sollen. Es gibt eine Datenbankansicht namens _v_dual_dslice, die einen Datensatz für jede Datenscheibe für die gesamte Datenbank enthält. Zum Beispiel:
SELECT * FROM _v_dual_dslice;
DSID
------
1
4
2
3
…Um diese Ansicht zu verwenden, registrieren Sie eine skalare Funktion, die eine Verbindung zur entfernten AE über die Adresszeichenfolge name herstellt. Der Skalar benötigt ein ganzzahliges Argument und wird mit der Spalte DSID in der Ansicht _v_dual_dslice als Argument aufgerufen. Nach dem Start der entfernten AE wird diese skalare Funktion aufgerufen. Die entfernte AE auf jeder SPU erhält eine Meldung für jede Datenscheibe. Wenn die entfernte ZB die Datenverbindung öffnet, erhält sie die Datenscheibe für diese Anforderung und verwendet diese Scheibe, um den Listener für die Adresszeichenkette name, Datenscheibe in einem neuen Thread zu starten. Die skalare Funktion wird normal verarbeitet, um einen Wert zurückzugeben und die Datenverbindung zu schließen. Da die skalare Funktion zur Bereitstellung der entfernten AE-Informationen verwendet wird, ist der Rückgabewert irrelevant.
Zusammenfassend lässt sich sagen, dass Sie in Szenario 1 einen Hörer verwendet haben. In Szenario 4, Ansatz eins, haben Sie einen entfernten AE-Prozess pro Datenscheibe mit jeweils einem Listener verwendet. In Szenario 4, Ansatz zwei, haben Sie fünf verschiedene Benachrichtigungslistener in einem einzigen entfernten AE-Prozess verwendet.