Desain tabel besar SQL

Saya punya pertanyaan umum tentang desain SQL Server 2008. Saat ini kami memiliki meja yang lebih dari 600GB dan tumbuh sekitar 3GB sehari. Tabel ini memiliki indecies yang sesuai tetapi menjadi hangup utama ketika menjalankan kueri dan hanya karena ukurannya. Pertanyaannya adalah apakah saya harus membagi tabel menjadi beberapa tabel berdasarkan tahun dan bulan (ini akan cocok dengan cara departemen lain membagi set data besar mereka) atau haruskah kita memanfaatkan partisi yang dibangun ke dalam SQL Server. Tampaknya menggunakan partisi akan membutuhkan lebih sedikit perubahan kode. Dari apa yang saya baca ketika mempartisi Anda masih hanya query satu tabel dan server menangani cara mendapatkan data. Jika kami memilih rute beberapa tabel, kami harus menangani penarikan data dari banyak tabel.

"Tabel ini memiliki indecies yang sesuai tetapi menjadi hangup utama ketika menjalankan kueri"

Mempartisi sendiri tidak membantu kinerja kueri kecuali SQL Server mampu menghilangkan partisi saat menjalankan kueri. Klausa WHERE Anda harus sejajar dengan cara Anda mempartisi. Kami hanya mendapatkan satu bidang untuk digunakan sebagai bidang pemartisian, jadi jika bidang itu tidak termasuk dalam klausa WHERE Anda, Anda masih akan memindai seluruh tabel meskipun memiliki partisi.

"Dan hanya karena ukurannya."

Pemartisian dapat membuat operasi pemeliharaan tertentu lebih mudah, tetapi masih ada hal-hal yang tidak dapat kita lakukan berdasarkan partisi-demi-partisi. Jika pemeliharaan indeks dan pembaruan statistik menyebabkan masalah bagi Anda, lebih baik Anda membagi desain menjadi tabel arsip dan tabel yang diperbarui secara langsung. Ketika Anda perlu secara berkala memindahkan data dari tabel langsung ke tabel arsip, Anda melakukannya, membangun kembali indeks dengan faktor isian 100%, memperbarui statistik dengan pemindaian penuh, dan kemudian mengatur filegroup menjadi read-only. Partisi dapat membantu dengan memuat tabel arsip - tetapi mempartisi tabel langsung mungkin tidak. (Saya mengeluarkan beberapa konsep canggih di sini seolah-olah itu cepat dan sederhana, tapi saya hanya membuat sketsa latar belakang di sini.)

"Tampaknya menggunakan partisi akan membutuhkan lebih sedikit perubahan kode."

Agak agak - terlihat seperti itu pada pandangan pertama, tetapi semakin Anda masuk ke dalamnya, Anda memiliki opsi seperti tampilan yang dipartisi. Anda dapat mengganti nama tabel yang ada, menampilkannya, dan kemudian Anda dapat membuat perubahan sendiri ke tabel yang mendasarinya (dan menambahkan beberapa tabel) tanpa mengubah aplikasi Anda.

Saya telah menulis lebih banyak tentang perangkap partisi di sini:

http://www.brentozar.com/archive/2008/06/sql-server-partitioning-not-the-answer-to-everything/

Partisi dalam isolasi mungkin cukup tetapi Anda mungkin mendapatkan hasil yang lebih baik dengan menggabungkan dengan tampilan yang dipartisi dan beberapa tabel. Ini sangat tergantung pada pola permintaan dan pertumbuhan.

Batasan saat ini dengan partisi adalah bahwa statistik kolom hanya dipertahankan pada tabel, bukan pada tingkat partisi. Jika Anda memiliki pola kueri yang akan mendapat manfaat dari statistik yang lebih akurat, menggabungkan tabel partisi dengan tampilan yang dipartisi dapat menghasilkan manfaat kinerja yang signifikan.

Di mana sifat data Anda bervariasi dari bulan ke bulan, tahun ke tahun, tampilan yang dipartisi juga dapat membantu. Bayangkan seorang pengecer yang terus-menerus mengubah lini produknya, sehingga ada sedikit konsistensi dalam Product.ProductId rentang penggunaan dari tahun ke tahun. Dengan satu tabel pesanan / rincian pesanan dan oleh karena itu satu histogram statistik, statistik akan menawarkan sedikit untuk optimizer kueri. Tabel per tahun (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011) dipartisi berdasarkan bulan dan dikombinasikan dengan tampilan yang dipartisi (Order, OrderLine) akan memberikan statistik yang lebih rinci dan berpotensi bermanfaat bagi pengoptimal.

Anda dapat memperkenalkan tabel partisi dengan sedikit usaha, jadi mulailah dari sana, ukur dampaknya, dan kemudian evaluasi apakah tampilan yang dipartisi akan sebanding dengan upaya tambahan.

Kimberly Tripp telah menerbitkan banyak panduan dan buku putih tentang partisi yang umumnya dianggap wajib dibaca tentang topik tersebut. Kendra Little juga memiliki beberapa bahan yang bagus dan daftar referensi yang berguna dari artikel lain

Kinerja biasanya merupakan alasan nomor 1 mengapa orang ingin mempartisi. Secara pribadi, saya melihat perbaikan dalam waktu pemulihan menjadi manfaat yang sama atau lebih besar dengan VLDB. Luangkan waktu untuk memahami ketersediaan parsial dan pengembalian sedikit demi sedikit sebelum Anda mulai karena dapat memengaruhi pendekatan yang Anda ambil.

Jika Anda memiliki proses pengiriman cadangan yang tidak ideal tetapi tidak biasa di seluruh jaringan, Anda mungkin mencari waktu pemulihan 3 jam untuk 600GB Anda saat ini. Dalam setahun ketika Anda melanggar 1.5TB, Anda punya masalah.

Seperti yang Anda katakan, Anda memiliki dua opsi di sini:

1. Gunakan beberapa tabel
2. Gunakan Partisi

Dengan 1, Anda dapat membuat VIEW yang menyatukan semua tabel itu bersama-sama, dan cukup perbarui untuk menyertakan tabel yang baru dibuat. Saya menganggap ini benar-benar menjadi cara untuk meniru partisi. Pro dari metode ini termasuk tidak memerlukan SQL Server Edisi Perusahaan.

Dengan 2, Anda dapat menyelaraskan indeks Anda ke partisi Anda, dan menyelaraskan partisi Anda ke penyimpanan yang berbeda. Setelah Anda mengatur fungsi partisi dan skema partisi, ini dilakukan untuk Anda ketika Anda membagi atau menggabungkan partisi. Pro dari metode ini termasuk tidak diharuskan untuk memindahkan catatan secara manual ke tabel baru. Karena fungsi partisi dan skema partisi menangani ini untuk Anda. Selanjutnya, seperti yang Anda katakan, ada sedikit atau tidak ada perubahan kode yang diperlukan untuk mengakses data.

Jika Anda memiliki Edisi Enterprise, saya pasti akan memberikan tampilan partisi. Meskipun betapa rumit tampilannya, itu sebenarnya tidak terlalu buruk. Jika tidak, partisi bahkan bukan pilihan untuk Anda.

Membuat Tabel Partisi

Memodifikasi Tabel Partisi

Merancang Partisi untuk Mengelola Subhimpunan Data

Semoga ini membantu,

Mat

Dari pertanyaan Anda, Anda tampaknya menyimpan data historis (log) dan keterbatasan Anda tampaknya berasal dari kecepatan kueri, bukan masalah ruang penyimpanan. Bagi saya partisi tidak akan membantu.

Ketika Anda mengatakan Anda memiliki indeks yang tepat, apakah itu memasukkan indeks pada bidang tanggal? Saya mendapat hasil yang baik menggunakan indeks pada trunc (timestamp, hari) dengan Postgres. Anda kemudian harus memastikan bahwa semua pertanyaan dipilih pada hari sebelum manipulasi lainnya. Hati-hati, cap waktu dengan bidang zona waktu tidak dapat diindeks (karena "bergerak" tergantung pada zona waktu) sehingga Anda memerlukan cap waktu "tetap" untuk diindeks.