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 mendapat manfaat dari OLTP dalam memori adalah: pemrosesan transaksi throughput tinggi seperti perdagangan dan game, penyerapan data dari peristiwa atau perangkat IoT, penembolokan, beban data, dan skenario tabel sementara dan variabel tabel.
  • 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 keuntungan 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, Quorum Business Solutions dapat menggandakan beban kerja mereka sambil meningkatkan DTU sebesar 70%. Untuk informasi selengkapnya, lihat OLTP dalam memori di Azure SQL Database.

Catatan

Teknologi dalam memori tersedia di tingkat Premium dan Bisnis Penting dari Azure SQL Database.

Artikel ini menjelaskan aspek indeks OLTP dan penyimpan kolom dalam memori yang khusus untuk Azure SQL Database, dan juga menyertakan sampel:

  • Anda akan melihat dampak teknologi tersebut pada batas penyimpanan dan ukuran data.
  • Anda akan melihat cara mengelola pergerakan database yang menggunakan teknologi tersebut di antara berbagai tingkat harga.
  • Anda akan melihat dua sampel yang mengilustrasikan penggunaan OLTP dalam memori, serta indeks penyimpan kolom.

Untuk informasi selengkapnya tentang 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 berkinerja tinggi. Ada dua jenis tabel dengan memori dioptimalkan yang dapat digunakan dalam format rowstore dengan memori dioptimalkan:

    • Tabel yang tahan lama (SCHEMA_AND_DATA) di mana baris yang ditempatkan dalam memori dipertahankan setelah menghidupkan ulang server. 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

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

Ukuran data dan batas penyimpanan untuk OLTP dalam memori

OLTP dalam memori mencakup tabel yang dioptimalkan memori, yang digunakan untuk menyimpan data pengguna. Tabel tersebut diperlukan agar pas dalam memori. Karena Anda mengelola memori langsung di SQL Database, kami memiliki konsep kuota untuk data pengguna. Ide ini disebut sebagai penyimpanan OLTP dalam memori.

Setiap tingkat harga database tunggal yang didukung dan setiap tingkat harga kumpulan elastis mencakup sejumlah penyimpanan OLTP dalam memori tertentu.

Item berikut dihitung untuk batas 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 tingkat harga database atau kumpulan.

Untuk detail tentang memantau pemanfaatan penyimpanan OLTP dalam memori dan mengonfigurasi pemberitahuan saat Anda hampir mencapai batas, lihat Memantau penyimpanan 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 MaxvCore untuk database yang lebih rendah dari jumlah eDTU atau vCore untuk kumpulan secara keseluruhan. Maksimum ini membatasi pemanfaatan penyimpanan OLTP dalam memori, dalam database apa pun di kumpulan, dengan ukuran yang sesuai dengan jumlah eDTU.
  • Mengonfigurasi Min-eDTU atau MinvCore yang lebih besar dari 0. Minimum ini menjamin bahwa setiap database di kumpulan memiliki jumlah penyimpanan OLTP dalam memori yang tersedia yang sesuai dengan yang dikonfigurasi Min-eDTU atau vCore.

Mengubah tingkat layanan database yang menggunakan teknologi OLTP dalam memori

Anda selalu dapat meningkatkan database Anda ke tingkat yang lebih tinggi, seperti dari Tujuan Umum (vCore) ke Business Critical, atau Standard (DTU) ke Premium. Fungsionalitas dan sumber daya yang tersedia hanya meningkat.

Tetapi menurunkan tingkatan dapat berdampak negatif pada database Anda. Dampaknya sangat jelas ketika Anda menurunkan dari Business Critical ke Tujuan Umum (atau Premium ke Standar atau Dasar) saat database Anda berisi objek OLTP dalam memori. Anda dapat dengan mudah menemukan objek dalam memori di database Anda.

Tabel dengan memori dioptimalkan tidak tersedia setelah penurunan tingkat (meskipun tetap terlihat). Pertimbangan yang sama berlaku saat Anda menurunkan tingkat harga kumpulan elastis, atau memindahkan database dengan teknologi dalam memori, ke dalam kumpulan elastis Tujuan Umum, Standar, atau Dasar.

Penting

OLTP dalam memori tidak didukung dalam Tujuan Umum, atau tingkat DTU Standar atau Dasar Azure SQL Database. Oleh karena itu, tidak dimungkinkan untuk memindahkan database yang memiliki objek OLTP dalam memori ke salah satu tingkatan ini. Sebelum Anda menurunkan tingkat database, hapus semua tabel dan jenis tabel yang dioptimalkan memori serta semua modul T-SQL yang dikompilasi secara asli, atau konversikan ke objek berbasis baris.

Sumber daya penskalaan-turun di tingkat Bisnis Kritis: Data dalam tabel yang dioptimalkan memori harus pas dalam penyimpanan OLTP dalam memori yang terkait dengan tingkat database, atau tersedia di kumpulan elastis. Jika Anda mencoba menurunkan skala tingkat atau memindahkan database ke kumpulan yang tidak memiliki cukup penyimpanan OLTP dalam memori, operasi gagal.

Menentukan apakah objek dalam memori ada

Ada cara terprogram untuk memahami 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 bisa diturunkan tingkatnya ke Tujuan Umum, Standar, atau Dasar:

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 model penyimpan kolom yang bisa Anda gunakan untuk mengatur data Anda:

  • Penyimpan kolom berkluster yang semua datanya dalam tabel diatur dalam format kolom. Dalam model ini, semua baris dalam tabel ditempatkan dalam format kolom yang sangat memadatkan data dan memungkinkan Anda untuk menjalankan kueri dan laporan analitik cepat di tabel. Bergantung pada sifat data Anda, ukuran data Anda mungkin berkurang 10x-100x. Model 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. Model ini adalah pilihan yang baik untuk skenario gudang data klasik.
  • Penyimpan kolom tidak berkluster di mana data disimpan dalam tabel rowstore tradisional dan ada indeks dalam format penyimpan kolom yang digunakan untuk kueri analitik. Model ini memungkinkan Transaksi Hibrida/Pemrosesan Analitik (HTAP): kemampuan untuk menjalankan analitik real time yang berperforma 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 harus dalam 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 masuk ke dalam memori disimpan di disk. Oleh karena itu, jumlah data dalam struktur penyimpan kolom dalam memori dapat melebihi jumlah memori yang tersedia.

Ukuran dan penyimpanan data untuk indeks penyimpan kolom

Indeks penyimpan kolom tidak diperlukan agar 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. Dan kompresi tersebut dapat lebih ditingkatkan dengan kompresi arsip 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.

Mengubah tingkat layanan database yang berisi indeks penyimpan kolom

Menurunkan tingkat database tunggal ke Dasar atau Standar mungkin tidak memungkinkan jika tingkat target Anda di bawah S3. Indeks penyimpan kolom hanya didukung pada tingkat harga Penting Bisnis/Premium dan pada tingkat Standar, S3 ke atas, dan bukan pada tingkat Dasar. Saat Anda menurunkan tingkat database ke tingkat atau tingkat yang tidak didukung, indeks penyimpan kolom Anda menjadi tidak tersedia. Sistem mempertahankan indeks penyimpan kolom Anda, tetapi tidak pernah menggunakan indeks. Jika nanti Anda meningkatkan kembali ke tingkat atau tingkat yang didukung, indeks penyimpan kolom Anda segera siap untuk digunakan lagi.

Jika Anda memiliki indeks penyimpan kolom berkluster, seluruh tabel menjadi tidak tersedia setelah penurunan tingkat. Hilangkan semua indeks penyimpan kolom berkluster (dan ganti dengan indeks berkluster rowstore) sebelum Anda menurunkan tingkat database Anda ke tingkat atau tingkat yang tidak didukung.

Konten terkait