Bagikan melalui

Mengoptimalkan performa dengan menggunakan teknologi dalam memori di Azure SQL Database

  • Artikel

Berlaku untuk: Azure SQL Database

Teknologi dalam memori memungkinkan Anda meningkatkan performa aplikasi, dan berpotensi mengurangi biaya database Anda.

Kapan menggunakan teknologi dalam memori

Dengan menggunakan teknologi dalam memori, Anda dapat mencapai peningkatan performa dalam berbagai beban kerja:

  • Transaksional (pemrosesan transaksional online (OLTP)) di mana sebagian besar permintaan membaca atau memperbarui kumpulan data yang lebih kecil, misalnya, operasi buat/baca/perbarui/hapus (CRUD).
  • Analitik (pemrosesan analitik online (OLAP)) di mana sebagian besar kueri memiliki perhitungan kompleks untuk tujuan pelaporan, dan juga proses terjadwal secara teratur yang melakukan operasi pemuatan (atau beban massal) dan/atau menulis perubahan data ke tabel yang ada. Seringkali, beban kerja OLAP diperbarui secara berkala dari beban kerja OLTP.
  • Campuran (transaksi hibrida/pemrosesan analitik (HTAP)) yang kueri OLTP dan OLAP dijalankan pada set data yang sama.

Teknologi dalam memori dapat meningkatkan performa beban kerja tersebut dengan menyimpan data yang harus diproses ke dalam memori, menggunakan kompilasi asli kueri, atau pemrosesan lanjutan seperti pemrosesan batch dan instruksi SIMD yang tersedia pada perangkat keras yang mendasarinya.

Gambaran Umum

Azure SQL Database mendukung teknologi dalam memori berikut:

  • OLTP Dalam Memori meningkatkan jumlah transaksi per detik dan mengurangi latensi untuk pemrosesan transaksi. Skenario yang diuntungkan dari OLTP Dalam Memori adalah: pemrosesan transaksi throughput tinggi seperti perdagangan dan permainan, menyerap data dari peristiwa atau perangkat IoT, penembolokan, pemuatan data, dan skenario variabel tabel dan tabel sementara.
  • Indeks penyimpan kolom berkluster mengurangi jejak penyimpanan Anda (hingga 10 kali) dan meningkatkan performa untuk melaporkan dan kueri analitik. Anda dapat menggunakannya dengan tabel fakta di pasar data Anda agar pas dengan lebih banyak data dalam database Anda dan meningkatkan performa. Selain itu, Anda dapat menggunakannya dengan data riwayat dalam database operasional Anda untuk mengarsipkan dan dapat mengkueri hingga 10 kali lebih banyak data.
  • Indeks penyimpan kolom tidak berkluster untuk HTAP membantu Anda memperoleh wawasan real time ke dalam bisnis Anda melalui kueri database operasional secara langsung, tanpa perlu menjalankan proses ekstrak, transformasi, serta pemuatan (ETL) yang mahal dan menunggu agar gudang data diisi. Indeks penyimpan kolom tidak berkluster memungkinkan eksekusi cepat kueri analitik pada database OLTP, sekaligus mengurangi dampak pada beban kerja operasional.
  • Indeks penyimpan kolom berkluster yang dengan memori dioptimalkan untuk HTAP memungkinkan Anda melakukan pemrosesan transaksi cepat, dan untuk menjalankan kueri analitik secara bersamaan dengan sangat cepat pada data yang sama.

Indeks penyimpan kolom dan OLTP Dalam Memori masing-masing diperkenalkan ke SQL Server pada tahun 2012 dan 2014. Azure SQL Database, Azure SQL Managed Instance, dan SQL Server memiliki penerapan teknologi dalam memori yang sama.

Catatan

Untuk tutorial langkah demi langkah terperinci untuk menunjukkan keunggulan performa teknologi OLTP Dalam Memori, menggunakan AdventureWorksLT database sampel dan ostress.exe, lihat Sampel dalam memori di Azure SQL Database.

Keuntungan teknologi dalam memori

Karena kueri dan pemrosesan transaksi yang lebih efisien, teknologi dalam memori juga membantu Anda mengurangi biaya. Anda biasanya tidak perlu meningkatkan tingkat harga database untuk memperoleh keuntungan performa. Dalam beberapa kasus, Anda bahkan mungkin dapat mengurangi tingkat harga, sambil tetap melihat peningkatan performa dengan teknologi dalam memori.

Dengan menggunakan OLTP Dalam Memori, Solusi Bisnis Kuorum mampu menggandakan beban kerja mereka sekaligus meningkatkan DTUs sebesar 70%. Untuk informasi selengkapnya, lihat OLTP Dalam Memori di Azure SQL Database.

Catatan

OLTP Dalam Memori tersedia di tingkat layanan Premium (DTU) dan Business Critical (vCore) azure SQL Database. Tingkat layanan Hyperscale mendukung subset objek OLTP Dalam Memori. Untuk informasi selengkapnya, lihat Batasan Hyperscale.

Indeks penyimpan kolom tersedia di semua tingkat layanan kecuali untuk tingkat Dasar, dan tingkat Standar saat tujuan layanan di bawah S3. Untuk informasi selengkapnya, lihat Mengubah tingkat layanan database yang berisi indeks penyimpan kolom.

Artikel ini menjelaskan aspek OLTP Dalam Memori dan indeks penyimpan kolom yang khusus untuk Azure SQL Database, dan juga menyertakan sampel yang memungkinkan Anda melihat:

  • Dampak teknologi ini pada batas penyimpanan dan ukuran data.
  • Cara mengelola pergerakan database yang menggunakan teknologi ini di antara berbagai tingkat harga.
  • Penggunaan ilustrasi OLTP Dalam Memori, serta indeks penyimpan kolom.

Untuk informasi selengkapnya tentang teknologi dalam memori di SQL Server, lihat:

OLTP Dalam Memori

Teknologi OLTP Dalam Memori menyediakan operasi akses data yang sangat cepat dengan menyimpan semua data dalam memori. Ini juga menggunakan indeks khusus, kompilasi kueri asli, dan akses data bebas latch untuk meningkatkan performa beban kerja OLTP. Ada dua cara untuk mengatur data OLTP Dalam Memori Anda:

  • Format rowstore dengan memori dioptimalkan yang setiap barisnya adalah objek memori terpisah. Ini adalah format OLTP Dalam Memori klasik yang dioptimalkan untuk beban kerja OLTP berperforma tinggi. Ada dua jenis tabel dengan memori dioptimalkan yang dapat digunakan dalam format rowstore dengan memori dioptimalkan:

    • Tabel tahan lama (SCHEMA_AND_DATA) tempat baris ditempatkan dalam memori dipertahankan setelah server dimulai ulang. Jenis tabel ini befungsi seperti tabel rowstore tradisional dengan keuntungan tambahan dari pengoptimalan dalam memori.
    • Tabel yang tidak dapat ditahan (SCHEMA_ONLY) di mana baris tidak dipertahankan setelah dihidupkan ulang. Jenis tabel ini didesain untuk data sementara (misalnya, penggantian tabel sementara), atau tabel di mana Anda perlu memuat data dengan cepat sebelum Anda memindahkannya ke beberapa tabel yang bertahan (disebut tabel penahapan).

  • Format penyimpan kolom dengan memori dioptimalkan yang datanya diatur dalam format kolom. Struktur ini dirancang untuk skenario HTAP di mana Anda perlu menjalankan kueri analitik pada struktur data yang sama saat beban kerja OLTP Anda berjalan.

Catatan

OLTP Dalam Memori dirancang untuk struktur data yang sepenuhnya dapat berada dalam memori. Karena data dalam memori tidak dapat dilepas ke disk, pastikan Anda menggunakan database yang memiliki memori yang cukup. Untuk informasi selengkapnya, lihat Ukuran data dan batas penyimpanan untuk OLTP Dalam Memori.

Ukuran data dan tutup penyimpanan untuk OLTP Dalam Memori

OLTP Dalam Memori menyertakan tabel dengan memori dioptimalkan, yang digunakan untuk menyimpan data pengguna. Tabel tersebut diperlukan agar pas dalam memori. Setiap tujuan layanan memiliki kuota memori atau batas untuk tabel yang dioptimalkan memori, yang dikenal sebagai penyimpanan OLTP Dalam Memori.

Setiap tujuan layanan database tunggal yang didukung dan setiap tujuan layanan kumpulan elastis mencakup sejumlah penyimpanan OLTP Dalam Memori tertentu:

Item berikut diperhitungkan dalam tutup penyimpanan OLTP Dalam Memori Anda:

  • Baris data pengguna aktif dalam tabel dengan memori dioptimalkan dan variabel tabel. Versi baris lama tidak dihitung terhadap batas.
  • Indeks pada tabel dengan memori dioptimalkan.
  • Overhead operasional operasi ALTER TABLE.

Jika Anda mencapai tutup, Anda menerima kesalahan di luar kuota, dan Anda tidak lagi dapat menyisipkan atau memperbarui data. Untuk mengurangi kesalahan ini, hapus data atau tingkatkan tujuan layanan database atau kumpulan elastis.

Untuk detail tentang memantau pemanfaatan penyimpanan OLTP Dalam Memori dan mengonfigurasi pemberitahuan saat Anda hampir mencapai batas, lihat Memantau penyimpanan OLTP Dalam Memori.

Tentang kumpulan elastis

Dengan kumpulan elastis, penyimpanan OLTP Dalam Memori dibagikan di semua database di kumpulan. Oleh karena itu, penggunaan dalam satu database dapat berpotensi memengaruhi database lain. Dua mitigasi untuk ini adalah:

  • Mengonfigurasi Max eDTU atau Max vCore untuk database yang lebih rendah dari jumlah eDTU atau vCore untuk kumpulan secara keseluruhan. Maksimum ini juga membatasi pemanfaatan penyimpanan OLTP Dalam Memori dalam database apa pun di kumpulan secara proporsional.
  • Mengonfigurasi Min eDTU atau Min vCore yang lebih besar dari 0. Minimum ini menjamin bahwa setiap database dalam kumpulan memiliki jumlah penyimpanan OLTP Dalam Memori yang tersedia yang sesuai dengan yang dikonfigurasi Min eDTU atau Min vCore.

Mengubah tingkat layanan database yang menggunakan teknologi OLTP Dalam Memori

OLTP Dalam Memori tidak didukung di tingkat layanan Tujuan Umum, Standar, dan Dasar Azure SQL Database. Oleh karena itu, tidak mungkin untuk menskalakan database yang memiliki objek OLTP Dalam Memori ke salah satu tingkatan ini. Jika Anda ingin menskalakan database ke salah satu tingkat layanan ini, hapus semua tabel dan jenis tabel yang dioptimalkan memori serta semua modul T-SQL yang dikompilasi secara asli, atau konversikan ke objek berbasis disk dan modul T-SQL reguler.

Saat Anda menurunkan skala database Business Critical atau Premium, data dalam tabel yang dioptimalkan memori harus pas dalam penyimpanan OLTP Dalam Memori yang tersedia dalam tujuan layanan tujuan database atau kumpulan elastis. Jika Anda mencoba menurunkan skala database atau kumpulan elastis, atau memindahkan database ke kumpulan elastis, dan tujuan layanan tujuan tidak memiliki penyimpanan OLTP Dalam Memori yang cukup, operasi gagal.

Menentukan apakah objek OLTP Dalam Memori ada

Ada cara terprogram untuk menemukan apakah database tertentu mendukung OLTP Dalam Memori. Anda dapat menjalankan kueri T-SQL berikut:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

Jika kueri mengembalikan 1, OLTP Dalam Memori didukung dalam database ini.

Kueri berikut mengidentifikasi semua objek yang perlu dihapus sebelum database dapat diskalakan ke tingkat layanan Hyperscale, General Purpose, Standard, atau Basic:

SELECT * FROM sys.tables WHERE is_memory_optimized = 1;
SELECT * FROM sys.table_types WHERE is_memory_optimized = 1;
SELECT * FROM sys.sql_modules WHERE uses_native_compilation = 1;

Penyimpan kolom dalam memori

Teknologi penyimpan kolom dalam memori memungkinkan Anda untuk menyimpan dan mengkueri sejumlah besar data dalam tabel. Teknologi penyimpan kolom menggunakan format penyimpanan data berbasis kolom dan pemrosesan kueri batch untuk mencapai perolehan hingga 10 kali performa kueri dalam beban kerja OLAP melalui penyimpanan tradisional berorientasi baris. Anda juga dapat memperoleh keuntungan hingga 10 kali pemadatan data atas ukuran data yang tidak dipadatkan.

Ada dua jenis indeks penyimpan kolom yang bisa Anda gunakan untuk menata data Anda:

  • Penyimpan kolom berkluster yang semua datanya dalam tabel diatur dalam format kolom. Dalam jenis indeks ini, semua baris dalam tabel ditempatkan dalam format kolom yang sangat memadatkan data dan memungkinkan Anda menjalankan kueri dan laporan analitik cepat pada tabel. Bergantung pada sifat data Anda, ukuran data Anda mungkin berkurang 10x-100x. Indeks penyimpan kolom berkluster juga memungkinkan penyerapan cepat data dalam jumlah besar (beban massal) karena batch besar data yang lebih besar dari 100.000 baris dikompresi sebelum disimpan di disk. Jenis indeks ini adalah pilihan yang baik untuk skenario gudang data klasik.
  • Penyimpan kolom non-kluster tempat data disimpan dalam tabel rowstore tradisional dan ada indeks tambahan dalam format penyimpan kolom yang digunakan untuk kueri analitik. Jenis indeks ini memungkinkan Pemrosesan Analitik Transaksional Hibrid (HTAP): kemampuan untuk menjalankan analitik real-time yang cepat pada beban kerja transaksional. Kueri OLTP dijalankan pada tabel rowstore yang dioptimalkan untuk mengakses set kecil baris, sementara kueri OLAP dijalankan pada indeks penyimpan kolom yang merupakan pilihan yang lebih baik untuk pemindaian dan analitik. Pengoptimal kueri secara dinamis memilih format rowstore atau penyimpan kolom berdasarkan kueri. Indeks penyimpan kolom noncluster tidak mengurangi ukuran data karena himpunan data asli disimpan dalam tabel rowstore asli tanpa perubahan apa pun. Namun, ukuran indeks penyimpan kolom tambahan adalah urutan besarnya lebih kecil dari indeks pohon B yang setara.

Catatan

Teknologi penyimpan kolom dalam memori hanya menyimpan data yang diperlukan untuk diproses dalam memori, sementara data yang tidak dapat pas dalam memori disimpan pada disk. Oleh karena itu, jumlah data dalam struktur penyimpan kolom dapat melebihi jumlah memori yang tersedia.

Ukuran dan penyimpanan data untuk indeks penyimpan kolom

Indeks penyimpan kolom tidak diperlukan untuk sepenuhnya pas dalam memori. Oleh karena itu, satu-satunya tutup pada ukuran indeks adalah ukuran database keseluruhan maksimum, yang didokumentasikan dalam model pembelian berbasis DTU dan artikel model pembelian berbasis vCore.

Saat Anda menggunakan indeks penyimpan kolom berkluster, kompresi kolom digunakan untuk penyimpanan tabel dasar. Kompresi ini dapat secara signifikan mengurangi jejak penyimpanan data pengguna Anda, yang berarti Anda dapat memasukkan lebih banyak data dalam database. Rasio kompresi dapat ditingkatkan lebih lanjut dengan kompresi pengarsipan kolom. Jumlah kompresi yang dapat Anda capai tergantung pada sifat data, tetapi 10 kali kompresi tidaklah jarang.

Misalnya, jika Anda memiliki database dengan ukuran maksimum 1 terabyte (TB) dan Anda mencapai 10 kali kompresi dengan menggunakan indeks penyimpan kolom, Anda dapat memasukkan total 10 TB data pengguna dalam database.

Saat Anda menggunakan indeks penyimpan kolom tidak berkluster, tabel dasar masih disimpan dalam format rowstore tradisional. Oleh karena itu, penghematan penyimpanan tidak signifikan seperti indeks penyimpan kolom berkluster. Namun, jika Anda mengganti banyak indeks nonclustered tradisional dengan satu indeks penyimpan kolom, Anda masih dapat melihat penghematan keseluruhan dalam jejak penyimpanan untuk tabel. Anda juga dapat menggunakan kompresi data rowstore untuk tabel dasar.

Mengubah tingkat layanan database yang berisi indeks penyimpan kolom

Jika Anda menggunakan model pembelian DTU dan database Anda berisi indeks penyimpan kolom, aplikasi Anda mungkin berhenti berfungsi jika Anda menskalakan database Anda di bawah tujuan layanan S3. Indeks penyimpan kolom hanya didukung di tingkat layanan Hyperscale, Business Critical, dan Premium, serta di tingkat layanan Standar jika menggunakan S3 ke atas. Indeks penyimpan kolom tidak didukung di tingkat layanan Dasar. Saat Anda menskalakan database Anda ke tingkat layanan atau tujuan layanan yang tidak didukung, indeks penyimpan kolom Anda menjadi tidak tersedia. Sistem mempertahankan indeks saat Anda menjalankan pernyataan DML, tetapi tidak pernah menggunakan indeks. Jika nanti Anda menskalakan kembali ke tingkat layanan atau tujuan layanan yang didukung, indeks penyimpan kolom Anda segera siap untuk digunakan lagi.

Jika Anda memiliki indeks penyimpan kolom berkluster , seluruh tabel menjadi tidak tersedia jika database diskalakan ke tingkat layanan atau tujuan layanan yang tidak didukung. Hilangkan semua indeks penyimpan kolom berkluster , ganti dengan indeks atau tumpukan berkluster rowstore, sebelum operasi penskalakan.

Konten terkait