Architettura di estendibilità nelle estensioni di linguaggio di SQL Server
Si applica a: 
SQL Server 2019 (15.x) e versioni successive
Informazioni sull'architettura di estendibilità usata per le estensioni del linguaggio di SQL Server, che consente di eseguire codice esterno in SQL Server. In SQL Server 2019 (15.x) e versioni successive sono supportati i runtime Java, Python e R. Il codice viene eseguito in un ambiente di runtime del linguaggio come estensione del motore di database principale.
Background
Lo scopo del framework di estendibilità è fornire un'interfaccia tra SQL Server e i linguaggi esterni. Glli amministratori di database possono mantenere la sicurezza consentendo ai data scientist di accedere ai dati aziendali eseguendo un linguaggio attendibile all'interno di un framework protetto gestito da SQL Server.
Qualsiasi linguaggio esterno supportato può essere eseguito chiamando una stored procedure e i risultati vengono restituiti sotto forma tabulare direttamente a SQL Server. Ciò semplifica l'uso del linguaggio esterno da qualsiasi applicazione in grado di inviare una query SQL e gestire i risultati.
Diagrammi dell'architettura
L'architettura è progettata in modo tale che il codice esterno viene eseguito in un processo separato da SQL Server, ma con componenti che gestiscono internamente la catena di richieste di dati e operazioni in SQL Server.
Architettura dei componenti in Windows:
Architettura dei componenti in Linux:
I componenti includono un servizio Launchpad usato per richiamare i runtime esterni (ad esempio Java) e la logica specifica della libreria per il caricamento di interpreti e librerie.
Launchpad
Launchpad di SQL Server è un servizio che gestisce la durata, le risorse e i limiti di sicurezza del processo esterno responsabile dell'esecuzione dello script. Il funzionamento è analogo al modo in cui il servizio di indicizzazione e query full-text avvia un host separato per l'elaborazione delle query full-text. Il servizio Launchpad può avviare solo utilità di avvio attendibili pubblicate da Microsoft o che Microsoft ha certificato come conformi ai requisiti di prestazioni e gestione delle risorse.
Il servizio Launchpad di SQL Server viene eseguito in SQLRUserGroup, che usa un ambiente AppContainer per l'isolamento dell'esecuzione.
Viene creato un servizio Launchpad di SQL Server separato per ogni istanza del motore di database a cui si aggiungono estensioni di linguaggio macchina di SQL Server. È disponibile un servizio Launchpad per ogni istanza del motore di database, quindi se si hanno più istanze con supporto per gli script esterni, si ha un servizio Launchpad per ciascuna di esse. Un'istanza del motore di database è associata al servizio Launchpad creato per tale istanza. Per tutte le chiamate di uno script esterno in una stored procedure o in T-SQL, il servizio SQL Server chiama il servizio Launchpad creato per la stessa istanza.
Per eseguire attività in un linguaggio supportato specifico, il servizio Launchpad ottiene un account di lavoro protetto dal pool e avvia un processo satellite per gestire il runtime esterno. Ogni processo satellite eredita l'account utente del servizio Launchpad e usa tale account di lavoro durante l'esecuzione dello script. Se lo script usa processi paralleli, questi vengono creati con lo stesso account di lavoro singolo.
Canali di comunicazione tra componenti
In questa sezione vengono descritti i protocolli di comunicazione tra i componenti e le piattaforme dati.
TCP/IP
Per impostazione predefinita, le comunicazioni interne tra SQL Server e SQL Satellite usano TCP/IP.
ODBC
La comunicazione tra i client di data science esterni e un'istanza remota di SQL Server usa ODBC. L'account che invia i processi di script a SQL Server deve avere entrambe le autorizzazioni per connettersi all'istanza ed eseguire gli script esterni.
Inoltre, a seconda dell'attività, per l'account potrebbero essere necessarie le autorizzazioni seguenti:
- Lettura dei dati usati dal processo
- Scrittura dei dati nelle tabelle: ad esempio, quando si salvano i risultati in una tabella
- Creazione di oggetti di database: ad esempio, se si salva uno script esterno come parte di una nuova stored procedure
Quando si usa SQL Server come contesto di calcolo per uno script eseguito da un client remoto e l'eseguibile deve recuperare i dati da un'origine esterna, viene usato ODBC per il writeback. SQL Server mappa l'identità dell'utente che invia il comando remoto all'identità dell'utente dell'istanza corrente ed esegue il comando ODBC usando le credenziali di tale utente. La stringa di connessione necessaria per eseguire questa chiamata a ODBC viene ottenuta dal codice client.
Altri protocolli
I processi che potrebbero dover funzionare in "blocchi" o ritrasferire i dati a un client remoto possono anche usare il formato di file XDF. L'effettivo trasferimento dei dati avviene tramite BLOB codificati.