Bagikan melalui

Pertimbangan perangkat keras untuk OLTP Dalam Memori di SQL Server

  • Artikel

OLTP Dalam Memori menggunakan memori dan disk dengan cara yang berbeda dari tabel berbasis disk tradisional. Peningkatan performa yang Anda lihat dengan OLTP Dalam Memori bergantung pada perangkat keras yang Anda gunakan. Dalam artikel ini, kami membahas beberapa pertimbangan perangkat keras umum, dan memberikan panduan umum untuk digunakan perangkat keras dengan OLTP Dalam Memori.

Catatan

Artikel ini adalah blog yang diterbitkan pada 1 Agustus 2013, oleh tim Microsoft SQL Server 2014. Halaman web blog sedang dihentikan.

SQL Server In-Memory-OLTP

CPU

OLTP Dalam Memori tidak memerlukan server kelas atas untuk mendukung beban kerja OLTP throughput tinggi. Sebaiknya gunakan server kelas menengah dengan dua soket CPU. Karena peningkatan throughput yang diaktifkan oleh OLTP Dalam Memori, dua soket kemungkinan akan cukup untuk kebutuhan bisnis Anda.

Sebaiknya aktifkan multithreading simultan (SMT) dengan OLTP Dalam Memori. Dengan beberapa beban kerja OLTP, kami telah melihat perolehan performa hingga 40% saat menggunakan SMT.

Memori

Semua tabel yang dioptimalkan memori berada sepenuhnya dalam memori. Oleh karena itu, Anda harus memiliki cukup memori fisik untuk tabel itu sendiri dan untuk mempertahankan beban kerja yang berjalan terhadap database - berapa banyak memori yang sebenarnya Anda butuhkan benar-benar tergantung pada beban kerja, tetapi sebagai titik awal Anda membutuhkan memori yang cukup tersedia sekitar dua kali ukuran data. Anda juga memerlukan memori yang cukup untuk kumpulan buffer jika beban kerja juga beroperasi pada tabel berbasis disk tradisional.

Untuk menentukan berapa banyak memori yang digunakan tabel yang dioptimalkan memori tertentu, jalankan kueri berikut:

select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;

Hasilnya menunjukkan memori yang digunakan untuk tabel yang dioptimalkan memori dan indeksnya. Data tabel menyertakan data pengguna, dan semua versi baris lama yang masih diperlukan dengan menjalankan transaksi, atau belum dibersihkan oleh sistem. Memori yang digunakan oleh indeks hash konstan, dan tidak bergantung pada jumlah baris dalam tabel.

Penting untuk diingat ketika Anda menggunakan OLTP Dalam Memori bahwa seluruh database Anda tidak perlu pas dalam memori. Anda dapat memiliki database multi-Terabyte dan masih mendapat manfaat dari OLTP Dalam Memori, selama ukuran data panas Anda (yaitu, tabel yang dioptimalkan memori) tidak melebihi 256 GB. Jumlah maksimum file data titik pemeriksaan yang dapat dikelola SQL Server untuk satu database adalah 4.000, dengan setiap file adalah 128 MB. Meskipun ini akan memberikan maksimum teoritis 512 GB, untuk menjamin bahwa SQL Server dapat mengikuti penggabungan file titik pemeriksaan dan tidak mencapai batas 4.000 file, kami mendukung hingga 256 GB. Batas ini hanya menerapkan tabel yang dioptimalkan memori; tidak ada batasan ukuran seperti itu pada tabel berbasis disk tradisional dalam database SQL Server yang sama.

Tabel yang dioptimalkan memori (NDT) yang tidak tahan lama, yaitu tabel yang dioptimalkan memori dengan DURABILITY=SCHEMA_ONLY tidak bertahan pada disk. Meskipun NDT tidak dibatasi oleh jumlah file titik pemeriksaan, hanya 256 GB yang didukung. Pertimbangan untuk drive log dan data di sisa posting ini tidak berlaku untuk tabel yang tidak tahan lama, karena data hanya ada dalam memori.

Kandar log

Catatan log yang berkaitan dengan tabel yang dioptimalkan memori ditulis ke log transaksi database, bersama dengan rekaman log SQL Server lainnya.

Selalu penting untuk menempatkan file log pada drive yang memiliki latensi rendah, sehingga transaksi tidak perlu menunggu terlalu lama, dan untuk mencegah pertikaian pada I/O log. Sistem Anda berjalan secepat komponen terlambat Anda (hukum Amdahl). Anda perlu memastikan bahwa, saat menjalankan OLTP Dalam Memori, perangkat I/O log Anda tidak menjadi hambatan. Sebaiknya gunakan perangkat penyimpanan dengan latensi rendah, setidaknya SSD.

Tabel yang dioptimalkan memori menggunakan bandwidth log yang lebih sedikit daripada tabel berbasis disk, karena tidak mencatat operasi indeks dan tidak mencatat rekaman UNDO. Ini dapat membantu meringankan ketidakcocokan I/O log.

Drive data

Persistensi tabel yang dioptimalkan memori menggunakan file titik pemeriksaan menggunakan I/O streaming. Oleh karena itu, file-file ini tidak memerlukan drive dengan latensi rendah atau I/O acak cepat. Sebaliknya, faktor utama untuk drive ini adalah kecepatan I/O berurutan dan bandwidth adaptor bus host (HBA). Dengan demikian, Anda tidak memerlukan SSD untuk file titik pemeriksaan; Anda dapat menempatkannya pada spindel performa tinggi (misalnya, SAS), selama kecepatan I/O berurutan mereka memenuhi kebutuhan Anda.

Faktor terbesar dalam menentukan persyaratan kecepatan adalah RTO [Tujuan Waktu Pemulihan] Anda pada menghidupkan ulang server. Selama pemulihan database, semua data dalam tabel yang dioptimalkan memori perlu dibaca dari disk, ke dalam memori. Pemulihan database terjadi pada kecepatan baca berurutan subsistem I/O Anda; disk adalah hambatan.

Untuk memenuhi persyaratan RTO yang ketat, sebaiknya sebarkan file titik pemeriksaan melalui beberapa disk, dengan menambahkan beberapa kontainer ke grup file MEMORY_OPTIMIZED_DATA. SQL Server mendukung beban paralel file titik pemeriksaan dari beberapa drive – pemulihan terjadi pada kecepatan agregat drive.

Dalam hal kapasitas disk, kami sarankan memiliki 2 - 3 kali ukuran tabel yang dioptimalkan memori yang tersedia.

Konten terkait