Erweiterbarkeitsarchitektur in SQL Server-Spracherweiterungen
Gilt für: 
SQL Server 2019 (15.x) und höhere Versionen
Erfahren Sie mehr über die Erweiterbarkeitsarchitektur, die für SQL Server-Spracherweiterungen verwendet wird und Ihnen das Ausführen von externem Code in SQL Server ermöglicht. In SQL Server 2019 (15.x) und späteren Versiopnen werden Java, Python und R unterstützt. Der Code wird in einer Language Runtime-Umgebung als Erweiterung der Haupt-Datenbank-Engine ausgeführt.
Hintergrund
Der Zweck des Erweiterbarkeitsframeworks besteht darin, eine Schnittstelle zwischen SQL Server und externen Sprachen bereitzustellen. Durch das Ausführen einer vertrauenswürdigen Sprache innerhalb eines von SQL Server verwalteten sicheren Frameworks können Datenbankadministratoren die Sicherheit aufrechterhalten und gleichzeitig Datenanalysten den Zugriff auf Unternehmensdaten ermöglichen.
Jede unterstützte externe Sprache kann durch Aufrufen einer gespeicherten Prozedur ausgeführt werden, und die Ergebnisse werden als tabellarische Ergebnisse direkt an SQL Server zurückgegeben. Dies vereinfacht das Verwenden der externen Sprache aus einer beliebigen Anwendung, die eine SQL-Abfrage senden und die Ergebnisse verarbeiten kann.
Architekturdiagramme
Die Architektur ist so konzipiert, dass externer Code in einem separaten Prozess von SQL Server ausgeführt wird, jedoch mit Komponenten, die intern die Kette von Anforderungen für Daten und Vorgänge auf SQL Server verwalten.
Komponentenarchitektur unter Windows:
Komponentenarchitektur unter Linux:
Zu den Komponenten gehört ein Launchpad-Dienst, der zum Aufrufen externer Runtimes (z. B. Java) und bibliotheksspezifischer Logik für das Laden von Interpretern und Bibliotheken verwendet wird.
Launchpad
SQL Server-Launchpad ist ein Dienst, der die Lebensdauer, Ressourcen und Sicherheitsgrenzen des externen Prozesses verwaltet, der für die Skriptausführung verantwortlich ist. Dies ähnelt der Art und Weise, wie die Volltextindizierung und der Abfragedienst einen separaten Host für die Verarbeitung von Volltextabfragen starten. Der Launchpad-Dienst kann nur vertrauenswürdige Startprogramme starten, die von Microsoft veröffentlicht oder zertifiziert wurden, da sie die Anforderungen hinsichtlich der Leistung und der Ressourcenverwaltung erfüllen.
Der SQL Server-Launchpad-Dienst wird unter der SQLRUserGroup ausgeführt, die AppContainers für die Ausführungsisolierung verwendet.
Für jede Instanz der Datenbank-Engine, der Sie SQL Server-Spracherweiterungen hinzugefügt haben, wird ein separater SQL Server-Launchpad-Dienst erstellt. Es gibt einen Launchpad-Dienst pro Datenbank-Engine-Instanz. Wenn Sie also über mehrere Instanzen mit externer Skriptunterstützung verfügen, haben Sie für jede Instanz einen Launchpad-Dienst. Eine Datenbank-Engine-Instanz ist an den für sie erstellten Launchpad-Dienst gebunden. Alle Aufrufe externer Skripts in einer gespeicherten Prozedur oder in T-SQL führen dazu, dass der SQL Server-Dienst den für dieselbe Instanz erstellten Launchpad-Dienst aufruft.
Zum Ausführen von Aufgaben in einer bestimmten unterstützten Sprache erhält das Launchpad ein gesichertes Workerkonto aus dem Pool und startet einen Satellitenprozess zum Verwalten der externen Runtimes. Jeder Satellitenprozess erbt das Benutzerkonto des Launchpads und verwendet dieses Workerkonto für die Dauer der Skriptausführung. Wenn Skripts parallele Prozesse verwenden, werden sie unter demselben Einzelworkerkonto erstellt.
Kommunikationskanäle zwischen Komponenten
Im folgenden Abschnitt werden die Kommunikationsprotokolle zwischen Komponenten und Datenplattformen beschrieben.
TCP/IP
Standardmäßig wird für die interne Kommunikation zwischen SQL Server und SQL Satellite TCP/IP verwendet.
ODBC
Für die Kommunikation zwischen externen Data Science-Clients und einer SQL Server-Remoteinstanz wird ODBC verwendet. Das Konto, das Skriptaufträge an SQL Server übermittelt, muss über beide Berechtigungen zum Herstellen einer Verbindung mit der Instanz und zum Ausführen externer Skripts verfügen.
Außerdem benötigt das Konto abhängig von der Aufgabe möglicherweise die folgenden Berechtigungen zum:
- Lesen der vom Auftrag verwendeten Daten
- Schreiben von Daten in Tabellen, z. B. beim Speichern von Ergebnissen in einer Tabelle
- Erstellen von Datenbankobjekten, z. B. beim Speichern eines externen Skripts als Teil einer neuen gespeicherten Prozedur
Wenn SQL Server als Computekontext für Skripts verwendet wird, die von einem Remoteclient ausgeführt werden, und die ausführbare Datei Daten aus einer externen Quelle abrufen muss, wird ODBC für den Rückschreibevorgang verwendet. SQL Server ordnet die Identität des Benutzers, der den Remotebefehl ausgibt, der Identität des Benutzers auf der aktuellen Instanz zu und führt den ODBC-Befehl mit den Anmeldeinformationen dieses Benutzers aus. Die Verbindungszeichenfolge, die zum Durchführen dieses ODBC-Aufruf erforderlich ist, wird vom Clientcode abgerufen.
Weitere Protokolle
Prozesse, die möglicherweise in „Blöcken“ arbeiten oder Daten zurück an einen Remoteclient übertragen müssen, können auch das XDF-Dateiformat verwenden. Die tatsächliche Datenübertragung erfolgt über codierte Blobs.