Paralel Skaler UDF desteği makul bir özellik isteği midir?

Skaler UDF'lerin genel bir seri planı zorladığı oldukça iyi belgelenmiştir.

Paralel çalışma fonksiyonları

Boru hattında bir UDF'nin hesaplanması gereken bir noktaya gelen çok sayıda satır göz önüne alındığında, motor bunları neden işlemciler arasında dağıtamıyor? Bir UDF içinde devlet yoksa, siparişin önemi yoktur.

Kara kutu olmanın imleç kullanması gerektiğine dair iddialar var. Bir kullanıcı imlecinin, yinelemeler arasında bir durumun korunduğu, ancak bunun başka türlü paralelleştirilmesi gerektiği gibi durumlarda bir SP içinde paralelleştirilemediğini görebiliyorum.

Motorun neden sadece UDF hesaplama aşaması yerine tüm planı seri olmaya zorladığını açıklayan ekstra noktalar.

Paralel UDF desteği talep etmek için makul bir özellik midir?

UDF'lerin genel bir seri planı zorladığı oldukça iyi belgelenmiştir.

Bu kadar iyi belgelenmiş olduğundan emin değilim.

• Skaler T-SQL fonksiyonu planın herhangi bir yerinde paralellik önler.
• Bir skaler CLR işlevi, veritabanına erişmediği sürece paralel olarak yürütülebilir.
• Çok ifadeli tablo değerli T-SQL işlevi, başka bir yerde paralellik kullanabilen bir plandaki seri bölgeyi zorlar.
• Satır içi tablo değerli T-SQL işlevi bir görünüm gibi genişletilir, bu nedenle doğrudan bir etkisi yoktur.

Bkz. Paralel Yürütme Planını Zorlama ve / veya Craig Freedman'ın Paralel Yürütme sunumu .

Kara kutu olmanın UDF'lerin imleç kullanması gerektiğine dair iddialar var.

Bu iddialar doğru değil.

Motorun neden sadece UDF hesaplama aşaması yerine tüm planı seri olmaya zorladığını açıklayan ekstra noktalar.

Anladığım kadarıyla, mevcut kısıtlamaların tamamen belirli uygulama detaylarının bir sonucu olduğu. Paralellik kullanılarak işlevlerin yürütülememesinin temel bir nedeni yoktur.

Özellikle, T-SQL skaler fonksiyonları ayrı bir T-SQL bağlamında yürütülür, bu da doğru çalışmayı, koordinasyonu ve kapanmayı (özellikle bir hata durumunda) önemli ölçüde karmaşıklaştırır.

Aynı şekilde, tablo değişkenleri genel olarak paralel okumaları destekler (ancak yazmaz), ancak tablo değerli bir işlevle ortaya çıkan tablo değişkeni uygulamaya özel nedenlerle paralel okumaları destekleyemez. Korkarım, yetkili bir yanıt sağlamak için kaynak kodu erişimine (ve ayrıntıları paylaşma özgürlüğüne) sahip birine ihtiyacınız olacak.

Paralel UDF desteği talep etmek için makul bir özellik midir?

Tabii ki, yeterince güçlü bir dava yapabilirseniz. Kendi düşüncem, ilgili çalışmanın kapsamlı olacağı, bu nedenle teklifinizin son derece yüksek bir bara ulaşması gerekeceğidir . Örneğin, satır içi skaler fonksiyonlar sağlamak için ilgili (ve çok daha basit) bir talebin büyük bir desteği var, ancak yıllardır uygulanmadı.

Microsoft belgesini okumak isteyebilirsiniz:

• Froid: İlişkisel Veritabanındaki Zorunlu Programların Optimizasyonu (pdf)

... Microsoft'un SQL Server 2017'den sonraki sürümde T-SQL skaler fonksiyon performansı sorunlarını ele almak için attığı yaklaşımı özetliyor.

Froid'in amacı, geliştiricilerin performanstan ödün vermeden UDF'lerin ve prosedürlerin soyutlamalarını kullanmalarını sağlamaktır. Froid, bu amaca, zorunlu programları otomatik olarak mümkün olduğunca eşdeğer ilişkisel cebirsel biçimlere dönüştürmek için yeni bir teknik kullanarak başarıyor. Froid, zorunlu kod bloklarını ilişkisel ifadeler olarak modeller ve Uygula operatörünü kullanarak bunları sistematik olarak tek bir ifadede birleştirir, böylece sorgu optimize edicinin verimli küme odaklı, paralel sorgu planları seçmesini sağlar .

(benimkini vurgula)

Satır içi skaler T-SQL işlevleri artık SQL Server 2019'da uygulanmaktadır .

Pavlus'un cevabında haklı olarak bahsettiği gibi, skaler UDF'lerin paralellik kullanılarak yürütülememesinin temel bir nedeni yoktur. Bununla birlikte, uygulama zorluklarının yanı sıra, bunları seri olmaya zorlamanın başka bir nedeni daha vardır. Froid Paul tarafından belirtilen kağıt Bu konuda daha fazla bilgi verir.

Makaleden alıntı (Bölüm 2.3):

Şu anda, SQL Server, UDF'leri çağıran sorgularda sorgu içi paralellik kullanmaz. Bu sınırlamayı hafifletmek için yöntemler tasarlanabilir, ancak her UDF çağrısı için doğru paralellik derecesini seçmek gibi ek zorluklar ortaya çıkarırlar.

Örneğin, Şekil 1'deki gibi diğer SQL sorgularını çağıran bir UDF'yi düşünün. Bu tür her bir sorgunun kendisi paralellik kullanabilir ve bu nedenle, optimize edicinin, UDF ve içindeki her sorgu için paralellik derecesine karar verir (potansiyel olarak bir çağrıdan diğerine değişebilir). İç içe ve özyinelemeli UDF'lerle bu sorunun yönetilmesi daha da zorlaşır.

Makalede açıklandığı gibi Froid'in yaklaşımı sadece paralel planlarla sonuçlanmayacak, aynı zamanda UDF'lerle yapılan sorgular için çok daha fazla fayda sağlayacaktır. Özünde, UDF'lerin paralel yürütülmesi talebinizi yerine getirir.

Güncelleme: Froid artık SQL Server 2019 önizlemesinin bir özelliği olarak kullanılabilir. Bu özelliğe "Skaler UDF Satır İçi" denir. Daha fazla ayrıntı burada: https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/11/07/introducing-scalar-udf-inlining/

[Açıklama: Froid gazetesinin ortak yazarıyım]