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:

Diagram of component architecture on Windows.

Architettura dei componenti in Linux:

Diagram of Component architecture on 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.