Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 menguntungkan dari OLTP Dalam Memori adalah: pemrosesan transaksi dengan throughput tinggi seperti perdagangan dan permainan, penyimpanan sementara, pemuatan data, dan skenario tabel sementara serta variabel tabel.
- Indeks penyimpan kolom terkluster mengurangi ukuran penyimpanan Anda (hingga 10 kali) dan meningkatkan performa untuk laporan dan kueri analitik. Anda dapat menggunakannya dengan tabel fakta di mart data Anda untuk memuat lebih banyak data ke dalam database Anda dan meningkatkan kinerja. 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 dioptimalkan untuk memori untuk HTAP memungkinkan Anda melakukan pemrosesan transaksi dengan cepat, dan secara bersamaan menjalankan kueri analitik 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 yang terperinci untuk menunjukkan keunggulan kinerja teknologi In-Memory OLTP, menggunakan AdventureWorksLT
database sampel dan ostress.exe, lihat Sampel In-Memory di Azure SQL Database.
Keuntungan teknologi in-memory
Karena kueri dan pemrosesan transaksi yang lebih efisien, teknologi in-memory 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 tingkatan harga, sambil tetap melihat peningkatan performa dengan teknologi penyimpanan 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
In-Memory OLTP tersedia di lapisan layanan Premium (DTU) dan Business Critical (vCore) Azure SQL Database. Tingkat layanan Hyperscale mendukung sebagian objek In-Memory OLTP. Untuk informasi selengkapnya, lihat Batasan Hyperscale.
Indeks Columnstore tersedia dalam semua tingkat layanan kecuali tingkat Dasar dan tingkat Standar ketika tujuan layanan di bawah S3. Untuk informasi selengkapnya, lihat Mengubah tingkat layanan database yang berisi indeks penyimpan kolom.
Artikel ini menjelaskan aspek In-Memory OLTP dan indeks kolomstore yang spesifik untuk Azure SQL Database, dan juga menyertakan sampel yang memungkinkan Anda untuk melihat:
- Dampak teknologi ini pada batas penyimpanan dan ukuran data.
- Cara mengelola pergerakan database yang menggunakan teknologi ini di antara berbagai tingkat harga.
- Contoh penggunaan OLTP dalam Memori, serta indeks columnstore.
Untuk informasi selengkapnya tentang teknologi dalam memori di SQL Server, lihat:
- Gambaran umum dan skenario penggunaan OLTP Dalam Memori (termasuk referensi ke studi kasus pelanggan dan informasi untuk memulai)
- Dokumentasi untuk OLTP Dalam Memori
- Panduan Indeks Penyimpan Kolom
- Pemrosesan transaksional/analitis hibrida (HTAP), juga dikenal sebagai analitik operasional real-time
OLTP di 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 asli kueri, dan akses data tanpa 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 pakai (
SCHEMA_AND_DATA
) yang baris-barisnya disimpan dalam memori dapat 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).
-
Tabel tahan pakai (
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 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 kapasitas penyimpanan untuk In-Memory OLTP.
- Panduan cepat pada OLTP Dalam Memori: Panduan 1: Teknologi Dalam Memori OLTP untuk Meningkatkan Performa T-SQL.
Ukuran data dan batas penyimpanan untuk OLTP Dalam Memori
OLTP In-Memory menyertakan tabel yang dioptimalkan untuk memori, 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 In-Memory OLTP storage.
Setiap tujuan layanan database tunggal yang didukung dan setiap tujuan layanan kumpulan elastis mencakup sejumlah penyimpanan OLTP Dalam Memori tertentu:
- Batas sumber daya berbasis DTU - database tunggal
- Batas sumber daya berbasis DTU - kumpulan elastis
- Batas sumber daya berbasis vCore - database tunggal
- Batas sumber daya berbasis vCore - kumpulan elastis
Item-item berikut dihitung dalam batas penyimpanan OLTP In-Memory Anda:
- Baris data pengguna aktif dalam tabel yang dioptimalkan untuk memori dan variabel tabel. Versi baris lama tidak dihitung terhadap batas maksimal.
- Indeks pada tabel yang dioptimalkan untuk memori.
- Overhead operasional operasi ALTER TABLE.
Jika Anda mencapai batas, Anda menerima kesalahan kuota terlampaui, dan Anda tidak dapat lagi 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 peringatan saat Anda hampir mencapai batas, lihat Memantau penyimpanan OLTP Dalam Memori.
Tentang kumpulan elastis
Dengan menggunakan kumpulan elastis, penyimpanan OLTP Dalam Memori dibagikan di antara semua database dalam kumpulan tersebut. Oleh karena itu, penggunaan dalam satu database dapat berpotensi memengaruhi database lain. Dua mitigasi untuk ini adalah:
- Konfigurasikan
Max eDTU
atauMax vCore
untuk basis data dengan jumlah yang lebih rendah dari jumlah eDTU atau vCore untuk seluruh kumpulan. Maksimum ini juga membatasi pemanfaatan penyimpanan OLTP Dalam Memori dalam database apa pun di kumpulan secara proporsional. - Konfigurasikan
Min eDTU
atauMin 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 dikonfigurasiMin eDTU
atauMin 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.
- Non-klustered columnstore di mana data disimpan dalam tabel penyimpan baris tradisional dan terdapat 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 jauh lebih kecil daripada indeks pohon B yang setara.
Catatan
Teknologi kolom dalam penyimpanan memori hanya menyimpan data yang diperlukan untuk diproses dalam memori, sementara data yang tidak dapat muat dalam memori disimpan ke dalam 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 wajib sepenuhnya muat dalam memori. Oleh karena itu, satu-satunya batas ukuran indeks adalah ukuran maksimal keseluruhan database, yang didokumentasikan dalam artikel 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 kolom, Anda masih dapat melihat penghematan keseluruhan dalam ruang 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 berkluster rowstore atau heap, sebelum operasi penskalaan.
Konten terkait
- Panduan Cepat 1: Teknologi OLTP Dalam Memori untuk meningkatkan Performa T-SQL
- Gunakan OLTP Dalam Memori pada aplikasi Azure SQL yang sudah ada
- Gambaran umum dan skenario penggunaan OLTP Dalam Memori
- Memantau penyimpanan OLTP dalam memori
- Sampel dalam memori di Azure SQL Database
- Blog: OLTP Dalam Memori di Azure SQL Database
- Pelajari tentang In-Memory OLTP
- Pelajari tentang indeks penyimpan kolom
- Pelajari tentang analitik operasional real time
- Artikel teknis: OLTP Dalam Memori – Pola Beban Kerja Umum dan Pertimbangan Migrasi di SQL Server 2014