Pengantar Tabel Memory-Optimized
Berlaku untuk:
SQL Server (semua versi yang didukung) Azure SQL Database Azure SQL Managed Instance
Tabel yang dioptimalkan memori dibuat menggunakan CREATE TABLE (Transact-SQL).
Tabel yang dioptimalkan memori sepenuhnya tahan lama secara default, dan, seperti transaksi pada tabel berbasis disk (tradisional), transaksi pada tabel yang dioptimalkan memori sepenuhnya atomik, konsisten, terisolasi, dan tahan lama (ACID). Tabel yang dioptimalkan memori dan prosedur tersimpan yang dikompilasi secara asli hanya mendukung subset fitur SQL Transact.
Dimulai dengan SQL Server 2016, dan dalam Azure SQL Database, tidak ada batasan untuk kolase atau halaman kode yang khusus untuk In-Memory OLTP.
Penyimpanan utama untuk tabel yang dioptimalkan memori adalah memori utama. Baris dalam tabel dibaca dari dan ditulis ke memori. Salinan kedua data tabel dipertahankan pada disk, tetapi hanya untuk tujuan durabilitas. Lihat Membuat dan Mengelola Storage untuk Objek Memory-Optimized untuk informasi selengkapnya tentang tabel yang tahan lama. Data dalam tabel yang dioptimalkan memori hanya dibaca dari disk selama pemulihan database (misalnya setelah server dimulai ulang).
Untuk perolehan performa yang lebih besar, In-Memory OLTP mendukung tabel tahan lama dengan durabilitas transaksi tertunda. Transaksi tahan lama yang tertunda disimpan ke disk segera setelah transaksi dilakukan dan kontrol dikembalikan ke klien. Sebagai imbalan atas peningkatan performa, transaksi yang diterapkan yang belum disimpan ke disk hilang dalam crash server atau failover.
Selain tabel default yang dioptimalkan memori tahan lama, SQL Server juga mendukung tabel yang dioptimalkan memori yang tidak tahan lama, yang tidak dicatat dan datanya tidak bertahan pada disk. Ini berarti bahwa transaksi pada tabel ini tidak memerlukan IO disk apa pun, tetapi data tidak akan dipulihkan jika ada crash atau failover server.
In-Memory OLTP terintegrasi dengan SQL Server untuk memberikan pengalaman yang mulus di semua bidang seperti pengembangan, penyebaran, pengelolaan, dan dukungan. Database dapat berisi dalam memori serta objek berbasis disk.
Baris dalam tabel yang dioptimalkan memori diberi versi. Ini berarti bahwa setiap baris dalam tabel berpotensi memiliki beberapa versi. Semua versi baris dipertahankan dalam struktur data tabel yang sama. Penerapan versi baris digunakan untuk memungkinkan pembacaan dan penulisan bersamaan pada baris yang sama. Untuk informasi selengkapnya tentang bacaan dan tulis bersamaan pada baris yang sama, lihat Transaksi dengan tabel Memory-Optimized.
Gambar berikut mengilustrasikan multi-versi. Gambar memperlihatkan tabel dengan tiga baris dan setiap baris memiliki versi yang berbeda.
Tabel memiliki tiga baris: r1, r2, dan r3. r1 memiliki tiga versi, r2 memiliki dua versi, dan r3 memiliki empat versi. Perhatikan bahwa versi yang berbeda dari baris yang sama tidak selalu menempati lokasi memori berturut-turut. Versi baris yang berbeda dapat tersebar di seluruh struktur data tabel.
Struktur data tabel yang dioptimalkan memori dapat dilihat sebagai kumpulan versi baris. Baris dalam tabel berbasis disk diatur dalam halaman dan jangkauan, dan baris individual yang ditangani menggunakan nomor halaman dan offset halaman, versi baris dalam tabel yang dioptimalkan memori ditangani menggunakan penunjuk memori 8-byte.
Data dalam tabel yang dioptimalkan memori diakses dengan dua cara:
Melalui prosedur tersimpan yang dikompilasi secara asli.
Melalui transact-SQL yang ditafsirkan, di luar prosedur tersimpan yang dikompilasi secara asli. Pernyataan SQL Transact ini mungkin berada di dalam prosedur tersimpan yang ditafsirkan atau mungkin merupakan pernyataan transact-SQL ad-hoc.
Mengakses Data dalam Tabel Memory-Optimized
Tabel yang dioptimalkan memori dapat diakses paling efisien dari prosedur tersimpan yang dikompilasi secara asli (Prosedur Tersimpan yang Dikompilasi Secara Asli). Tabel yang dioptimalkan memori juga dapat diakses dengan transact-SQL yang ditafsirkan (tradisional). Transact-SQL yang ditafsirkan mengacu pada mengakses tabel yang dioptimalkan memori tanpa prosedur tersimpan yang dikompilasi secara asli. Beberapa contoh akses Transact-SQL yang ditafsirkan termasuk mengakses tabel yang dioptimalkan memori dari pemicu DML, ad hoc Transact-SQL batch, tampilan, dan fungsi bernilai tabel.
Tabel berikut ini meringkas akses SQL Transact-SQL asli dan tertafsirkan untuk berbagai objek.
| Fitur | Akses Menggunakan Prosedur Tersimpan yang Dikompilasi Secara Asli | Akses SQL Transact yang Ditafsirkan | Akses CLR |
|---|---|---|---|
| Tabel yang dioptimalkan memori | Ya | Ya | Tidak* |
| Jenis tabel yang dioptimalkan memori | Ya | Ya | Tidak |
| Prosedur tersimpan yang dikompilasi secara asli | Bersarangnya prosedur tersimpan yang dikompilasi secara asli sekarang didukung. Anda dapat menggunakan sintaks EXECUTE di dalam prosedur tersimpan, selama prosedur yang dirujuk juga dikompilasi secara asli. | Ya | Tidak* |
*Anda tidak dapat mengakses tabel yang dioptimalkan memori atau prosedur tersimpan yang dikompilasi secara asli dari koneksi konteks (koneksi dari SQL Server saat menjalankan modul CLR). Namun, Anda dapat membuat dan membuka koneksi lain tempat Anda dapat mengakses tabel yang dioptimalkan memori dan prosedur tersimpan yang dikompilasi secara asli.
Performa dan skalabilitas
Faktor-faktor berikut akan memengaruhi perolehan performa yang dapat dicapai dengan In-Memory OLTP:
Komunikasi: Aplikasi dengan banyak panggilan ke prosedur tersimpan singkat mungkin melihat perolehan performa yang lebih kecil dibandingkan dengan aplikasi dengan lebih sedikit panggilan dan lebih banyak fungsionalitas yang diterapkan di setiap prosedur tersimpan.
Eksekusi SQL Transaksi: In-Memory OLTP mencapai performa terbaik saat menggunakan prosedur tersimpan yang dikompilasi secara asli daripada menafsirkan prosedur tersimpan atau eksekusi kueri. Mungkin ada manfaat untuk mengakses tabel yang dioptimalkan memori dari prosedur tersimpan tersebut.
Pemindaian Rentang vs Pencarian Titik: Indeks non-kluster yang dioptimalkan memori mendukung pemindaian rentang dan pemindaian yang diurutkan. Untuk pencarian titik, indeks hash yang dioptimalkan memori memiliki performa yang lebih baik daripada indeks nonkluster yang dioptimalkan memori. Indeks nonkluster yang dioptimalkan memori memiliki performa yang lebih baik daripada indeks berbasis disk.
- Mulai SQL Server 2016, rencana kueri untuk tabel yang dioptimalkan memori dapat memindai tabel secara paralel. Ini meningkatkan performa kueri analitik.
- Indeks hash juga menjadi dapat dipindai secara paralel pada SQL Server 2016.
- Indeks nonkluster juga menjadi dapat dipindai secara paralel pada SQL Server 2016.
- Indeks penyimpan kolom telah dapat dipindai secara paralel sejak awal di SQL Server 2014.
Operasi indeks: Operasi indeks tidak dicatat, dan hanya ada dalam memori.
Concurrency: Aplikasi yang performanya dipengaruhi oleh konkurensi tingkat mesin, seperti ketidakcocokan atau pemblokiran kait, meningkat secara signifikan ketika aplikasi berpindah ke In-Memory OLTP.
Tabel berikut ini mencantumkan masalah performa dan skalabilitas yang umumnya ditemukan dalam database relasional dan bagaimana In-Memory OLTP dapat meningkatkan performa.
| Masalah | Dampak OLTP In-Memory |
|---|---|
| Performa Penggunaan sumber daya tinggi (CPU, I/O, jaringan atau memori). |
CPU Prosedur tersimpan yang dikompilasi secara asli dapat menurunkan penggunaan CPU secara signifikan karena memerlukan instruksi yang jauh lebih sedikit untuk menjalankan pernyataan SQL Transact dibandingkan dengan prosedur tersimpan yang ditafsirkan. In-Memory OLTP dapat membantu mengurangi investasi perangkat keras dalam beban kerja yang diskalakan karena satu server berpotensi memberikan throughput lima hingga sepuluh server. I/O Jika Anda mengalami hambatan I/O dari pemrosesan ke halaman data atau indeks, In-Memory OLTP dapat mengurangi penyempitan. Selain itu, titik pemeriksaan objek In-Memory OLTP berkelanjutan dan tidak menyebabkan peningkatan mendadak dalam operasi I/O. Namun, jika kumpulan tabel kritis performa yang berfungsi tidak sesuai dalam memori, In-Memory OLTP tidak akan meningkatkan performa karena membutuhkan data untuk menjadi residen memori. Jika Anda mengalami hambatan I/O dalam pengelogan, In-Memory OLTP dapat mengurangi penyempitan karena tidak terlalu banyak pengelogan. Jika satu atau beberapa tabel yang dioptimalkan memori dikonfigurasi sebagai tabel yang tidak tahan lama, Anda dapat menghilangkan pengelogan untuk data. Memori In-Memory OLTP tidak menawarkan manfaat performa apa pun. In-Memory OLTP dapat memberikan tekanan ekstra pada memori karena objek perlu menjadi residen memori. Jaringan In-Memory OLTP tidak menawarkan manfaat performa apa pun. Data perlu dikomunikasikan dari tingkat data ke tingkat aplikasi. |
| Skalabilitas Sebagian besar masalah penskalaan dalam aplikasi SQL Server disebabkan oleh masalah konkurensi seperti ketidakcocokan pada kunci, kait, dan spinlock. |
Ketidakcocokan Kait Skenario umum adalah ketidakcocokan pada halaman terakhir indeks saat menyisipkan baris secara bersamaan dalam urutan kunci. Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan ketidakcocokan kait akan dihapus sepenuhnya. Pertikaian Spinlock Karena In-Memory OLTP tidak mengambil kait saat mengakses data, masalah skalabilitas yang terkait dengan ketidakcocokan spinlock sepenuhnya dihapus. Mengunci Ketidakcocokan Terkait Jika aplikasi database Anda mengalami masalah pemblokiran antara operasi baca dan tulis, In-Memory OLTP menghapus masalah pemblokiran karena menggunakan bentuk baru kontrol konkurensi optimis untuk menerapkan semua tingkat isolasi transaksi. In-Memory OLTP tidak menggunakan TempDB untuk menyimpan versi baris. Jika masalah penskalaan disebabkan oleh konflik antara dua operasi tulis, seperti dua transaksi bersamaan yang mencoba memperbarui baris yang sama, In-Memory OLTP memungkinkan satu transaksi berhasil dan gagal pada transaksi lainnya. Transaksi yang gagal harus diajukan kembali baik secara eksplisit maupun implisit, mencoba kembali transaksi. Dalam kedua kasus, Anda perlu membuat perubahan pada aplikasi. Jika aplikasi Anda sering mengalami konflik antara dua operasi tulis, nilai penguncian optimis berkurang. Aplikasi ini tidak cocok untuk In-Memory OLTP. Sebagian besar aplikasi OLTP tidak memiliki konflik tulis kecuali konflik disebabkan oleh eskalasi kunci. |
Keamanan Row-Level dalam Tabel Memory-Optimized
Keamanan Tingkat Baris didukung dalam tabel yang dioptimalkan memori. Menerapkan kebijakan keamanan Row-Level ke tabel yang dioptimalkan memori pada dasarnya sama dengan tabel berbasis disk, kecuali bahwa fungsi bernilai tabel sebaris yang digunakan sebagai predikat keamanan harus dikompilasi secara asli (dibuat menggunakan opsi WITH NATIVE_COMPILATION). Untuk detailnya, lihat bagian Kompatibilitas Lintas Fitur di topik Keamanan Tingkat Baris .
Berbagai fungsi keamanan bawaan yang penting untuk keamanan tingkat baris telah diaktifkan untuk tabel dalam memori. Untuk detailnya, lihat Fungsi Bawaan dalam Modul yang Dikompilasi Secara Asli.
EXECUTE AS CALLER - Semua modul asli sekarang mendukung dan menggunakan EXECUTE AS CALLER secara default, bahkan jika petunjuk tidak ditentukan. Ini karena diharapkan bahwa semua fungsi predikat keamanan tingkat baris akan menggunakan EXECUTE AS CALLER sehingga fungsi (dan fungsi bawaan apa pun yang digunakan di dalamnya) akan dievaluasi dalam konteks pengguna panggilan.
EXECUTE AS CALLER memiliki hit performa kecil (sekitar10%) yang disebabkan oleh pemeriksaan izin pada pemanggil. Jika modul menentukan EXECUTE AS OWNER atau EXECUTE AS SELF secara eksplisit, pemeriksaan izin ini dan biaya performa terkait akan dihindari. Namun, menggunakan salah satu opsi ini bersama dengan fungsi bawaan di atas akan menimbulkan hit performa yang jauh lebih tinggi karena peralihan konteks yang diperlukan.
Skenario
Untuk diskusi singkat tentang skenario umum di mana SQL Server In-Memory OLTP dapat meningkatkan performa, lihat OLTP Dalam Memori.