"20.000 IOPS per node adalah kinerja yang baik dengan latensi 5 ms." Untuk OLTP - no

Alasan penulisan artikel ini adalah ulasan yang sangat layak tentang Bagaimana kami menguji VMware vSAN ... CROC. Ulasan ini layak, tetapi memiliki frasa yang telah saya perjuangkan selama lebih dari satu dekade. Administrator penyimpanan, virtualizer, dan integrator berulang-ulang: "Penundaan 5 ms adalah indikator yang sangat baik." Bahkan angka 5 ms selama sepuluh tahun tidak berubah. Saya mendengar ini langsung dari admin yang sangat dihormati tidak kurang dari selusin kali. Dari yang kurang dihormati - lusinan, dan berapa kali saya membaca di Internet ... Tidak, tidak, tidak. Untuk beban OLTP 5 ms, terutama karena biasanya diukur, ini gagal epik. Saya harus menjelaskan alasan ini berkali-kali, kali ini saya memutuskan untuk mengumpulkan pikiran saya dalam bentuk yang dapat digunakan kembali.

Saya harus segera mengatakan bahwa tidak ada kesalahan seperti itu dalam artikel yang disebutkan di atas, tetapi frasa tersebut berfungsi sebagai pemicu.

Mulai yang khas

Segala sesuatu yang dijelaskan dalam artikel ini berlaku untuk DBMS umum yang digunakan untuk OLTP bisnis biasa. Sebagian besar dari semua saya memiliki pengalaman dengan MS SQL Server, tetapi, setidaknya untuk PostgeSQL, Oracle dan Sybase, banyak poin dan kesimpulan juga akan tetap benar.

Kinerja DBMS biasanya tidak senang dengan semua orang. Jika ada DBMS dalam sistem besar - dan tiba-tiba hampir selalu ada - maka DBMS ini menjadi hambatan. Nah, atau itu akan segera menjadi hambatan jika Anda mulai mengoptimalkan yang lainnya. Jadi, pelanggan datang dan berkata dengan suara manusia: "Tolong! Simpan! Mereka membayar $ NNNNNNNNN untuk server dan penyimpanan, tetapi kecepatannya tidak meningkat! Oh, dan administrator mengatur dan vendor berkonsultasi, tetapi masih tidak bergerak." Jika pengembang sistem sesuai dengan definisi Lavrov (kita dapat melakukannya tanpa penawaran harga yang tepat), dan spesialis operasi dan pemeliharaan "berjuang dengan insiden dengan me-reboot server", maka masalahnya sering kali sederhana dan bersahaja: tidak ada indeks, pertanyaan bengkok, kesalahan fatal konfigurasi (tentang dokumentasi yang dicetak tebal) ia mengatakan "Anda tidak bisa melakukan ini !!!" ), kunci berlebihan, kebuntuan dan omong kosong sederhana dan jelas lainnya. Ada banyak kasus seperti itu, sebagian besar, tetapi tidak semua. Jika sistem, dalam kompleksitas atau beban, telah melewati batas tak terlihat, maka ia akan mati karena masalah ini atau naik ke tingkat berikutnya.

Pada tingkat ini, server tidak lagi di bawah tabel direktur, disk tidak lagi di dalam server, tetapi dalam sistem penyimpanan, pengembang tahu tentang indeks, dan administrator sudah tahu PowerShell, dan manajer TI mulai mengatakan kata-kata pintar seperti SLA dan RPO / RTO. Situasi menarik muncul pada level ini:

• DBMS adalah hambatan.
• Server tampaknya mencukupi dalam segala hal.
• DBMS dapat ditingkatkan lebih lanjut secara programatik, tetapi sulit (beralih ke lisensi yang lebih mahal atau beralih ke "zona merah kurva Shipilev" untuk optimisasi)
• Sistem disk dibeli mahal dan, tampaknya, bahkan entah bagaimana dikonfigurasi.

Tapi tidak. Buaya tidak ditangkap, kelapa tidak tumbuh, dan kinerja sistemnya sama atau lebih rendah dari pada server lama. Saya mencari di sys.dm_os_waitsats dan melihat WRITELOG , PAGEIOLATCH_SH dan PAGEIOLATCH_EX di atas, waktu tunggu rata-rata adalah 5+ ms. Biasanya, cho: "Hei, admin dan DBA, di sini Anda memiliki sistem disk - bottleneck" dan di sini dimulai lagu lama sekitar 5 ms:

• Kami memiliki 5 ms untuk SLA
• Ya, kami memiliki resimen 20.000 IOPS
• Vendor memberi tahu kami bahwa semua file database bisa berada di satu partisi
• Kami memiliki virtualisasi dan hyperconvergence dan kami tidak dapat mengalokasikan disk terpisah di bawah basis data
• Menurut data kami, pemanfaatan server 5%
• Semuanya dikonfigurasi sesuai dengan rekomendasi
• Basis data Anda tidak membutuhkan banyak kinerja, ia tidak melakukan lebih dari 300 IOPS (dan kami memiliki rak untuk 20.000 IOPS)

By the way, semua hal di atas, tidak hanya tentang server "mereka", tetapi juga tentang layanan cloud dan virtualisasi. Ada banyak spesifikasinya sendiri, tetapi gambaran klinis tipikal hampir sama: basis data yang dioptimalkan secara moderat, staf pengembangan dan pemeliharaan yang cerdas, ada cadangan untuk prosesor dan memori, "pembuangan" dari investasi lebih lanjut hampir nol.

Jadi disini. Seluruh lagu ini tentang "5 ms" adalah omong kosong dan omong kosong. Jika Anda sendiri mengatakan ini, baca artikel ini. Dan jika mereka mengatakan ini kepada Anda, siapkan argumen. Sebelumnya, ketika saya mendengar kata-kata ini, saya marah, tetapi saya tidak lagi marah. Saya, seperti pot dengan petunia dari Hitchhiker's Guide to the Galaxy, hanya punya satu pemikiran: "Baiklah, sekali lagi ...".

Siapa yang harus disalahkan?

Mengapa database sangat lambat? Nah, tampaknya server tipikal dengan 20-64 core pada frekuensi 2-3 GHz mampu melakukan 50-150 miliar operasi sederhana, dan tes basis data maksimum (sintetis) menunjukkan pada mesin tersebut hanya 10.000-50000 transaksi per detik. Hai! Nah ini dari satu juta hingga selusin kemungkinan jutaan transaksi per transaksi. Ini tidak hanya banyak, sangat masuk akal.
Biaya overhead seperti ACID - persyaratan untuk transaksi.

• Sebuah keganjilan - baik seluruh transaksi selesai, atau keseluruhan tidak selesai.
• C onsistancy - di pintu masuk dan keluar transaksi, sistem berada dalam kondisi yang konsisten
• I solation - transaksi tidak melihat status perantara masing-masing
• D urability - jika transaksi telah berhasil diselesaikan (dilakukan), maka, terlepas dari keadaan, perubahan yang dibuat harus tetap dalam sistem.

Omong-omong, huruf-demi-huruf, persyaratan ini tidak dipenuhi hampir di mana saja dan tidak pernah, tetapi tidak pernah dalam sistem terdistribusi (teorema CAP mengganggu). Untuk situasi kami, persyaratan "D" kemungkinan besar lebih mahal daripada yang lain, persyaratan ini disediakan oleh mekanisme kunci semua DBMSs OLTP yang umum: WAL, log write-ahead (PostgeSQL), juga merupakan log transaksi (SQL Server), alias log REDO (Oracle). Ini dia - batu di leher produktivitas, dan itu adalah dasar dari transaksi Daya Tahan.

Apa itu WAL?

Mari kita lupakan sejenak tentang SSD modern, tentang sistem penyimpanan yang keren. Misalkan kita memiliki server, ia memiliki satu atau lebih disk.
Setiap transaksi, bahkan penyisipan satu catatan, setidaknya berpotensi, tetapi pada kenyataannya hampir selalu dan secara realistis tindakan non-atom. Kita hampir selalu perlu mengubah tidak hanya halaman tempat catatan itu berada, tetapi juga halaman indeks, mungkin halaman layanan. Selain itu, dalam transaksi yang sama halaman yang sama dapat berubah berkali-kali. Plus, transaksi lain dapat dilakukan secara paralel dengan kami. Selain itu - transaksi yang bertepatan waktu secara konstan "menarik" halaman yang sama. Jika kita menunggu setiap halaman dituliskan ke disk sebelum melanjutkan, yang pada dasarnya diperlukan oleh Daya Tahan, kita harus menulis berkali-kali lebih banyak dan menunggu setiap rekaman diselesaikan pada media yang tidak mudah menguap. Tidak ada cache, tidak ada pengaturan ulang operasi dalam antrian, jika tidak maka tidak akan ada integritas! Selain itu, kita perlu mencatat data mana yang sudah pada transaksi tetap dan mana yang belum (dan data mana yang sebelumnya). Untuk memahami - hard disk tunggal khas (HDD) dalam mode ini akan memberikan 50-100 IOPS dan ini telah konstan selama 20 tahun. Satu transaksi kecil akan membutuhkan 5-10 operasi penulisan. Ah, ya, untuk tahu apa yang harus direkam, Anda harus membacanya. Bahkan sistem OLTP yang sangat-sangat bisa ditulis membaca 3 kali lebih banyak daripada yang mereka tulis. Dengan demikian, biaya transaksi kami 20-40 IO, yang berarti 0,2-0,8 detik per disk.
2 transaksi per detik. Tidak cukup? Mari mencoba menyebarkan disk? Oh, tapi kita masih harus menunggu sampai yang sebelumnya direkam dan tidak ada paralelisme pada akhirnya. Bagaimana menjadi Dan mari kita mulai file log di mana kita akan secara berurutan merekam semua operasi penulisan dalam database dan tanda transaksi! Pro:

• Informasi tentang operasi bisa jauh lebih ringkas daripada merekam seluruh halaman (ukuran halaman khas adalah 8 KiB, informasi yang ditulis ke log sering 0,5-1 KiB).
• Alih-alih menulis tentang apakah transaksi dicatat atau tidak langsung ke halaman, ada cukup label tentang awal dan perbaikan transaksi dalam log.
• Halaman tidak dapat ditulis setelah setiap transaksi - beberapa kali lebih sedikit. Proses membaca / menulis data sepenuhnya "tidak terikat" dari log.
• Hal utama. Jika kita meletakkan jurnal kita pada disk terpisah dan menulis catatan secara berurutan, maka karena fakta bahwa Anda tidak perlu terus-menerus memposisikan ulang kepala disk, bahkan HDD rumah tangga dalam mode ini meremas hingga 1000 IOPS, mengingat bahwa transaksi kecil “biaya” 2-4 entri jurnal, maka Anda dapat memeras 200-400 TPS
• Dalam hal terjadi kegagalan, keadaan file data dapat dipulihkan dengan menggunakan log seperti itu, dan jika transaksi dibatalkan, perubahan dapat dibatalkan.

Log semacam itu disebut log write-ahead / log transaksi / REDO log.

Hore! Hebat! Ada 2 transaksi per detik, menjadi 300 - meningkat 150 kali. Dan berapa biayanya? Ternyata, harganya signifikan:

• Dalam semua DBMS umum, logging sangat konsisten. Satu utas bertanggung jawab untuk menulis ke log. Apakah Anda memiliki 100 prosesor? Keren Dan log masih akan menulis satu utas. Kedalaman antrian tepat satu.
• Tetap - tidak ada cache OS, tidak ada permutasi operasi. Persyaratan daya tahan tetap ada. Operasi Write-through: sampai disk menjawab "Saya menulis, saya menulisnya langsung ke permukaan, bukan ke cache, pasti" DBMS tidak terus bekerja.
• Jika Anda meletakkan file log pada disk data, maka hampir semua manfaat perekaman berurutan akan hilang. Selain itu - untuk selamanya, jika ada beberapa database di server, maka beberapa disk untuk majalah.
• Rollback transaksi (setidaknya dalam MS SQL Server) - baca log dan kembalikan status darinya. Ini adalah sebanyak atau bahkan lebih operasi tulis karena ada operasi tulis dalam transaksi. Kembalikan mahal!

Penjelasan ini sangat disederhanakan, "di jari." Ini cukup untuk topik kita. WAL adalah kunci, mekanisme fundamental untuk memastikan transaksionalitas, itu harus ditulisi, akses hanya berulir tunggal untuk rekaman berurutan, dari sudut pandang penyimpanan, kedalaman antrian adalah 1.

Topik log-forward logging dalam database harus minimal diketahui siapa pun yang entah bagaimana mengelola DBMS, atau infrastruktur DBMS, atau mengembangkan database.

WAL dan SHD

"Dari lahir" produsen penyimpanan dihadapkan dengan DBMS. Untuk basis data bisnis membeli kompleks yang sangat mahal ini: dari penyimpanan harga jalan Dell-EMC, HP, Hitachi, NetApp, ketika memaksakan anggaran, mata dipenuhi dengan air mata bagi sebagian besar manajer puncak, kecuali, tentu saja, mereka mendapatkan persentase dari harga ini. Tetapi ada konflik teknik dan pemasaran. Saya akan menjelaskannya menggunakan Dell-EMC sebagai contoh, tetapi hanya karena saya ingat di mana mereka memiliki dokumentasi.

Jadi:

1. Jurnal berulir tunggal
2. Log write-through, yaitu latensi, "abadi" dibandingkan dengan kinerja CPU
3. Beban OLTP adalah banyak transaksi yang relatif kecil,
4. Sebagian besar beban DBMS lainnya paralel dengan satu atau lain cara.

Hukum Amdahl tanpa ampun memberi tahu kita bahwa beban kinerja tunggal berulir tunggal akan membuat prosesor tambahan tidak berguna, dan kinerja akan ditentukan oleh log. Selain itu, saat ini kami tidak akan peduli tentang kinerja penyimpanan di IOPS, dan hanya latensi yang akan menjadi penting.
Tetapi jangan mengabaikan operasi disk lain - membaca dan menulis ke file data dan tempdb . Membaca juga merupakan operasi "menunggu". Hingga halaman data dibaca dari disk ke memori, prosesor tidak dapat memprosesnya. Tetapi untuk operasi ini, antrian besar dan permutasi operasi dalam antrian ini dimungkinkan: DBMS sering tahu halaman mana yang akan dimuat ke dalam memori, halaman mana yang akan dibuang dan menempatkan banyak antrian untuk membaca sekaligus. Karena dalam skenario ini, penting ketika operasi terakhir dari bundel berakhir, dalam beban ini, sebaliknya, IOPS lebih penting bagi kami daripada latensi operasi tunggal. Untuk memahami ruang lingkup: operasi baca dalam sistem OLTP khas adalah 85% -95%. Ya, ya, ya, operasi tulis adalah urutan besarnya kurang.

Insinyur penyimpanan vendor bekerja erat dengan vendor DBMS, dan sangat menyadari semua nuansa teknis tentang bagaimana DBMS bekerja dengan subsistem disk. Perencanaan, partisi, dan alokasi sumber daya disk yang tepat untuk DBMS adalah kompetensi yang kompleks dan penting dari administrator sistem penyimpanan . Dell-EMC yang sama bahkan memiliki H14621 white-paper dasar dan H12341 untuk rekomendasi pemartisian untuk SQL Server - lebih dari seratus halaman. Hai! Ini bukan dermaga terperinci, ini adalah kertas putih paling umum! Masih ada banyak yang spesifik ( h15142 , h16389 ... ada kegelapan di sana). "Adjacents" dari VMware - Merancang Microsoft SQL Server di VMware vSphere tidak jauh di belakang. Harap dicatat bahwa dokumen-dokumen ini tidak hanya dan tidak begitu banyak untuk DBA maupun untuk administrator infrastruktur dan penyimpanan.
Saya juga mencatat bahwa dalam semua dokumen ini LUN terpisah untuk data, untuk log, dan untuk tempdb . Ya, di suatu tempat di dokumen terbaru mereka dengan rapi mengatakan bahwa untuk solusi All-Flash tidak masuk akal untuk memisahkan log menjadi media yang terpisah secara fisik, tetapi LUN masih menawarkan untuk memotongnya secara terpisah. Jika Anda membuang data dan log ke dalam satu LUN, maka dari sudut pandang OS itu akan menjadi satu antrian IO. Dan akan ada masalah. Operasi latensi akan segera memiliki urutan yang lebih besar. Dan karena fakta bahwa operasi log yang tidak dapat dipindahkan akan muncul dalam antrian, IOPS akan tergelincir pada file data dan tempdb . Ini bukan "penemuan abad ini", ini adalah kebenaran dasar bekerja dengan database. Itu tidak ketinggalan jaman atau dibatalkan dengan munculnya All-Flash. Ya, keterlambatan operasi dengan SSD lebih cepat dengan urutan besarnya daripada dalam operasi dengan HDD, tetapi masih ada beberapa urutan besarnya lebih lambat daripada operasi dengan memori. IO masih menjadi hambatan bagi DBMS.
Dan dokumen teknis dengan benar menekankan bahwa dalam log transaksi jumlah IOPS tidak penting, tetapi penting bahwa latensi minimal (di zaman modern ini ditulis kurang dari 1 ms).

Tetapi pemasar perlu menjual. Hyperconvergence! Virtualisasi! Fleksibilitas Penempatan! Deduplikasi! Pengaturan mudah! Banyak, banyak IOPS! Presentasi yang indah, suara percaya diri, kostum formal. Tapi bagaimana lagi menjual solusi dengan label harga 6-7 digit dalam dolar? Untuk ini, entah bagaimana dilupakan bahwa baik latensi atau throughput dapat diperoleh dari sistem penyimpanan, tetapi tidak keduanya sekaligus, bahwa beberapa jenis lisensi untuk penyeimbang beban seperti rak lain, bahwa jika rekaman intensif berlangsung lebih dari satu jam, maka RAM dari pengontrol itu tidak cukup dan produktivitas akan turun ke "seolah-olah tidak ada cache", bahwa pelatihan karyawan pelanggan biaya 100.000 rubel lain untuk tahun pertama, well, trik seperti ...

5 ms

Entah telah mendengar banyak dari membaca marketer, atau dari kemalasan, atau karena beberapa jenis kecoak, tetapi untuk beberapa alasan sering administrator penyimpanan melakukan sesuatu seperti ini. Kami mengambil rak besar, menggabungkan semuanya menjadi sesuatu yang rata, memotongnya menjadi LUN yang tipis dan mendistribusikannya dengan LUN ke server. Atau dua, karena "partisi sistem terduplikasi dengan baik." Dan ketika, saya melihat bahwa dengan subsistem disk dari sisi SQL hell-hell-hell, maka lagu dimulai bahwa "5 ms adalah indikator yang sangat baik", "100000 IOPS", "Beban penyimpanan Anda kurang dari 5%"

TIDAK .

• Untuk sistem OLTP pada partisi dengan log WAL / transaksi 5 ms, ini adalah indikator yang tidak valid. Pada potongan "hampir-komoditas" besi dengan harga 1000 (dalam kata: seribu) kali lebih murah, indikator normal sekarang adalah 0,1-0,3 ms. Dan besok - 0,01 ms. Kecepatan, seperti pada HDD 2008, dengan harga seluruh pintu masuk apartemen di Moskow, tidak diperlukan. Tidak ada “kemudahan servis” yang sepadan.
• Apakah vendor menulis bahwa log transaksi tidak menuntut IOPS dan bisakah mereka dimasukkan ke dalam HDD? Ya itu. Tetapi untuk ini perlu bahwa tidak ada disk ini penularan Selain menulis log, DBMS tidak menyentuh tugas. Dan agar sistem penyimpanan merespons ke server bahwa data ditulis, segera setelah data masuk ke memori non-volatil (ini jauh lebih awal daripada yang akan ditulis)
• Disk tipis untuk database OLTP nyata adalah jahat.
• Untuk WAL, sama sekali tidak menarik berapa banyak IOPS dapat diperas di sana pada kedalaman antrian 10 atau 20. Tidak ada kedalaman di sana.
• Untuk WAL, itu sama sekali bukan indikator bahwa antrian IO di OS adalah "hanya sekitar 1". Dia tidak akan lagi.
• Tidak, pengembang DBA dan DB bukanlah "pelatuk engkol yang tidak dapat mengonfigurasi dengan benar untuk menulis ke paralel WAL" (pendapat nyata dari administrator)
• Logika penggemar untuk mempertimbangkan daur ulang "karena sistem Anda yang kami konfigurasikan secara bengkok dalam satu partisi tidak menghasilkan 10.000 IOPS, maka itu harus dipindahkan dari array kelas atas ke kelas menengah" - ini adalah logika yang salah.
• Jika server 40-core memiliki beban prosesor 2,5 persen, ini tidak berarti tidak ada hubungannya, tetapi, kemungkinan besar, berarti ada beberapa jenis tugas yang menghalangi semua orang.

Ketika beberapa pemuatan data pada laptop pengembang membutuhkan waktu 5 menit, dan pada server nuklir ke-40 dengan 1 TiB RAM dan penyimpanan selama setengah juta dolar, tugas yang sama dilakukan selama satu jam, bahkan pelanggan yang paling sabar pun akan memiliki pertanyaan tentang kelayakan biaya.

Apa yang harus dilakukan

Kiat Admin dan DBA

Untuk OLTP, berhentilah menghitung "daur ulang" dan IOPS. Secara terpisah, saya perhatikan - jangan melihat IOPS dengan kedalaman antrian yang besar sama sekali: bahkan pada partisi data, antrian besar biasanya memiliki ledakan pendek atau sesuatu yang tidak mempengaruhi kinerja aktual OLTP.

Berbagi ruang disk oleh LUN bukan keinginan DBA. Basis data memiliki beberapa profil beban subsistem disk yang berbeda. Minimal, berikut ini dapat dibedakan:

• Bekerja dengan file data. Biasanya ini membaca dan menulis dengan blok acak 8/64 KiB. Bacaan 80-95%. Antrian muncul: selama periode layanan, selama periode pemuatan massal, pada permintaan massal atau tidak efisien, dan selama pos pemeriksaan. Kinerja dipengaruhi oleh responsif terhadap membaca. Adalah penting bahwa penjajaran blok KiB 8/64 “through” melewati seluruh sistem penyimpanan.
• Bekerja dengan tempdb sama dengan bekerja dengan file data, tetapi pembacaan biasanya 40-75% dan responsif terhadap penulisan bisa menjadi penting. Dalam sistem MS SQL modern, basis data ini dapat dimuat beberapa kali lebih kuat daripada basis data. Dalam konfigurasi DBMS yang tidak berkerumun, bagian ini harus dikecualikan dari replikasi penyimpanan apa pun. Isinya setelah me-reboot layanan masih akan dihancurkan.
• Bekerja dengan data yang diarsipkan / DWH. Bacaan mendekati 100%. Ukuran satu blok bacaan biasanya 64 KiB. Permintaan banyak dibaca dan berturut-turut, sehingga antrean dapat melonjak hingga 1000 atau lebih.
• Bekerja dengan log transaksi. Membaca hanya untuk pemeliharaan (cadangan, replikasi, dll.), Kinerja aplikasi hanya dipengaruhi oleh penulisan. Merekam dalam blok 0,5-64 KiB. Tanpa antrian, dalam satu utas. Keterlambatan sangat penting untuk aplikasi.
• Cadangkan dan pulihkan. Dari sudut pandang database membaca dalam blok besar (sering 1 MiB). Penting bahwa beban ini dapat berada di atas saluran / bus (baik FC dan Ethernet) dan kinerja prosesor penyimpanan dalam beberapa kasus. Mencadangkan satu server dapat memengaruhi kinerja server lain dari SAN / SHD yang sama.
• Bekerja dengan file aplikasi: ini adalah log, jejak default, file biner, dll. Beban ini jarang signifikan dan hanya penting pada awal sistem.

Ada jenis beban lainnya, tetapi sedikit eksotis (misalnya, mungkin ada repositori file yang disimpan dalam database dalam bentuk direktori FileStream). Semua jenis beban ini memiliki persyaratan disk yang berbeda, seringkali saling bertentangan. Jika mereka semua ditumpuk di satu partisi, maka Anda tidak hanya menurunkan kinerja, tetapi sangat penting bahwa Anda kehilangan kemampuan untuk memahami mengapa sistem melambat, dan Anda juga kehilangan kesempatan untuk meningkatkan hanya bagian yang membutuhkan perbaikan tanpa peningkatan global / peningkatan penyimpanan. Oleh karena itu, rekomendasi utama:

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . Ini benar . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

Itu saja. . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .