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

12

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 berikut:

SQL Server Pro: Mudah dicadangkan 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 berurusan dengan tantangan multi-juta gambar dan bagaimana Anda mengatasinya?

images

— Webjedi
sumber

4

Jangan bukan tidak bukan tidak tidak tidak menyimpan data gambar (gumpalan) dalam database. Kami membuat kesalahan ini bertahun-tahun yang lalu dan telah membayar untuk itu sejak itu. Database sangat bagus untuk metadata.

— Mark Henderson

Lihat posting saya tentang tipe data FILESTREAM - mungkin akan berubah pikiran.

— Dan Diplo

6

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 secara 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 menemukan 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 )

— ditambatkan
sumber

Pencadangan akan menjadi rumit, tetapi setidaknya dengan cadangan tingkat file Anda (umumnya) tidak harus mengembalikan seluruh cadangan hanya untuk mengembalikan satu catatan / gambar. IMO, sistem file secara default kecuali database memberi Anda sesuatu yang tidak dapat Anda lakukan sebaliknya. +1

— JasonBirch

Sistem file dirancang untuk menyimpan file - Anda dapat menemukan sistem file yang dirancang untuk menyimpan jutaan file secara efisien. Database dirancang untuk hal-hal seperti metadata Anda - permintaan dan hubungan. Kecuali jika Anda memiliki sangat sedikit gambar, ini mungkin cara terbaik (tidak termasuk solusi cloud).

— dmsnell

3

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

— Mark Henderson
sumber

3

Abaikan orang yang mengatakan, " Jangan menyimpan gambar / data biner dalam database " karena mereka mendasarkan jawaban mereka pada informasi lama (dengan asumsi Anda akan menyimpan data dalam kolom tipe VarBinary). Masalah kinerja menggunakan SQL Server untuk menyimpan gambar sekarang dapat dikurangi dengan menggunakan tipe data FILESTREAM di 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 .

— Dan Diplo
sumber

Apakah penyimpanan FILESTREAM mengubah kisah cadangan / pemulihan sama sekali? Itu hangup terbesar kami saat ini ... jika disimpan di VarBinary, itu akan menjadi cerita yang relatif lurus ke depan.

— Webjedi

Tidak, data FILESTREAM diperlakukan seperti yang lain, jadi didukung dengan database. Mengutip MSDN: "Anda dapat menggunakan semua model cadangan dan pemulihan dengan data FILESTREAM, dan data FILESTREAM dicadangkan dengan data terstruktur dalam database." - technet.microsoft.com/en-us/library/bb933993.aspx

— Dan Diplo

2

Meskipun saya tidak berurusan dengan tantangan gambar multi-juta, 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 di satu direktori semuanya akan rusak, sulit.

SQL bagi saya tidak akan menjadi opsi untuk sistem seperti ini. Anda tidak hanya 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.

— Frank Robert Anderson
sumber

Dalam skenario saya, saat ini semuanya ada di lokasi di server saya sendiri yang saya miliki. Jadi tidak ada biaya transaksi per se.

— Webjedi

1

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 lain.

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 .

— Gary
sumber