Confronto tra le estensioni del linguaggio SQL Server e SQL CLR

  • Articolo

Si applica a: SQL Server 2019 (15.x) e versioni successive

Questo articolo offre un confronto tra le estensioni del linguaggio SQL Server e il Common Language Runtime (CLR) nativo. Identifica le differenze principali e aiuta a decidere quale usare.

Le estensioni del linguaggio SQL Server sono una funzionalità di SQL Server usata per l'esecuzione di codice esterno. I dati relazionali possono essere usati nel codice esterno tramite il framework di estendibilità.

Il Common Language Runtime (CLR) nativo consente di implementare alcune delle funzionalità di SQL Server con linguaggi .NET. CLR fornisce codice gestito con servizi quali l'integrazione tra linguaggi diversi, la sicurezza da accesso di codice, la gestione della durata degli oggetti e il supporto per il debug e il profiling.

I linguaggi disponibili nelle estensioni del linguaggio di SQL Server non sono una sostituzione diretta per SQL CLR. Il framework di estendibilità e le estensioni del linguaggio estendono la superficie di SQL Server e forniscono un ambiente di esecuzione per i runtime più prossimo al motore di database. Forniscono anche un framework open source che può essere usato per eseguire l'onboarding di nuovi runtime senza modifiche del motore. Attualmente la superficie è limitata alla stored procedure di sistema sp_execute_external_script.

Di seguito sono riportate alcune delle differenze chiave tra le estensioni del linguaggio SQL e SQL CLR:

Funzionalità SQL CLR Estensioni del linguaggio SQL
Piattaforme supportate Windows & Linux - Linux supporta solo SAFE assembly. Windows e Linux: parità completa in termini di funzionalità.
Modalità di esecuzione In-process Out-of-process
Isolamento Il codice CLR viene eseguito all'interno del processo del motore; L'amministratore dell'istanza deve considerare attendibili tutti gli assembly/codice. L'esecuzione del runtime avviene al di fuori del processo del motore. Viene fornito un ulteriore isolamento tramite i contenitori di app in Windows o gli spazi dei nomi in Linux. Inoltre, la comunicazione di rete esterna è disabilitata per impostazione predefinita.
Sintassi dichiarativa (T-SQL) Tipi definiti dall'utente, aggregazioni definite dall'utente, funzioni, procedure, trigger. Solo l'esecuzione ad hoc tramite sp_execute_external_script.
Supporto DDL CREATE ASSEMBLY per caricare il codice utente e definire altri oggetti (funzioni, procs, trigger definiti dall'utente, UDAgg). CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY per gestire estensioni e librerie.
Supporto per le librerie Ottenuto tramite assembly. È possibile usare librerie per un runtime specifico, ad esempio pacchetti R o Python e librerie Java.
Runtime supportati .NET Framework R, Python, Java, C# o Bring Your Own Runtime (BYOR).
Framework OSS N/D: estendibile tramite assembly .NET definiti dall'utente. Sì: l'SDK di estensione fornisce la creazione di nuove estensioni o l'integrazione con runtime senza modifiche al motore.
Integrazione QO Integrazione a livello di operatore per varie sintassi, incluso il parallelismo. Singolo operatore di script esterno per inviare/ricevere risultati e dati dai runtime; questo operatore supporta l'esecuzione in modalità batch e il parallelismo.
Governance delle risorse Nessuna: poche opzioni al di fuori di Resource Governor. Fornisce EXTERNAL RESOURCE POOL l'oggetto come meccanismo separato per gestire le risorse utilizzate dagli script di runtime/esterni, i criteri possono essere definiti per i runtime esterni oltre al carico di lavoro SQL.
Modello di autorizzazione Controllo a livello di istanza con oggetti con ambito database. Controllo a livello di istanza con oggetti con ambito database.
Prestazioni Il codice CLR SQL in genere supera l'estendibilità a causa della natura dell'esecuzione. Ideale per l'esecuzione orientata ai batch.
Funzionalità di monitoraggio sys.dm_clr*DMV e contatore Monitor prestazioni specifico di SQL CLR limitato. sys.dm_external*DMV, DMV del pool di risorse esterne, contatori di Windows JobObject Monitor prestazioni.

Scegliere la soluzione più adatta

La decisione di usare le estensioni del linguaggio o CLR dipende dai propri scenari e obiettivi. Ad esempio, se è necessario estendere l'area di attacco T-SQL con le proprie aggregazioni o tipi, CLR è la scelta migliore perché il tipo o l'aggregazione non può essere definita usando il meccanismo di estendibilità. D'altra parte, se si vuole usare competenze di data science esistenti nell'organizzazione o nel team, l'uso dell'integrazione di R/Python con estendibilità è la scelta migliore.

Analogamente, gli obiettivi di prestazioni potrebbero determinare la decisione. L'implementazione di una funzione regex in C# e l'uso di CLR è molto più veloce rispetto all'uso dell'estendibilità per richiamare uno script Python che esegue la stessa funzionalità regex.

Contenuto correlato