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. Java, Python e R sono supportati in SQL Server 2019 (15.x) e versioni successive. 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. Gli amministratori di database possono mantenere la sicurezza eseguendo un linguaggio attendibile all'interno di un framework sicuro gestito da SQL Server, consentendo ai data scientist di accedere ai dati aziendali.
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 certificate da Microsoft come requisiti per le prestazioni e la 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 le estensioni del linguaggio del computer di SQL Server. È disponibile un servizio Launchpad per ogni istanza del motore di database, quindi se si dispone di più istanze con supporto di script esterni, è disponibile un servizio Launchpad per ognuno di essi. Un'istanza del motore di database è associata al servizio Launchpad creato per tale istanza. Tutte le chiamate di uno script esterno in una stored procedure o T-SQL comportano il servizio SQL Server che 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 di Launchpad e usa tale account di lavoro durante l'esecuzione dello script. Se lo script usa processi paralleli, 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 il satellite SQL usano TCP/IP.
ODBC
La comunicazione tra 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
- Creare 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.
Contenuto correlato
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per