Penyesuaian Kinerja untuk Tabel Besar (SQL Server 2008 R2)


14

Latar belakang:
Saya memiliki tabel fakta di Fase UAT. Objektif untuk memuat 5 tahun data dalam Prod (ukuran yang diharapkan 400 juta catatan). Saat ini hanya memiliki 2 tahun data dalam Tes.

Fitur Meja:

  1. Jumlah Dimensi ~ 45
  2. Tindakan ~ 30
  3. Tindakan non-aditif dan kolom lainnya ~ 25
  4. Ukuran data saat ini ~ 200 Juta (2 tahun data)
  5. Tampilan Waktu: 3 tampilan Bulan yang berbeda: Fiskal / Kalender / Disesuaikan (yaitu baris yang sama dapat jatuh dalam bulan yang berbeda berdasarkan tampilan yang dicari orang)
  6. Hanya Satu tampilan yang diperlukan pada satu waktu oleh pengguna. (mis. hanya satu Bulan Kolom akan digunakan dalam kueri, itu menghentikan kami untuk melakukan partisi pada tampilan waktu)
  7. Indeks: 1 Indeks Clustered pada Natural Keys (8 kolom). Diciptakan 3 yang mencakup Indeks Non Clustered satu pada setiap kolom Bulan termasuk beberapa Dimensi SK (FK) dan semua tindakan).
  8. Indeks sangat besar (total 190 GB) karena ini.
  9. Ruang tidak kendala (dialokasikan 1 TB)
  10. 64 GB RAM tersedia di server.
  11. Kompresi tabel juga dilakukan.

Persyaratan:
Kueri pada tabel Fakta ini akan memberikan hasil dalam 30 detik (Kueri umum pilih jumlah (ukuran) bergabung dengan beberapa grup Dims dengan Nilai Dim). Laporan langsung dilakukan di atas tabel Fakta ini.

Masalah:
Permintaan apa pun yang menyertakan kolom yang tersedia di Indeks berfungsi dengan baik, tetapi jika kami menyertakan kolom lain yang tidak termasuk .. Ini menyebalkan. Dibutuhkan lebih dari 5-10 menit. Adakah yang bisa menyarankan beberapa solusi di mana ia berfungsi dengan baik untuk setiap dimensi / kolom yang kita pilih. Dapatkah Index melihat bantuan dalam situasi ini?

Jawaban:


6

Tingkatkan ke SQL Server 2012 dan gunakan toko kolom . Mereka berkembang dalam persyaratan ini. Serius, unduh edisi evaluasi dan cobalah. Jatuhkan semua indeks, jatuhkan indeks berkerumun, cukup tambahkan indeks toko kolom yang tidak berkerumun di semua kolom dan berikan pusaran. Saya telah melihat kasus-kasus seperti Anda yang mengurangi waktu eksekusi menjadi 2-3 detik, sebagian besar karena penghapusan segmen menendang. Beberapa tambahan berbunyi:


0

Akankah tampilan yang diindeks menyelesaikan masalah Anda? Seberapa up to date data yang dibutuhkan? Anda bisa membuat tampilan yang diindeks untuk beberapa permutasi. Tetapi dengan banyak dimensi dan ukuran Anda mungkin kehabisan ruang dengan cepat!

Bagaimana dengan menggunakan SSD?


Data akan diperbarui setiap bulan. Berapa lama waktu yang diperlukan untuk memperbarui Tampilan?

Jika permintaan Anda saat ini membutuhkan waktu 5-10 menit, maka tampilan yang diindeks akan memakan waktu 5-10 menit. Ketika selesai, ketika Anda menjalankan kueri yang sama itu akan kembali seolah-olah itu keluar dari tabel (yaitu segera). Tampilan yang diindeks pra-menjalankan sedikit SQL tertentu. Jika Anda mengirimkan SQL yang cocok, itu diambil dari tampilan yang diindeks, daripada menjalankannya lagi. Keuntungan utama dari tampilan yang diindeks adalah Anda tidak perlu mengubah kueri yang ada, mereka akan secara otomatis menggunakannya. Kerugiannya adalah Anda harus membuat satu untuk beberapa kombinasi yang berbeda.
Nick.McDermaid

Tapi saya tidak menyarankan Anda membuat banyak tampilan indeks untuk mempercepat - Anda akan kehabisan waktu dan ruang disk pada akhirnya. Mungkin hanya satu hal untuk dimasukkan ke dalam gudang senjata Anda.
Nick.McDermaid

dan tolong ... lihat ke toko kolom seperti yang disarankan!
Nick.McDermaid
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.