Aracılığıyla paylaş

Azure Synapse Analytics'de ayrılmış SQL havuzları için en iyi yöntemler

  • Makale

Bu makalede, Azure Synapse Analytics'te ayrılmış SQL havuzları için en iyi performansı elde etmeye yardımcı olacak en iyi yöntemler koleksiyonu sağlanmaktadır. Sunucusuz SQL havuzuyla çalışıyorsanız, belirli yönergeler için sunucusuz SQL havuzları için en iyi yöntemler bölümüne bakın. Aşağıda, çözümünüzü oluştururken odaklanmanız gereken temel kılavuzları ve önemli alanları bulacaksınız. Her bölüm size bir kavram tanıtır ve ardından kavramı daha ayrıntılı bir şekilde kapsayan daha ayrıntılı makalelere işaret eder.

Ayrılmış SQL havuzları yükleniyor

Ayrılmış SQL havuzları yükleme kılavuzu için bkz . Veri yükleme kılavuzu.

Duraklatma ve ölçeklendirme ile maliyetleri azaltın

Duraklatma ve ölçeklendirme yoluyla maliyetleri azaltma hakkında daha fazla bilgi için bkz . İşlemi yönetme.

İstatistiklerin bakımını yapın

Ayrılmış SQL havuzu, sütunlar üzerinde istatistikleri otomatik olarak algılayıp oluşturacak şekilde yapılandırılabilir. İyileştirici tarafından oluşturulan sorgu planları yalnızca kullanılabilir istatistikler kadar iyidir.

Sorgularınızda kullanılan sütunlarla ilgili istatistiklerin her zaman güncel olduğundan emin olmak için veritabanlarınız için AUTO_CREATE_STATISTICS etkinleştirmenizi ve istatistikleri günlük olarak veya her yüklemeden sonra güncel tutmanızı öneririz.

İstatistik bakım süresini kısaltmak için hangi sütunların istatistiklere sahip olduğu veya en sık güncelleştirilmesi gerektiği konusunda seçici olun. Örneğin, her gün yeni değerlerin eklenebileceği tarih sütunlarını güncelleştirmek isteyebilirsiniz. Birleştirmelere dahil olan sütunlar, WHERE yan tümcesinde kullanılan sütunlar ve GROUP BY içinde bulunan sütunlar için istatistiklere odaklanın.

İstatistiklerle ilgili ek bilgileri Tablo istatistiklerini yönetme, CREATE STATISTICS ve UPDATE STATISTICS makalelerinde bulabilirsiniz.

Sorgu performansını ayarlama

INSERT deyimlerini gruplayın

gibi bir INSERT deyimine INSERT INTO MyLookup VALUES (1, 'Type 1')sahip küçük bir tabloya tek seferlik yük, gereksinimlerinize bağlı olarak en iyi yaklaşım olabilir. Bununla birlikte, gün boyunca binlerce veya milyonlarca satır yüklemeniz gerekiyorsa, tekli INSERT'lerin en iyi durumda olma olasılığı yüksektir.

Bu sorunu çözmenin bir yolu, bir dosyaya yazan bir işlem geliştirmek ve sonra bu dosyayı düzenli aralıklarla yüklemek için başka bir işlem geliştirmektir. Daha fazla bilgi için INSERT makalesine bakın.

Verileri hızlıca yüklemek ve dışarı aktarmak için PolyBase kullanın

Ayrılmış SQL havuzu Azure Data Factory, PolyBase ve BCP gibi çeşitli araçlar aracılığıyla veri yüklemeyi ve dışarı aktarmayı destekler. Performansın yüksek öneme sahip olmadığı küçük miktarlardaki veriler için bu araçlardan herhangi birini kullanabilirsiniz.

Dekont

PolyBase, büyük hacimli verileri yüklerken veya dışarı aktarırken veya daha hızlı performansa ihtiyaç duyduğunuzda en iyi seçenektir.

PolyBase yükleri CTAS veya INSERT INTO ile çalıştırılabilir. CTAS işlem günlüğünü en aza indirir ve verilerinizi yüklemenin en hızlı yoludur. Azure Data Factory, PolyBase yüklerini de destekler ve CTAS'a benzer bir performans elde edebilir. PolyBase, Gzip dosyaları da dahil olmak üzere çeşitli dosya biçimlerini destekler.

Gzip metin dosyalarını kullanırken aktarım hızını en üst düzeye çıkarmak için, yükünüzün paralelliğini en üst düzeye çıkarmak için dosyaları 60 veya daha fazla dosyaya bölün. Toplam hızı artırmak için verilerinizi aynı anda yükleyin. Bu bölümle ilgili ek bilgiler aşağıdaki makalelerde yer almaktadır:

Dış tabloları önce yükleyip sonra sorgu çalıştırın

PolyBase sorgular için en uygun seçenek değildir. Ayrılmış SQL havuzları için PolyBase tabloları şu anda yalnızca Azure blob dosyalarını ve Azure Data Lake depolamayı destekler. Bu dosyalar, bunları yedeklerken herhangi bir işlem kaynağına sahip değildir. Sonuç olarak, ayrılmış SQL havuzları bu işi boşaltamaz ve verileri okuyabilmesi için tempdb dosyasını yükleyerek dosyanın tamamını okuması gerekir.

Bu verileri sorgulamak için birkaç sorgunuz varsa, bu verileri bir kez yüklemek ve sorguların yerel tabloyu kullanmasını sağlamak daha iyidir. PolyBase kullanma kılavuzu makalesine daha fazla PolyBase kılavuzu eklenmiştir.

Büyük tabloları karma olarak dağıtın

Tablolar varsayılan olarak Hepsini Bir Kez Deneme yöntemiyle dağıtılmıştır. Bu varsayılan ayar, kullanıcıların tablolarının nasıl dağıtılacağına karar vermek zorunda kalmadan tablo oluşturmaya başlamasını kolaylaştırır. Hepsini Bir Kez Deneme tabloları bazı iş yükleri için yeterli performans gösterebilir. Ancak çoğu durumda dağıtım sütunu daha iyi performans sağlar.

Hepsini bir kez deneme tablosunun daha iyi performans gösterdiği bir sütun tarafından dağıtılan tablonun en yaygın örneği, iki büyük olgu tablosunun birleştirilmesidir.

Örneğin, order_id tarafından dağıtılan bir sipariş tablonuz ve order_id tarafından dağıtılan bir işlem tablonuz varsa, siparişler tablonuzu order_id'de işlemler tablonuza eklediğinizde, bu sorgu doğrudan sorguya dönüşür. Daha sonra veri taşıma işlemleri ortadan kalkar. Adım sayısı ne kadar az olursa sorgu o kadar hızlı işlenir. Taşınan veri miktarı azaldıkça sorgunun hızı artar.

Bahşiş

Dağıtılmış tablo yüklenirken, gelen verileriniz dağıtım anahtarında sıralanmamalıdır. Bunu yapmak yüklerinizi yavaşlatır.

Aşağıda sağlanan makale bağlantıları, bir dağıtım sütunu seçerek performansı artırma hakkında ek ayrıntılar sağlar. Ayrıca CREATE TABLE deyiminizin WITH yan tümcesinde dağıtılmış tablo tanımlama hakkında bilgi bulabilirsiniz:

Aşırı bölümleme yapmayın

Bölümleme verileri bölüm değiştirme veya bölüm eleme ile taramaları iyileştirme yoluyla verilerinizi korumak için etkili olsa da, çok fazla bölüme sahip olmak sorgularınızı yavaşlatabilir. Genellikle SQL Server'da iyi çalışabilen yüksek ayrıntı düzeyi bölümleme stratejisi, ayrılmış SQL havuzunda iyi çalışmayabilir.

Çok fazla bölüm olması, her bölümün 1 milyondan az satırı varsa kümelenmiş columnstore dizinlerinin verimliliğini azaltabilir. Ayrılmış SQL havuzları, verilerinizi otomatik olarak 60 veritabanına böler. Bu nedenle, 100 bölümlü bir tablo oluşturursanız sonuç 6000 bölüm olur. Her iş yükü farklıdır, bu nedenle en iyi öneri, iş yükünüz için en uygun olanı görmek için bölümleme denemeleri yapmaktır.

Dikkate alınması gereken bir seçenek, SQL Server kullanarak uyguladığınız taneciklikten daha düşük bir ayrıntı düzeyi kullanmaktır. Örneğin, günlük bölümler yerine haftalık veya aylık bölümler kullanmayı göz önünde bulundurun.

Bölümleme hakkında daha fazla bilgi tablo bölümleme makalesinde ayrıntılı olarak verilmiştir.

İşlem boyutları en aza indirin

INSERT, UPDATE ve DELETE deyimleri bir işlemde çalışır. Başarısız olduklarında geri alınmalıdırlar. Uzun bir geri alma olasılığını azaltmak için mümkün olduğunda işlem boyutlarını en aza indirin. INSERT, UPDATE ve DELETE deyimlerini parçalara ayırarak işlem boyutlarını en aza indirme işlemi yapılabilir. Örneğin, 1 saat sürmesini beklediğiniz bir INSERT'iniz varsa INSERT'i dört parçaya ayırabilirsiniz. Ardından her çalıştırma 15 dakikaya kısaltılır.

Bahşiş

Geri alma riskini azaltmak için CTAS, TRUNCATE, DROP TABLE veya INSERT gibi özel En Az Günlüğe Kaydetme durumlarında boş tablo kullanın.

Geri alma işlemlerini ortadan kaldırmanın başka bir yöntemi de veri yönetimi için bölüm değiştirme gibi Yalnızca Meta Veri işlemlerini kullanmaktır. Örneğin, order_date Ekim 2001'de olduğu bir tablodaki tüm satırları silmek için DELETE deyimi yürütmek yerine verilerinizi aylık olarak bölümleyebilirsiniz. Ardından, başka bir tablodan boş bir bölüme ait verileri içeren bölümü değiştirebilirsiniz (bkz. ALTER TABLE örnekleri).

Bölümlenmemiş tablolar için, DELETE kullanmak yerine bir tabloda tutmak istediğiniz verileri yazmak için bir CTAS kullanmayı göz önünde bulundurun. Bir CTAS aynı süreyi alıyorsa, minimum işlem günlüğü olduğundan ve gerekirse hızlı bir şekilde iptal edilebildiğinden çalıştırılması çok daha güvenlidir.

Bu bölümle ilgili içerik hakkında daha fazla bilgi aşağıdaki makalelerde yer almaktadır:

Sorgu sonucu boyutlarını küçültme

Sorgu sonuçları boyutlarını küçültmek, büyük sorgu sonuçlarının neden olduğu istemci tarafı sorunlarından kaçınmanıza yardımcı olur. Döndürülen satır sayısını azaltmak için sorgunuzu düzenleyebilirsiniz. Bazı sorgu oluşturma araçları, her sorguya "ilk N" söz dizimi eklemenize olanak sağlar. Ayrıca, sorgu sonucunu geçici bir tabloya CETAS olarak ekleyebilir ve ardından alt düzey işleme için PolyBase dışarı aktarmayı kullanabilirsiniz.

Mümkün olan en küçük sütun boyutunu kullanın

DDL'nizi tanımlarken, sorgu performansını artıracağı için verilerinizi destekleyecek en küçük veri türünü kullanın. Bu öneri özellikle CHAR ve VARCHAR sütunları için önemlidir. Bir sütundaki en uzun değer 25 karakterse, sütununuzu VARCHAR(25) olarak tanımlayın. Tüm karakter sütunları için varsayılan uzunluk değeri olarak yüksek bir değer kullanmaktan kaçının. Ayrıca, NVARCHAR kullanmak yerine gereken tek şey bu olduğunda sütunları VARCHAR olarak tanımlayın.

Yukarıdaki bilgilerle ilgili temel kavramların daha ayrıntılı bir incelemesi için lütfen Tabloya genel bakış, Tablo veri türleri ve CREATE TABLE makalelerine bakın.

Geçiş verileri için geçici yığın tabloları kullanın

Verileri ayrılmış SQL havuzlarına geçici olarak eklediğinizde yığın tabloları genel olarak süreci hızlandırır. Verileri yalnızca daha fazla dönüştürme çalıştırmadan önce hazırlamak için yüklüyorsanız, tabloyu yığın tablosuna yüklemek, verileri kümelenmiş columnstore tablosuna yüklemekten daha hızlı olacaktır.

Verileri geçici bir tabloya yüklemek, bir tabloyu kalıcı depolamaya yüklemekten çok daha hızlı yüklenir. Geçici tablolar bir "#" ile başlar ve yalnızca onu oluşturan oturum tarafından erişilebilir. Sonuç olarak, yalnızca sınırlı senaryolarda çalışabilirler. Yığın tabloları, CREATE TABLE deyiminin WITH yan tümcesinde tanımlanır. Geçici tablo kullanıyorsanız, onun için de istatistik oluşturmayı unutmayın.

Daha fazla bilgi için Geçici tablolar, CREATE TABLE ve CREATE TABLE AS SELECT makalelerine bakın.

Kümelenmiş columnstore tablolarını iyileştirin

Kümelenmiş columnstore dizinleri, verilerinizi ayrılmış SQL havuzunda depolamanın en verimli yollarından biridir. Varsayılan olarak, ayrılmış SQL havuzundaki tablolar Kümelenmiş ColumnStore olarak oluşturulur. Columnstore tablolarında yapılan sorgularda en iyi performansı elde etmek için segment kalitesinin yüksek olması önemlidir. Satırlar columnstore tablolarına bellek baskısı altında yazıldığında, segment kalitesi düşebilir.

Segment kalitesi, sıkıştırılmış satır grubundaki satır sayısıyla ölçülebilir. Kümelenmiş columnstore tablolarında segment kalitesini algılama ve iyileştirmeye yönelik adım adım yönergeler için Tablo dizinleri makalesindeki Düşük columnstore dizin kalitesinin nedenleri makalesine bakın.

Yüksek kaliteli columnstore segmentleri önemli olduğundan, verileri yüklemek için orta veya büyük kaynak sınıfında yer alan kullanıcı kimliklerini kullanmak iyi bir fikirdir. Daha düşük veri ambarı birimleri kullanmak, yükleme kullanıcınıza daha büyük bir kaynak sınıfı atamak istediğiniz anlamına gelir.

Columnstore tabloları genellikle tablo başına 1 milyondan fazla satır olana kadar verileri sıkıştırılmış bir columnstore segmentine göndermez. Her ayrılmış SQL havuzu tablosu 60 farklı dağıtıma dağıtılır. Bu nedenle, tablo 60 milyondan fazla satıra sahip olmadığı sürece columnstore tabloları sorguya fayda sağlamaz.

Bahşiş

60 milyondan az satıra sahip tablolar için columnstore dizinine sahip olmak en uygun çözüm olmayabilir.

Verilerinizi bölümlerseniz, kümelenmiş columnstore dizininden yararlanmak için her bölümün 1 milyon satırı olması gerekir. 100 bölümü olan bir tablo için, kümelenmiş sütun deposundan (60 dağıtım 100 bölüm 1 milyon satır) yararlanmak için en az 6 milyar satıra sahip olması gerekir.

Tablonuzda 6 milyar satır yoksa iki ana seçeneğiniz vardır. Bölüm sayısını azaltın veya bunun yerine yığın tablosu kullanmayı göz önünde bulundurun. Ayrıca, columnstore tablosu yerine ikincil dizinlere sahip bir yığın tablosu kullanılarak daha iyi performans elde edilip kazanılmadığını görmek için deneme yapmaya değer.

Columnstore tablosunda çalıştırılan sorgular yalnızca ihtiyacınız olan sütunları seçmeniz halinde daha hızlı olacaktır. Tablo ve columnstore dizinleri hakkında daha fazla bilgi ve aşağıdaki makalelerde bulunabilir:

Sorgu performansını artırmak için daha büyük kaynak sınıfı kullanın

SQL havuzları, sorgulara bellek ayırmanın bir yolu olarak kaynak gruplarını kullanır. Başlangıçta, tüm kullanıcılar dağıtım başına 100 MB bellek veren küçük kaynak sınıfına atanır. Her zaman 60 dağıtım vardır. Her dağıtıma en az 100 MB verilir. Sistem genelinde toplam bellek ayırma 6.000 MB veya yalnızca 6 GB'ın altındadır.

Büyük birleştirmeler veya kümelenmiş columnstore tablolarına yapılan yüklemeler gibi belirli sorgulara daha fazla bellek atanır. Saf taramalar gibi bazı sorgular avantaj sağlamaz. Daha büyük kaynak sınıflarının kullanımı eşzamanlılığı etkiler. Bu nedenle, tüm kullanıcılarınızı büyük bir kaynak sınıfına taşımadan önce bu olguları göz önünde bulundurmanız gerekir.

Kaynak sınıfları hakkında ek bilgi için iş yükü yönetimi için kaynak sınıfları makalesine bakın.

Eşzamanlılığı artırmak için daha küçük kaynak sınıfı kullanma

Kullanıcı sorgularında uzun bir gecikme fark ederseniz kullanıcılarınız daha büyük kaynak sınıflarında çalışıyor olabilir. Bu senaryo eşzamanlılık yuvalarının tüketimini teşvik eder ve bu da diğer sorguların kuyruğa almalarına neden olabilir. Kullanıcı sorgularının kuyruğa alınıp alınmadığını belirlemek için komutunu çalıştırarak SELECT * FROM sys.dm_pdw_waits herhangi bir satırın döndürülip döndürülmediğini görün.

İş yükü yönetimi ve sys.dm_pdw_waits makaleleri için Kaynak sınıfları size daha fazla bilgi sağlar.

Sorgularınızı izlemek ve iyileştirmek için DMV’leri kullanın

Ayrılmış SQL havuzları, sorgu yürütmeyi izlemek için kullanılabilecek çeşitli DMV'lere sahiptir. Aşağıdaki izleme makalesi, yürütülen sorgunun ayrıntılarını görüntülemeye yönelik adım adım yönergelerde size yol gösterir. Bu DMV’lerdeki sorguları hızlıca bulmak için sorgularınızla LABEL seçeneğini kullanabilirsiniz. Daha ayrıntılı bilgi için lütfen aşağıdaki listede yer alan makalelere bakın:

Sonraki adımlar

Yaygın sorunlar ve çözümler için Sorun giderme makalesine de bakın.

Bu makalede sağlanmayan bilgilere ihtiyacınız varsa Microsoft Soru-Cevap soru sayfasında Azure Synapse'in diğer kullanıcılara ve Azure Synapse Analytics Ürün Grubu'na soru sorabileceğiniz bir yer olduğunu arayın.

Sorularınızın diğer kullanıcılar veya ekibimiz tarafından yanıtlandığından emin olmak için bu forumu sürekli takip ediyoruz. Stack Overflow ile ilgili sorularınızı sormak isterseniz Azure Synapse Analytics Stack Overflow Forumu da mevcuttur.