Lembar sontekan untuk kumpulan SQL khusus (sebelumnya SQL DW) di Azure Synapse Analytics
Lembar sontekan ini memberikan tips bermanfaat dan praktik terbaik untuk membangun solusi kumpulan SQL khusus (sebelumnya SQL DW).
Grafik berikut menunjukkan proses merancang gudang data dengan kumpulan SQL khusus (sebelumnya SQL DW):
Kueri dan operasi di seluruh tabel
Saat Anda mengetahui sebelumnya operasi dan kueri utama yang akan dijalankan di gudang data Anda, Anda dapat memprioritaskan arsitektur gudang data Anda untuk operasi tersebut. Kueri dan operasi ini mungkin mencakup:
- Menggabungkan satu atau dua tabel fakta dengan tabel dimensi, memfilter tabel gabungan, lalu menambahkan hasilnya ke dalam mart data.
- Membuat pembaruan besar atau kecil ke dalam penjualan fakta Anda.
- Menambahkan hanya data ke tabel Anda.
Terlebih dahulu mengetahui jenis operasi membantu Anda mengoptimalkan desain tabel Anda.
Migrasi Data
Pertama, muat data ke Azure Data Lake Storage atau Azure Blob Storage. Selanjutnya, gunakan pernyataan COPY untuk memuat data Anda ke dalam tabel penahapan. Gunakan pengaturan konfigurasi berikut:
| Desain | Rekomendasi |
|---|---|
| Distribusi | Round Robin |
| Pengindeksan | Tumpukan |
| Pemartisian | Tidak ada |
| Kelas Sumber Daya | largerc atau xlargerc |
Pelajari selengkapnya tentang migrasi data, pemuatan data, dan proses Ekstrak, Muat, dan Transformasi (ELT).
Tabel terdistribusi atau direplikasi
Gunakan strategi berikut, bergantung pada properti tabel:
| Jenis | Sangat cocok untuk... | Hati-hati jika... |
|---|---|---|
| Direplikasi | * Tabel dimensi kecil dalam skema bintang dengan kurang dari 2GB penyimpanan setelah pemadatan (~ pemadatan 5x) | * Banyak transaksi menulis di atas tabel (seperti sisipan, upsert, hapus, perbarui) * Anda sering mengubah provisi Unit Gudang Data (DWU) * Anda hanya menggunakan 2-3 kolom tapi tabel Anda memiliki banyak kolom * Anda mengindeks tabel yang direplikasi |
| Round Robin (default) | * Tabel sementara/tahapan * Tidak ada kunci gabungan yang jelas atau kolom kandidat yang baik |
* Performa lambat karena pergerakan data |
| Hash | * Tabel fakta * Tabel dimensi besar |
* Kunci distribusi tidak dapat diperbarui |
Tips:
- Mulai dengan Round Robin, tapi berkeinginan untuk strategi distribusi hash untuk memanfaatkan arsitektur paralel besar-besaran.
- Pastikan bahwa kunci hash umum memiliki format data yang sama.
- Jangan mendistribusikan pada format varchar.
- Tabel dimensi dengan kunci hash umum ke tabel fakta dengan operasi gabungan yang sering dapat didistribusikan hash.
- Gunakan sys.dm_pdw_nodes_db_partition_stats untuk menganalisis kecondongan dalam data.
- Gunakan sys.dm_pdw_request_steps untuk menganalisis pergerakan data di belakang kueri, memantau siaran waktu, dan mengacak operasi. Ini sangat membantu untuk meninjau strategi distribusi Anda.
Pelajari selengkapnya tentang tabel yang direplikasi dan tabel terdistribusi.
Mengindeks tabel Anda
Pengindeksan sangat membantu untuk membaca tabel dengan cepat. Ada serangkaian teknologi unik yang dapat Anda gunakan berdasarkan kebutuhan Anda:
| Jenis | Sangat cocok untuk... | Hati-hati jika... |
|---|---|---|
| Tumpukan | * Penahapan/ tabel sementara * Tabel kecil dengan pencarian kecil |
* Pencarian apa pun memindai tabel lengkap |
| Indeks berkluster | * Tabel dengan hingga 100 juta baris * Tabel besar (lebih dari 100 juta baris) dengan hanya 1-2 kolom yang banyak digunakan |
* Digunakan pada tabel yang direplikasi * Anda memiliki kueri kompleks yang melibatkan beberapa gabungan dan Grup Berdasarkan operasi * Anda membuat pembaruan pada kolom terindeks: dibutuhkan memori |
| Indeks penyimpan kolom berkluster (CCI) (default) | * Tabel besar (lebih dari 100 juta baris) | * Digunakan pada tabel yang direplikasi * Anda membuat operasi pembaruan besar-besaran di tabel Anda * Anda mempartisi tabel Anda secara berlebihan: grup baris tidak mencakup berbagai node distribusi dan partisi |
Tips:
- Di atas indeks berkluster, Anda mungkin ingin menambahkan indeks yang tidak berkluster ke kolom yang banyak digunakan untuk pemfilteran.
- Hati-hati dengan cara Anda mengelola memori di tabel dengan CCI. Saat Anda memuat data, Anda ingin pengguna (atau kueri) mendapatkan keuntungan dari kelas sumber daya yang besar. Pastikan untuk menghindari pemangkasan dan membuat banyak grup baris kecil yang dipadatkan.
- Pada Gen2, tabel CCI di-cache secara lokal pada node komputasi untuk memaksimalkan performa.
- Untuk CCI, performa lambat dapat terjadi karena pemadatan yang buruk dari grup baris Anda. Jika ini terjadi, bangun kembali atau urutkan ulang CCI Anda. Anda menginginkan setidaknya 100.000 baris per grup baris yang dipadatkan. Idealnya adalah 1 juta baris di dalam grup baris.
- Berdasarkan frekuensi dan ukuran beban bertambah bertahap, Anda ingin mengotomatisasi saat Anda mengatur ulang atau membangun ulang indeks Anda. Pembersihan Spring selalu membantu.
- Jadilah strategis saat Anda ingin memangkas grup baris. Seberapa besar grup baris terbuka? Berapa banyak data yang Anda harapkan dimuat dalam beberapa hari mendatang?
Pelajari selengkapnya tentang indeks.
Pemartisian
Anda mungkin memartisi tabel Anda saat Anda memiliki tabel fakta besar (lebih dari 1 miliar baris). Dalam 99 persen kasus, kunci partisi harus didasarkan pada tanggal.
Dengan tabel penahapan yang memerlukan ELT, Anda dapat memperoleh keuntungan dari pemartisian. Ini memfasilitasi manajemen siklus hidup data. Berhati-hatilah untuk tidak melakukan partisi berlebihan pada fakta atau tabel penahapan Anda, terutama pada indeks penyimpan kolom berkluster.
Pelajari selengkapnya tentang partisi.
Muatan bertambah bertahap
Jika Anda akan memuat data secara bertambah bertahap, pertama-tama pastikan Anda mengalokasikan kelas sumber daya yang lebih besar untuk memuat data Anda. Ini sangat penting saat memuat ke dalam tabel dengan indeks penyimpan kolom berkluster. Lihat kelas sumber daya untuk detail lebih lanjut.
Sebaiknya gunakan PolyBase dan ADF V2 untuk mengotomatiskan alur ELT ke gudang data Anda.
Untuk kumpulan pembaruan besar dalam data historis Anda, pertimbangkan untuk menggunakan CTAS untuk menulis data yang ingin Anda simpan dalam tabel daripada menggunakan INSERT, UPDATE, dan DELETE.
Pertahankan statistik
Penting untuk memperbarui statistik karena perubahan signifikan terjadi pada data Anda. Lihat statistik pembaruan untuk menentukan apakah telah terjadi perubahan signifikan. Statistik yang diperbarui mengoptimalkan rencana kueri Anda. Jika Anda merasa bahwa mempertahankan semua statistik Anda memerlukan waktu terlalu lama, cobalah untuk lebih selektif tentang kolom mana yang memiliki statistik.
Anda juga dapat menentukan frekuensi pembaruan. Misalnya, Anda mungkin ingin memperbarui kolom tanggal, di mana nilai baru mungkin ditambahkan, setiap hari. Anda mendapatkan keuntungan paling besar dengan memiliki statistik pada kolom yang terlibat dalam gabungan, kolom yang digunakan dalam klausa WHERE, dan kolom yang ditemukan di GROUP BY.
Pelajari selengkapnya tentang statistik.
Kelas Sumber Daya
Grup sumber daya digunakan sebagai cara untuk mengalokasikan memori ke kueri. Jika Anda memerlukan lebih banyak memori untuk meningkatkan kueri atau kecepatan pemuatan, Anda harus mengalokasikan kelas sumber daya yang lebih tinggi. Di sisi lain, menggunakan kelas sumber daya yang lebih besar berdampak pada konkurensi. Anda ingin mempertimbangkannya sebelum memindahkan semua pengguna Anda ke kelas sumber daya yang besar.
Jika Anda melihat bahwa kueri terlalu lama, periksa apakah pengguna Anda tidak berjalan di kelas sumber daya besar. Kelas sumber daya besar mengonsumsi banyak slot konkurensi. Mereka dapat menyebabkan kueri lain mengantre.
Akhirnya, dengan menggunakan Gen2 dari kumpulan SQL khusus (sebelumnya SQL DW), setiap kelas sumber daya mendapatkan memori 2,5 kali lebih banyak daripada Gen1.
Pelajari selengkapnya cara kerja dengan kelas sumber daya dan konkurensi.
Turunkan biaya Anda
Fitur utama Azure Synapse adalah kemampuan untuk mengelola sumber daya komputasi. Anda dapat menjeda kumpulan SQL khusus Anda (sebelumnya SQL DW) saat Anda tidak menggunakannya, yang menghentikan penagihan sumber daya komputasi. Anda dapat menskalakan sumber daya untuk memenuhi tuntutan performa Anda. Untuk menjeda, gunakan portal Microsoft Azure atau PowerShell. Untuk menskalakan, gunakan portal Microsoft Azure, PowerShell, T-SQL, atau REST API.
Skala Otomatis sekarang pada saat yang Anda inginkan dengan Azure Functions:
Optimalkan arsitektur Anda untuk performa
Sebaiknya pertimbangkan SQL Database dan Azure Analysis Services dalam arsitektur hub-and-spoke. Solusi ini dapat memberikan isolasi beban kerja antara grup pengguna yang berbeda sambil juga menggunakan fitur keamanan lanjutan dari SQL Database dan Azure Analysis Services. Ini juga merupakan cara untuk memberikan konkurensi tanpa batas kepada pengguna Anda.
Pelajari selengkapnya tentang arsitektur khas yang memanfaatkan kumpulan SQL khusus (sebelumnya SQL DW) di Azure Synapse Analytics.
Sebarkan jari Anda dalam satu klik dalam database SQL dari kumpulan SQL khusus (sebelumnya SQL DW):