Jadi saya menggunakan aplikasi yang menyimpan banyak gambar dalam DB. Apa pandangan Anda tentang ini? Saya lebih dari tipe untuk menyimpan lokasi di sistem file, daripada menyimpannya langsung di DB.
Menurut Anda apa kelebihan / kekurangannya?
Jawaban:
Saya bertanggung jawab atas beberapa aplikasi yang mengelola banyak gambar TB. Kami telah menemukan bahwa menyimpan jalur file di database menjadi yang terbaik.
Ada beberapa masalah:
Seperti kebanyakan masalah, tidak sesederhana kedengarannya. Ada kasus di mana masuk akal untuk menyimpan gambar dalam database.
Di sisi lain ada masalah yang terkait
Penyimpanan file. Para insinyur Facebook berbicara banyak tentang hal itu. Satu mengambil adalah untuk mengetahui batas praktis file dalam direktori.
Ini mungkin sedikit sulit, tetapi jika Anda menggunakan (atau berencana menggunakan) SQL Server 2008 saya akan merekomendasikan melihat tipe data FileStream baru .
FileStream memecahkan sebagian besar masalah seputar menyimpan file dalam DB:
Namun SQL "Enkripsi Data Transparan" tidak mengenkripsi objek FileStream, jadi jika itu merupakan pertimbangan, Anda mungkin lebih baik menyimpannya sebagai varbinary.
Dari Artikel MSDN:
Pernyataan Transact-SQL dapat menyisipkan, memperbarui, meminta, mencari, dan mencadangkan data FILESTREAM. Antarmuka sistem file Win32 menyediakan akses streaming ke data.
FILESTREAM menggunakan cache sistem NT untuk menyalin data file. Ini membantu mengurangi efek yang mungkin dimiliki data FILESTREAM pada kinerja Mesin Basis Data. Kolam buffer SQL Server tidak digunakan; oleh karena itu, memori ini tersedia untuk pemrosesan permintaan.
Jalur file di DB jelas merupakan cara yang harus ditempuh - Saya telah mendengar kisah demi kisah dari pelanggan dengan TB gambar yang menjadi mimpi buruk ketika mencoba menyimpan jumlah gambar yang signifikan dalam DB - kinerja yang dicapai sendirian terlalu banyak.
Dalam pengalaman saya, kadang-kadang solusi paling sederhana adalah memberi nama gambar sesuai dengan kunci utama . Jadi mudah untuk menemukan gambar milik catatan tertentu, dan sebaliknya. Tetapi pada saat yang sama Anda tidak menyimpan apa pun tentang gambar di database.
Kuncinya di sini adalah untuk tidak menjadi fanatik.
Satu hal yang perlu diperhatikan di sini adalah bahwa tidak ada seorang pun di kamp sistem file pro telah mendaftarkan sistem file tertentu. Apakah ini berarti bahwa semuanya mulai dari FAT16 hingga ZFS dapat dengan mudah mengalahkan setiap basis data?
Tidak.
Yang benar adalah bahwa banyak database mengalahkan banyak sistem file, bahkan ketika kita hanya berbicara tentang kecepatan mentah.
Tindakan yang benar adalah membuat keputusan yang tepat untuk skenario Anda yang tepat, dan untuk melakukan itu, Anda akan memerlukan beberapa angka dan beberapa perkiraan kasus penggunaan.
Di tempat-tempat di mana Anda HARUS menjamin integritas referensial dan kepatuhan ACID, menyimpan gambar dalam database diperlukan.
Anda tidak dapat secara transaksional menjamin bahwa gambar dan meta-data tentang gambar yang disimpan dalam database merujuk ke file yang sama. Dengan kata lain, tidak mungkin untuk menjamin bahwa file pada sistem file hanya pernah diubah pada waktu yang sama dan dalam transaksi yang sama dengan metadata.
Seperti yang orang lain katakan, SQL 2008 hadir dengan tipe Filestream yang memungkinkan Anda untuk menyimpan nama file atau pengenal sebagai penunjuk dalam db dan secara otomatis menyimpan gambar pada sistem file Anda yang merupakan skenario hebat.
Jika Anda menggunakan database yang lebih lama, maka saya akan mengatakan bahwa jika Anda menyimpannya sebagai data gumpalan, maka Anda benar-benar tidak akan mendapatkan apa pun dari database dengan cara mencari fitur, jadi mungkin yang terbaik untuk menyimpan alamat pada sistem file, dan menyimpan gambar dengan cara itu.
Dengan begitu Anda juga menghemat ruang pada sistem file Anda, karena Anda hanya akan menghemat jumlah ruang yang tepat, atau bahkan ruang yang dipadatkan pada sistem file.
Juga, Anda dapat memutuskan untuk menyimpan dengan beberapa struktur atau elemen yang memungkinkan Anda untuk menelusuri gambar mentah di sistem file Anda tanpa hit db, atau mentransfer file secara massal ke sistem lain, hard drive, S3 atau skenario lain - memperbarui lokasi di program Anda, tetapi pertahankan strukturnya, lagi tanpa banyak ketukan mencoba untuk mengeluarkan gambar dari db Anda ketika mencoba meningkatkan penyimpanan.
Mungkin, itu juga akan memungkinkan Anda untuk melemparkan beberapa elemen caching, berdasarkan url gambar yang biasanya mengenai ke mesin / program web Anda, sehingga Anda menyelamatkan diri di sana juga.
Gambar statis kecil (tidak lebih dari beberapa MB) yang tidak sering diedit, harus disimpan dalam database. Metode ini memiliki beberapa manfaat termasuk portabilitas yang lebih mudah (gambar ditransfer dengan database), cadangan / pengembalian yang lebih mudah (gambar didukung dengan database) dan skalabilitas yang lebih baik (folder sistem file dengan ribuan file thumbnail kecil terdengar seperti mimpi buruk skalabilitas untuk saya).
Melayani gambar dari basis data itu mudah, cukup terapkan http handler yang melayani array byte yang dikembalikan dari server DB sebagai aliran biner.
Inilah kertas putih yang menarik tentang topik tersebut.
To BLOB or Not To BLOB: Penyimpanan Objek Besar dalam Database atau Filesystem
Jawabannya adalah, tergantung." Tentu saja itu akan tergantung pada server database dan pendekatannya terhadap penyimpanan gumpalan. Ini juga tergantung pada jenis data yang disimpan dalam gumpalan, serta bagaimana data itu akan diakses.
File berukuran lebih kecil dapat disimpan dan dikirim secara efisien menggunakan database sebagai mekanisme penyimpanan. File yang lebih besar mungkin akan lebih baik disimpan menggunakan sistem file, terutama jika mereka akan sering dimodifikasi / diperbarui. (Fragmentasi gumpalan menjadi masalah dalam hal kinerja.)
Inilah poin tambahan yang perlu diingat. Salah satu alasan yang mendukung penggunaan database untuk menyimpan gumpalan adalah kepatuhan ACID. Namun, pendekatan yang digunakan penguji dalam buku putih, (opsi Bulk Logged dari SQL Server,) yang menggandakan throughput SQL Server, secara efektif mengubah 'D' di ACID menjadi 'd,' karena data gumpalan tidak dicatat dengan menulis awal untuk transaksi. Oleh karena itu, jika kepatuhan ACID penuh merupakan persyaratan penting untuk sistem Anda, membagi dua angka throughput SQL Server untuk database ketika menulis file I / O ke database blob I / O.
Satu hal yang saya belum melihat ada yang menyebutkan tetapi pasti patut dicatat adalah bahwa ada masalah yang terkait dengan menyimpan sejumlah besar gambar di sebagian besar sistem file juga. Sebagai contoh jika Anda mengambil pendekatan yang disebutkan di atas dan memberi nama setiap file gambar setelah kunci utama, pada sebagian besar sistem file Anda akan mengalami masalah jika Anda mencoba untuk meletakkan semua gambar dalam satu direktori besar setelah Anda mencapai jumlah gambar yang sangat besar ( mis. dalam ratusan ribu atau jutaan).
Setelah solusi umum untuk ini adalah untuk hash mereka keluar ke pohon subdirektori yang seimbang.
Sesuatu yang tidak disebutkan oleh siapa pun adalah bahwa DB menjamin aksi atom, integritas transaksional, dan kesepakatan dengan konkurensi. Bahkan integritas referensial keluar dari jendela dengan sistem file - jadi bagaimana Anda tahu nama file Anda masih benar?
Jika Anda memiliki gambar dalam sistem file dan seseorang membaca file saat Anda sedang menulis versi baru atau bahkan menghapus file - apa yang terjadi?
Kami menggunakan gumpalan karena lebih mudah dikelola (cadangan, replikasi, transfer) juga. Mereka bekerja dengan baik untuk kita.
Masalah dengan hanya menyimpan filepath ke gambar dalam database adalah bahwa integritas database tidak lagi dapat dipaksakan.
Jika gambar aktual yang ditunjukkan oleh filepath menjadi tidak tersedia, database tanpa disadari memiliki kesalahan integritas.
Mengingat bahwa gambar adalah data aktual yang dicari, dan bahwa mereka dapat dikelola lebih mudah (gambar tidak akan tiba-tiba menghilang) dalam satu database terintegrasi daripada harus berinteraksi dengan beberapa jenis sistem file (jika sistem file diakses secara independen, gambar MUNGKIN tiba-tiba "menghilang"), saya akan pergi untuk menyimpannya secara langsung sebagai gumpalan atau semacamnya.
Di perusahaan tempat saya dulu bekerja, kami menyimpan 155 juta gambar dalam basis data Oracle 8i (kemudian 9i). Nilai 7,5TB.
Biasanya, saya sangat menentang mengambil bagian yang paling mahal dan paling sulit untuk skala infrastruktur Anda (database) dan meletakkan semua beban ke dalamnya. Di sisi lain: Ini sangat menyederhanakan strategi cadangan, terutama ketika Anda memiliki beberapa server web dan perlu entah bagaimana menjaga sinkronisasi data.
Seperti kebanyakan hal lainnya, Itu tergantung pada ukuran dan Anggaran yang diharapkan.
Kami telah menerapkan sistem pencitraan dokumen yang menyimpan semua gambar itu di bidang gumpalan SQL2005. Ada beberapa ratus GB saat ini dan kami melihat waktu respons yang sangat baik dan sedikit atau tidak ada penurunan kinerja. Selain itu, dari kepatuhan peraturan, kami memiliki lapisan middleware yang mengarsipkan dokumen yang baru diposting ke sistem jukebox optik yang memaparkannya sebagai sistem file NTFS standar.
Kami sangat senang dengan hasilnya, khususnya yang berkaitan dengan:
Asumsi: Aplikasi diaktifkan web / berbasis web
Saya terkejut tidak ada yang benar-benar menyebutkan ini ... mendelegasikannya kepada orang lain yang merupakan spesialis -> menggunakan penyedia hosting gambar / file pihak ke-3 .
Simpan file Anda di layanan online berbayar seperti
Utas StackOverflow lain membicarakan hal ini di sini .
Utas ini menjelaskan mengapa Anda harus menggunakan penyedia hosting pihak ke-3.
Ini sangat berharga. Mereka menyimpannya secara efisien. Tidak ada bandwidth yang diunggah dari server Anda ke permintaan klien, dll.
Jika Anda tidak menggunakan SQL Server 2008 dan Anda memiliki alasan kuat untuk meletakkan file gambar tertentu dalam database, maka Anda bisa mengambil pendekatan "keduanya" dan menggunakan sistem file sebagai cache sementara dan menggunakan database sebagai repositori master .
Misalnya, logika bisnis Anda dapat memeriksa apakah file gambar ada pada disk sebelum menyajikannya, mengambil dari database bila perlu. Ini memberi Anda kemampuan beberapa server web dan lebih sedikit masalah sinkronisasi.
Saya tidak yakin berapa banyak contoh "dunia nyata" ini, tetapi saat ini saya memiliki aplikasi di luar sana yang menyimpan perincian untuk permainan kartu perdagangan, termasuk gambar untuk kartu-kartu itu. Memang jumlah catatan untuk database hanya 2851 catatan hingga saat ini, tetapi mengingat fakta bahwa kartu-kartu tertentu telah dirilis beberapa kali dan memiliki karya seni alternatif, sebenarnya lebih efisien untuk memindai "alun-alun" dari karya seni dan kemudian secara dinamis menghasilkan efek perbatasan dan lain-lain untuk kartu saat diminta.
Pencipta asli pustaka gambar ini membuat kelas akses data yang membuat gambar berdasarkan permintaan, dan itu cukup cepat untuk dilihat dan kartu individual.
Ini juga memudahkan penyebaran / pembaruan ketika kartu baru dirilis, alih-alih membuka seluruh folder gambar dan mengirimkannya ke saluran dan memastikan struktur folder yang tepat dibuat, saya cukup memperbarui database dan meminta pengguna mengunduhnya lagi. Saat ini ukurannya mencapai 56MB, yang tidak terlalu bagus, tapi saya sedang mengerjakan fitur pembaruan tambahan untuk rilis mendatang. Selain itu, ada versi "tidak ada gambar" dari aplikasi yang memungkinkan mereka yang menggunakan dial-up untuk mendapatkan aplikasi tanpa penundaan unduhan.
Solusi ini telah bekerja dengan baik hingga saat ini karena aplikasi itu sendiri ditargetkan sebagai satu contoh di desktop. Ada situs web di mana semua data ini diarsipkan untuk akses online, tetapi saya sama sekali tidak akan menggunakan solusi yang sama untuk ini. Saya setuju akses file akan lebih disukai karena akan skala yang lebih baik dengan frekuensi dan volume permintaan yang dibuat untuk gambar.
Mudah-mudahan ini tidak terlalu mengoceh, tapi saya melihat topik dan ingin memberikan beberapa wawasan saya dari aplikasi skala kecil / menengah yang relatif sukses.
SQL Server 2008 menawarkan solusi yang memiliki yang terbaik dari kedua dunia: Tipe data filestream .
Mengelolanya seperti tabel biasa dan memiliki kinerja sistem file.
Itu tergantung pada jumlah gambar yang akan Anda simpan dan juga ukurannya. Saya telah menggunakan basis data untuk menyimpan gambar di masa lalu dan pengalaman saya cukup baik.
IMO, Kelebihan menggunakan database untuk menyimpan gambar adalah,
A. Anda tidak perlu struktur FS untuk menyimpan gambar Anda
B. Indeks basis data berkinerja lebih baik daripada pohon-pohon FS ketika lebih banyak item disimpan
C. Basis data yang disetel dengan cerdas melakukan pekerjaan dengan baik dalam menyimpan hasil kueri
D. Cadangan sederhana. Ini juga berfungsi dengan baik jika Anda memiliki pengaturan replikasi dan konten dikirimkan dari server di dekat pengguna. Dalam kasus seperti itu, sinkronisasi eksplisit tidak diperlukan.
Jika gambar Anda akan menjadi kecil (katakanlah <64k) dan mesin penyimpanan db Anda mendukung inline (dalam rekaman) gumpalan, itu meningkatkan kinerja lebih lanjut karena tidak ada tipuan yang diperlukan (Lokalitas referensi tercapai).
Menyimpan gambar mungkin merupakan ide yang buruk ketika Anda berhadapan dengan sejumlah kecil gambar berukuran besar. Masalah lain dengan menyimpan gambar dalam db adalah, metadata seperti kreasi, tanggal modifikasi harus ditangani oleh aplikasi Anda.
Saya baru-baru ini membuat aplikasi PHP / MySQL yang menyimpan file PDF / Word dalam tabel MySQL (sebesar 40MB per file sejauh ini).
Pro:
Cons:
Saya sebut implementasi saya sukses, itu mengurus persyaratan cadangan dan menyederhanakan tata letak proyek. Performanya baik untuk 20-30 orang yang menggunakan aplikasi.
Im pengalaman saya, saya harus mengelola kedua situasi: gambar yang disimpan dalam database dan gambar pada sistem file dengan jalur yang disimpan dalam db.
Solusi pertama, gambar dalam basis data, agak "lebih bersih" karena lapisan akses data Anda harus berurusan hanya dengan objek basis data; tetapi ini hanya baik ketika Anda harus berurusan dengan angka rendah.
Jelas kinerja akses database ketika Anda berurusan dengan objek besar biner merendahkan, dan dimensi database akan tumbuh banyak, menyebabkan lagi kehilangan kinerja ... dan biasanya ruang database jauh lebih mahal daripada ruang sistem file.
Di sisi lain, memiliki objek biner besar yang disimpan dalam sistem file akan menyebabkan Anda memiliki rencana cadangan yang harus mempertimbangkan basis data dan sistem file, dan ini dapat menjadi masalah bagi beberapa sistem.
Alasan lain untuk menggunakan sistem file adalah ketika Anda harus membagikan data gambar Anda (atau suara, video, apa pun) dengan akses pihak ketiga: hari ini saya sedang mengembangkan aplikasi web yang menggunakan gambar yang harus diakses dari "luar "Peternakan web saya sedemikian rupa sehingga akses basis data untuk mengambil data biner tidak mungkin. Jadi terkadang ada juga pertimbangan desain yang akan mengarahkan Anda ke suatu pilihan.
Pertimbangkan juga, ketika membuat pilihan ini, jika Anda harus berurusan dengan izin dan otentikasi ketika mengakses objek biner: syarat ini biasanya dapat diselesaikan dengan cara yang lebih mudah ketika data disimpan dalam db.
Saya pernah bekerja pada aplikasi pengolah gambar. Kami menyimpan gambar yang diunggah dalam direktori yang mirip dengan / images / [tanggal hari ini] / [nomor id]. Tetapi kami juga mengekstraksi metadata (data exif) dari gambar dan menyimpannya dalam database, bersama dengan stempel waktu dan semacamnya.
Dalam proyek sebelumnya saya menyimpan gambar pada sistem file, dan itu menyebabkan banyak sakit kepala dengan backup, replikasi, dan sistem file keluar dari sinkronisasi dengan database.
Dalam proyek terbaru saya, saya menyimpan gambar dalam database, dan menyimpannya di sistem file, dan itu bekerja dengan sangat baik. Sejauh ini saya tidak punya masalah.
Kedua rekomendasi pada jalur file. Saya telah mengerjakan beberapa proyek yang perlu mengelola pengumpulan aset besar-besaran, dan setiap upaya untuk menyimpan berbagai hal secara langsung dalam DB mengakibatkan rasa sakit dan frustrasi dalam jangka panjang.
Satu-satunya "pro" nyata yang dapat saya pikirkan tentang menyimpannya di DB adalah potensi untuk kemudahan aset gambar individu. Jika tidak ada jalur file untuk digunakan, dan semua gambar dialirkan langsung dari DB, tidak ada bahaya pengguna menemukan file yang seharusnya tidak dapat mereka akses.
Namun sepertinya itu akan lebih baik diselesaikan dengan skrip perantara yang menarik data dari penyimpanan file yang tidak dapat diakses web. Jadi penyimpanan DB TIDAK SANGAT perlu.
Kata di jalan adalah bahwa kecuali Anda adalah vendor database yang berusaha membuktikan bahwa database Anda dapat melakukannya (seperti, katakanlah Microsoft membual tentang Terraserver menyimpan gambar bajillion di SQL Server) itu bukan ide yang sangat bagus. Ketika alternatif - menyimpan gambar pada file server dan jalur dalam database jauh lebih mudah, mengapa repot-repot? Gumpalan bidang seperti kemampuan off-road SUV - kebanyakan orang tidak menggunakannya, mereka yang biasanya mendapat masalah, dan ada yang melakukannya, tetapi hanya untuk bersenang-senang saja.
Menyimpan gambar dalam database masih berarti bahwa data gambar berakhir di suatu tempat dalam sistem file tetapi dikaburkan sehingga Anda tidak dapat mengaksesnya secara langsung.
+ ves:
-saya:
Kedua metode ini umum dan dipraktikkan. Lihatlah kelebihan dan kekurangannya. Apa pun itu, Anda harus memikirkan cara mengatasi kerugiannya. Menyimpan dalam database biasanya berarti mengutak-atik parameter database dan mengimplementasikan beberapa jenis caching. Menggunakan filesystem mengharuskan Anda menemukan beberapa cara untuk menjaga sinkronisasi filesystem + database.