Strategi untuk menangani DB SQL Server dengan terlalu banyak file (BLOB) di dalamnya?

11

Skenario:
Database SQL Server 2005 yang melayani aplikasi ASP.NET (pada server web terpisah).

Database:
DB memiliki sekitar 5GB data "normal" di dalamnya, dan sekitar 15GB "file" (misalnya: 200k PDF disimpan sebagai gambar (BLOB), semacam itu). Semakin banyak file yang diunggah oleh pengguna, dan secara cepat memakan lebih banyak ruang disk (DB dapat tumbuh hingga 50GB dalam beberapa bulan ke depan, sebagian besar file).

Kekhawatiran:
Menyimpan begitu banyak file dalam DB sudah menyebabkan masalah (misalnya: Ukuran total database yang besar membuat sesekali pencadangan dan penyebaran DB keseluruhan menjadi sulit.).

Dan kami khawatir akan ada lebih banyak masalah . (misalnya: masalah kinerja - mungkin disebabkan karena tidak dapat menyimpan seluruh DB dalam RAM, mungkin?)

Pertanyaan:
Apa solusi teknis yang akan Anda sarankan untuk masalah ini? Simpan file dalam sistem file? Membagi database menjadi dua dan memiliki yang lebih besar, lebih lambat untuk file?

Rincian Lebih Lanjut jika Dibutuhkan:
File-file ini tidak super penting, dan tidak perlu waktu akses yang sangat cepat - beberapa detik akan baik-baik saja, dan mungkin ada selusin paling banyak per jam, paling banyak saat ini. Data "normal" lainnya di DB termasuk info yang diperlukan berkali-kali per detik.

sql-server-2005  performance  disk-space 
— MGOwen
sumber
Apakah meningkatkan ke 2008+ kemungkinan sebagai bagian dari solusi?
— Jon Seigel
@ Jon Seigel Ya, opsi apa yang tersedia pada 2008 (atau bahkan 2012)?
— MGOwen

Jawaban:

6

Saya menjaga database yang sangat mirip, saat ini 3TB dan tumbuh 5GB per hari.

  • Filestream (2008+) tidak menyelesaikan tantangan backup / restore.
  • Filestream memiliki kinerja yang lebih baik daripada penyimpanan LOB untuk file> 1MB, demikian kata pengujian Paul Randal . Tergantung pada beban kerja 256KB-1MB dan umumnya lebih buruk pada <256KB.
  • Nilai tambah yang besar untuk Filestream di beberapa lingkungan adalah ia melewati kumpulan buffer dan menggunakan cache sistem Windows sebagai gantinya.
  • Jika Anda meletakkan file pada sistem file, Anda kehilangan konsistensi transaksional dengan catatan database. Anda juga menambahkan overhead untuk mencadangkan jutaan file individual, yang bisa menyusahkan.

Timbang pro dan kontra untuk Filestream dan lihat apakah cocok dengan kasus Anda. Dalam kasus kami, kami telah mengambil rute yang berbeda dan memilih untuk mempartisi basis data sehingga kami dapat menggunakan ketersediaan sebagian / pengembalian sedikit demi sedikit .

Salah satu opsi yang tidak tersedia bagi kami, yang mungkin Anda miliki, adalah untuk menandai filegroup yang lebih lama / arsip sebagai hanya-baca. Filegroup read-only kemudian dapat dicadangkan dengan jarang.

Jika macet pada Standar 2005 (mempartisi adalah fitur edisi Perusahaan) dan Anda memiliki opsi hanya-baca untuk riwayat, Anda bisa mengatasi ini dengan cara lama.

  • Pisahkan meja Anda. Anda dapat mempertimbangkan rute aktif / riwayat atau berdasarkan tanggal misalnya tabel per bulan.
  • Letakkan data historis di filegroup read-only dan cadangkan hanya ketika Anda mengarsipkan data lebih lanjut. Pastikan pengguna Anda memahami bahwa ini hanya memotong waktu cadangan. Pemulihan mungkin memakan waktu cukup lama ketika Anda belum mendapatkan fitur ketersediaan parsial.
  • Buat tampilan yang dipartisi di atas tabel.

Satu opsi terakhir (yang kami pertimbangkan untuk blobber 3TB kami) adalah memindahkan data file ke database dokumen atau penyimpanan cloud (mis. AmazonS3 , Azure BLOB Storage ). Ini tidak memperkenalkan masalah konsistensi transaksional yang saya sebutkan sebelumnya tetapi mengambil beban dari Server SQL yang sangat mahal.

— Mark Storey-Smith
sumber
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.