it-swarm-id.com

Melayani Gambar dari SQL server vs. Sistem file vs. S3 dll

Aplikasi saya (asp klasik yay!) Memiliki sekitar 2,1 juta gambar @ 25GB dan itu hanya mewakili 90 hari data dan saya ingin minimal 365. Saya perlu mengendalikan ini dan mempertimbangkan semua opsi. Apa pendapat Anda tentang pro dan kontra dari praktik-praktik berikut:

  • SQL Server Pro: Mudah untuk membuat cadangan Kontra: Kinerja?
  • Pro Sistem File: Kecepatan Kontra: Redundansi, Pencadangan lambat (saat ini sedang meneliti melakukan pencadangan penuh Sintetis yang mungkin membuat itu lebih baik)
  • S3 dan sejenisnya Pro: Bandwidth dipindahkan dari pusat data saya ke Amazon, penyimpanan hampir tak terbatas. Cons: Biaya, Analisis Biaya rumit (memperkirakan 80% dari bandwidth saya adalah gambar untuk keperluan ROI), Sulit/Mahal untuk swtich penyedia layanan harus yang menjadi perlu

Apakah ada orang lain yang menghadapi tantangan gambar multi-juta dan bagaimana Anda mengatasinya?

12
Webjedi

Kami tidak memiliki jutaan gambar, tetapi memiliki ratusan ribu gambar, dan kami menggunakan pendekatan hybrid - mysql untuk metadata, gambar yang disimpan pada disk lokal untuk cadangan, dan didorong ke Amazon s3 di mana mereka disajikan kepada pengguna. Kami tidak mengalami masalah dengan Amazon dan ketersediaan. Pindah ke cloudfront ada dalam rencana kami, hanya perlu mencari waktu.

Diskusi ini mungkin bermanfaat bagi Anda dalam keputusan Anda:
http://ask.metafilter.com/59635/Millions-of-images

Saya akan pergi dengan metadata di SQL server dan file di sistem file (atau s3 atau cloudfront). Tetapi jawaban terbaik tergantung pada beberapa pola penggunaan lain:

  • jangan mengubah gambar sering
  • dapatkah Anda menyajikan gambar langsung dari sistem file (yaitu, img src="...") atau apakah Anda memerlukannya untuk dikendalikan akses. Jika yang terakhir, maka solusi database yang terbaik
  • apakah Anda melayani sejumlah kecil gambar sebagian besar waktu (10% terbaru) atau distribusi relatif luas.

Pencadangan untuk jutaan gambar akan menjadi rumit tidak peduli bagaimana Anda mengaturnya - itu hanya banyak data. Saya ingin mencari studi kasus yang baik tentang cadangan gumpalan di SQL server sebelum saya berkomitmen untuk solusi itu. (Inilah artikel yang mungkin berguna: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part -4.htm )

6
mooreds

Abaikan orang yang mengatakan, " Jangan menyimpan gambar/data biner dalam database " karena mereka mendasarkan jawaban mereka pada informasi lama (dengan asumsi Anda akan menjadi menyimpan data dalam kolom tipe VarBinary). Masalah kinerja menggunakan SQL Server untuk menyimpan gambar sekarang dapat dikurangi dengan menggunakan FILESTREAM tipe data dalam SQL Server 2008. Pada dasarnya, tipe data FILESTREAM memungkinkan Anda untuk menggabungkan kemudahan menyimpan data dalam database dengan kinerja yang Anda dapatkan dari melayani file dari penyimpanan file NTFS.

Mengutip SQL Mag :

"Dukungan FILESTREAM SQL Server 2008 menggabungkan manfaat mengakses LOB langsung dari sistem file NTFS dengan integritas referensial dan kemudahan akses yang ditawarkan oleh mesin database relasional SQL Server."

Untuk info lebih lanjut baca blog ini oleh Ravi S.Maniam di MSDN .

3
Dan Diplo

Jika Anda memutuskan untuk menyimpannya di sistem file, Anda mungkin ingin membaca pertanyaan tentang ServerFault ini untuk beberapa hal yang harus dan tidak boleh dilakukan: Menyimpan satu juta gambar di sistem file .

3
Mark Henderson

Meskipun saya tidak berurusan dengan tantangan multi-juta gambar, saya akan menggunakan Amazon CloudFront. Itu semua file disimpan dalam ember S3 tetapi server melalui sistem pengiriman konten Amazon. Saya tidak akan menggunakan S3 saja.

Pilihan kedua saya adalah sistem file. Sederhana dan mudah, satu-satunya masalah adalah jika semua file ini berakhir dalam satu direktori semuanya akan rusak, sulit.

SQL bagi saya tidak akan menjadi opsi untuk sistem seperti ini. Anda tidak hanya akan dikenakan biaya untuk transfer bandwidth Anda juga akan dikenakan biaya untuk pemrosesan permintaan - ini akan sangat tergantung pada hosting, tetapi saya berasumsi bahwa Anda menggunakan server khusus atau setidaknya vps di mana Anda akan dikenakan biaya untuk siklus. Maka itu akan memperlambat seluruh situs Anda jika menggunakan database yang sama dengan server gambar. Jika tidak maka Anda menambahkan semua kerumitan ini karena harus mengelola dua koneksi basis data.

2

Database dirancang untuk data/konsistensi dan keamanan transaksional.

File media (gambar, audio, video) cenderung dibuat dan mungkin dihapus, tetapi sangat jarang diperbarui. Jadi secara umum tidak perlu untuk membuat mereka konsisten secara transaksi dengan data lain dan database tidak akan memberi Anda manfaat nyata di sana. Konten teks mungkin masalah yang berbeda.

Selama Anda tidak memiliki masalah dengan konsep seseorang menarik file Anda secara langsung jika mereka memiliki URL file, maka sistem file baik-baik saja. Jika Anda menjalankan sesuatu seperti perpustakaan foto, di mana Anda mengharapkan untuk menagih sebelum orang mengunduh file, maka itu mungkin masalah yang berbeda. Yaitu, setelah pengguna membayar, mereka mungkin mendapatkan URL khusus untuk pengguna itu atau hanya berlaku untuk waktu yang singkat, dan aplikasi menangani beberapa atau sementara URL yang menunjuk ke gambar yang sama. Itu masih bisa ditangani oleh aplikasi dan sistem file, tetapi Anda akhirnya melayani media melalui aplikasi daripada sebagai download file langsung (yang sebagian besar akan mengesampingkan manfaat S3) dan ada sedikit perbedaan antara DB dan sistem file .

1
Gary