Server data warehouse. Bagaimana Anda menghitung spesifikasi RAM / CPU?

Saya mencoba menulis spesifikasi untuk server data warehouse untuk upgrade data warehouse yang direncanakan.

Saat kami menjalankan server virtual pada host VMWare, kami memiliki kemampuan untuk menambah atau menghapus sumber yang diperlukan. Di masa lalu kami telah menambahkan RAM dan CPU secara bertahap sesuai kebutuhan. Karena tuntutan kami meningkat, kami telah melobi untuk sumber daya yang lebih banyak. (terutama disk & RAM).

Kami meminta lebih banyak. Mereka memberi kita sesedikit mungkin.

Namun baru-baru ini setiap kali kita berbicara tentang sumber daya kita sekarang dikritik karena tidak menentukan mesin tepat di tempat pertama, dan saya sekarang diberitahu bahwa host dev sudah di-maks, tidak ada lagi RAM yang tersedia.

Kami adalah organisasi kecil Pemerintah Daerah dengan ~ 50 pengguna reguler dari DW. Dalam penggunaan sehari-hari normal itu berjalan dengan baik. Kami mendapatkan kinerja permintaan mdx yang baik, dan laporan serta dasbor kami cepat. Pengguna senang.

Namun proses ETL kami berjalan sepanjang malam, dan kami mulai melihat bukti tekanan memori saat memproses data secara bersamaan. Tadi malam SSIS gagal dengan peringatan tentang "kehabisan memori kesalahan".

DW server kami yang ada adalah Win 2008 R2 dengan 4 CPU dan 16Gb RAM yang menjalankan SQL 2012 Std. Saya memiliki memori server maks yang disetel ke 12GB, meninggalkan 4GB untuk OS dan layanan, dll. DW kami saat ini memiliki 3 datamarts / OLAP cubes, dan kami sedang mengembangkan 2 lagi.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Server baru kami direncanakan menjadi Win 2012 yang menjalankan SQL 2016 Enterprise. Ini akan menjalankan SQL, SSIS, SSR & SSAS. Penyimpanan bukan masalah, tapi saya tidak yakin tentang RAM & CPU.

Menurut Panduan Referensi Gudang Data Jalur Cepat untuk SQL Server 2012 , minimum yang harus saya miliki adalah 128Gb untuk mesin 2 soket ... yang tampaknya agak berlebihan. The Hardware dan Software Persyaratan untuk Instalasi SQL Server 2016 merekomendasikan minimal 4Gb RAM untuk SQL 2016. Itu ini cukup perbedaan!

Jadi .. Apa titik awal yang baik? 32Gb? 64Gb? Bagaimana saya membenarkan posisi awal saya (spek) untuk TI?

Apakah ada panduan bagus tentang cara menghitung sumber daya server?

Apakah ada aturan praktis yang baik?

Apa bahan / metrik utama untuk ukuran RAM dalam konteks DW?

• Volume data?
• Jumlah kubus?
• Waktu yang diperlukan untuk melakukan ETL atau memproses kubus?
• Beban pemrosesan puncak semalaman atau kinerja seperti yang dilihat oleh pengguna akhir di siang hari?

Pertanyaan yang bagus, dan saya melakukan sesi tentang hal ini di TechEd beberapa tahun yang lalu yang disebut Membangun SQL Server Tercepat:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

Di dalamnya, saya menjelaskan bahwa untuk gudang data, Anda memerlukan penyimpanan yang dapat menyediakan data dengan cukup cepat untuk dikonsumsi oleh SQL Server. Microsoft membuat serangkaian kertas putih yang hebat yang disebut Arsitektur Referensi Gudang Data Jalur Cepat yang masuk ke detail perangkat keras, tetapi ide dasarnya adalah penyimpanan Anda harus dapat memberikan kinerja pembacaan sekuensial 200-300MB / detik, per inti CPU, di untuk membuat CPU sibuk.

Semakin banyak data yang dapat Anda cache di memori, semakin lambat penyimpanan yang bisa Anda lakukan. Tetapi Anda memiliki lebih sedikit memori daripada yang dibutuhkan untuk men-cache tabel fakta yang Anda hadapi, sehingga kecepatan penyimpanan menjadi sangat penting.

Inilah langkah selanjutnya:

• Tonton video itu
• Uji penyimpanan Anda dengan CrystalDiskMark ( Begini caranya )
• Dengan 4 core, Anda ingin sekurangnya 800 MB / detik dari throughput baca sekuensial
• Jika Anda tidak memilikinya, pertimbangkan untuk menambahkan memori hingga rasa sakitnya hilang (dan menyimpan seluruh basis data dalam RAM tidak terpikirkan)

Katakanlah Anda memiliki database 200GB yang sedang Anda hadapi, dan Anda tidak bisa mendapatkan throughput penyimpanan yang cukup untuk membuat core Anda sibuk. Tidak terpikirkan untuk membutuhkan tidak hanya 200GB RAM, tetapi bahkan lebih - karena bagaimanapun, SSIS dan SSAS benar-benar ingin melakukan pekerjaan mereka dalam memori, jadi Anda harus memiliki data mesin tersedia, ditambah ruang kerja untuk SSIS dan SSAS.

Ini juga mengapa orang mencoba memisahkan SSIS dan SSAS ke VM yang berbeda - mereka semua membutuhkan memori secara bersamaan.

The Fast Track Data Warehouse Referensi Panduan untuk SQL Server 2012 sebenarnya sedikit out-of-date terutama jika Anda pindah ke SQL Server 2016 (benar-benar? Panggil aku), bukan hanya dalam hal waktu, tetapi juga fitur.

Di SQL Server 2012, versi di mana jalur cepat didasarkan, Anda hanya bisa memiliki indeks kolomstore yang tidak berkerumun. Ini adalah struktur yang terpisah dari tabel utama sehingga menimbulkan penyimpanan tambahan dan memproses overhead karena meskipun salinan data terkompresi.

Dari SQL Server 2014 dan seterusnya, Anda dapat memiliki indeks toko kolom berkerumun. Ini menawarkan kompresi besar-besaran dan potensi peningkatan kinerja untuk kueri agregat / ringkasan. Mereka benar-benar sesuai untuk tabel fakta, sehingga tabel fakta 32GB Anda bisa lebih mirip ~ 8-12GB. YMMV. Itu mengubah sedikit lanskap bukan? Melihat meja Anda (dan jempol di udara) Anda mungkin bisa lolos dengan 32GB tapi saya akan menembak untuk 64GB (tidak seperti Anda meminta 1TB) dan meninggalkan ruang untuk layanan dan pertumbuhan lainnya, pembenaran karena ini memungkinkan Anda memegang meja terbesar Anda dalam memori, memberikan ruang untuk pertumbuhan dan ruang untuk layanan lainnya. Anda tidak perlu memberi tahu mereka tentang kompresi. Satu hal yang harus Anda ingat dengan ukuran adalah, Anda tidak hanya menentukan ukuran untuk data Anda sekarang, tetapi bagaimana nantinya, katakan setahun dari sekarang. Namun perhatikan juga, kinerja untuk pencarian titik bisa sangat menghebohkan, tetapi saat Anda pindah ke SQL Server 2016 Anda dapat menambahkan indeks tambahan atau Anda selalu dapat mempertimbangkan Indeks Kolom untuk Analisis Operasional Real-Time meskipun Anda akan membutuhkan lebih banyak memori untuk itu :)

Ngomong-ngomong, Anda menggunakan CTP, saat ini di CTP3.3 memiliki sebagian besar fitur yang mungkin ingin Anda gunakan tersedia, jadi Anda mengatakan Anda tidak memiliki sumber daya untuk uji coba, tetapi Anda bisa mendapatkan uji coba Windows Azure , putar VM, buat beberapa sampel data, uji kompresi, kinerja fitur-fitur utama dan permintaan dll secara gratis. Atau jika Anda memiliki lisensi MSDN, ini sudah ada di dalamnya.

Singkatnya, ukuran untuk memungkinkan meja terbesar Anda berada di memori (ditambah barang-barang lainnya) atau membuat percobaan sederhana (gratis di cloud) untuk mendapatkan bukti keras yang Anda cari. Ingatlah untuk membatalkan alokasi VM Anda setelah selesai :)

Agaknya saat mengembangkan dan memelihara paket ETL pada mesin pengembangan lokal Anda kadang-kadang menggunakan data uji dengan skala yang sama atau lebih besar dari yang Anda harapkan dalam produksi, dan jika tidak maka mungkin Anda akan mempertimbangkan untuk melakukannya (data nyata yang dianonimkan atau data uji yang dihasilkan secara algoritmik, jika data asli Anda sensitif sama sekali).

Jika demikian, Anda dapat menjalankan proses di bawah berbagai kondisi memori dan memprofilkannya, untuk melihat titik di mana lebih banyak RAM berhenti membuat perbedaan besar - sama bermanfaatnya dengan aturan praktis dan tebakan yang mendidik. Tidak ada benchmarking dan profil yang dapat memberikan jawaban konkret yang jauh lebih konkret. dan sebagai bonus dapat menyoroti hambatan yang jelas yang mungkin mudah dioptimalkan. Tentu saja lingkungan pengembang / pengujian Anda mungkin tidak sama persis dengan produksi, jadi Anda mungkin perlu menggunakan pengalaman untuk menafsirkan bagaimana hasilnya dapat berubah.

Jika Anda menjalankan SSIS pada mesin yang sama dengan database maka Anda harus memastikan mesin contoh SQL Server diatur untuk tidak pernah mengklaim semua memori. Tidak hanya kelaparan memori dapat menyebabkan kesalahan OOM di SSIS, jauh sebelum itu dapat menyebabkan masalah kinerja yang signifikan karena gulungan buffer ke disk ketika itu bisa menyimpannya dalam RAM. Seberapa banyak Anda perlu memesan SSIS dan tugas-tugas lain akan sangat bervariasi tergantung pada proses Anda, jadi sekali lagi membuat profil adalah cara yang baik untuk mengukur ini. Sering disarankan agar Anda menjalankan SSIS pada mesin yang terpisah untuk membuatnya lebih mudah untuk dikelola, meskipun Anda mungkin memiliki masalah throughput jaringan dan lisensi untuk dipertimbangkan di sana.

Memperbarui

Jika, sesuai komentar Anda, tidak ada sumber daya yang tersedia untuk melakukan tolok ukur yang realistis untuk mengukur di mana kinerja turun (dan / atau kesalahan OOM dan masalah terkait mulai terjadi) jika terlalu sedikit RAM yang dialokasikan, hal-hal menjadi jauh lebih lamban. tanpa pengetahuan mendalam tentang proses gudang dan ETL. Aturan praktis untuk database gudang itu sendiri: Anda ingin RAM yang cukup untuk dapat menampung keseluruhan indeks yang paling umum digunakan, dan kemudian beberapa untuk memungkinkan data yang kurang umum digunakan dan lebih lagi untuk memungkinkan pertumbuhan yang diharapkan dalam waktu dekat. / masa depan menengah.

Menghitung ini bisa faf - sp_spaceUsed tidak akan memecah hal-hal berdasarkan indeks sehingga Anda harus melakukan query sys.allocation_units dan teman langsung. Ada beberapa contoh di luar sana untuk membantu Anda memulai, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 Saya terlihat seperti yang terbaik dari beberapa yang pertama yang berasal dari pencarian cepat.

Selain kebutuhan untuk menjalankan DB gudang itu sendiri, ingatlah untuk menambahkan persyaratan RAM untuk SSIS jika ingin dijalankan pada mesin yang sama dan pastikan SQL Server memiliki batasan RAM untuk memastikan bahwa memori ini benar-benar tersedia untuk SSIS.

Dari ukuran data keseluruhan, Anda mencantumkan usus saya menunjukkan bahwa 32Gb akan menjadi minimum absolut yang saya sarankan untuk hanya mesin database dan SSIS, pengaturan contoh SQL untuk digunakan paling banyak 26, dan karena Anda juga menjalankan SSRS dan layanan lain pada mesin yang sama minimum yang masuk akal dengan beberapa pemeriksaan di masa depan adalah 64Gb (dua pertiga dari data Anda saat ini harus sesuai dengan itu setelah layanan lain dan pemesanan terpotong). Jelas mengutip nyali saya tidak akan membuat Anda jauh dalam diskusi dengan orang-orang infrastruktur Anda ...