Menyimpan Gambar dalam DB - Ya atau Tidak?


415

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?


Nah, Anda bisa melakukan keduanya dengan cache disk transaksional .
Sungai Lilith

Jawaban:


350

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:

  • penyimpanan basis data biasanya lebih mahal daripada penyimpanan sistem file
  • Anda dapat mempercepat akses sistem file dengan standar dari produk rak
    • misalnya, banyak server web menggunakan panggilan sistem sendfile () sistem operasi untuk mengirim file secara sinkron langsung dari sistem file ke antarmuka jaringan. Gambar yang disimpan dalam database tidak mendapat manfaat dari optimasi ini.
  • hal-hal seperti server web, dll, tidak memerlukan pengkodean atau pemrosesan khusus untuk mengakses gambar dalam sistem file
  • basis data menang di mana integritas transaksional antara gambar dan metadata penting.
    • lebih kompleks untuk mengelola integritas antara metadata db dan data sistem file
    • sulit (dalam konteks aplikasi web) untuk menjamin data telah dibilas ke disk pada sistem file

33
produk rak apa yang tersedia untuk "super-percepatan" sistem file?
Andrei Rînea

22
Meskipun saya hanya mengelola 3TB file, saya setuju. Basis data untuk data terstruktur, bukan blob.
derobert

7
@derobert: cukup, jika Anda tidak akan pernah menggunakan elemen data dalam kueri, sebagai kondisi atau untuk bergabung, itu mungkin tidak termasuk dalam database. Kemudian lagi, jika Anda memiliki fungsi basis data yang bagus untuk permintaan gambar untuk ...
Nils Weinander

14
produk rak apa yang tersedia untuk "super-percepatan" sistem file?
ablmf

5
Produk Re: "super-akselerasi": Sebagian besar server web sekarang dapat memanfaatkan panggilan sistem sendfile () untuk mengirimkan file statis secara asinkron ke klien. Ini membongkar ke sistem operasi tugas memindahkan file dari disk ke antarmuka jaringan. OS dapat melakukan ini jauh lebih efisien, beroperasi di ruang kernel. Bagi saya, ini seperti kemenangan besar untuk sistem file vs. db untuk menyimpan / menyajikan gambar.
Alan Donnelly

140

Seperti kebanyakan masalah, tidak sesederhana kedengarannya. Ada kasus di mana masuk akal untuk menyimpan gambar dalam database.

  • Anda menyimpan gambar yang berubah secara dinamis, katakan faktur dan Anda ingin mendapatkan faktur seperti pada 1 Januari 2007?
  • Pemerintah ingin Anda mempertahankan sejarah 6 tahun
  • Gambar yang disimpan dalam database tidak memerlukan strategi cadangan yang berbeda. Gambar yang disimpan pada sistem file dilakukan
  • Lebih mudah untuk mengontrol akses ke gambar jika mereka berada dalam database. Admin idle dapat mengakses folder apa pun di disk. Dibutuhkan admin yang benar-benar bertekad untuk mengintip database untuk mengekstrak gambar

Di sisi lain ada masalah yang terkait

  • Diperlukan kode tambahan untuk mengekstrak dan mengalirkan gambar
  • Latensi mungkin lebih lambat daripada akses file langsung
  • Beban lebih berat di server database

2
Tidak memiliki strategi cadangan yang terpisah bisa menjadi masalah besar ketika Anda menulis aplikasi yang diinstal pada premis (seperti SharePoint). Saat Anda membuat cadangan SharePoint semuanya ada dalam DB yang membuatnya sangat mudah.
Eric Schoonover

44
Keamanan oleh ketidakjelasan sebenarnya bukan strategi kontrol akses!
Jon Cage

5
Saya tidak berpikir dia menganjurkan keamanan dengan ketidakjelasan - dia mengatakan bahwa menempatkan gambar di DB menambah lapisan keamanan. (Saya pikir ... @Conrad, tidak ingin menaruh kata-kata di mulut Anda)
AJ

Saya memilih menyimpan gambar dalam database karena keunggulan cadangan tunggal (atau lebih umum, memiliki semua data di satu tempat), tetapi masalah yang Anda sebutkan juga benar, itulah sebabnya saya menyimpan gambar di sistem file. Ini yang terbaik dari kedua dunia, dan saya terkejut tidak ada jawaban teratas yang menyebutkannya.
Bart van Heukelom

Apakah Anda, secara kebetulan, menggunakan pustaka ImageResizing.Net untuk menangani caching gambar disk SQL-> Anda? Ini adalah cache disk paling canggih, terukur, dan kuat yang bisa Anda dapatkan ...
Lilith River


56

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:

  1. Blob sebenarnya disimpan sebagai file dalam folder.
  2. The Blob dapat diakses menggunakan baik koneksi database atau lebih filesystem.
  3. Cadangan terintegrasi.
  4. Migrasi "hanya berfungsi".

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.


+1 untuk FileStream. Sebenarnya menyimpan gumpalan sebagai file pada disk, tetapi mengelola secara transaksi.
John Gietzen

Juga, SQL server memungkinkan gumpalan FileStream menjadi akses langsung dari disk, sehingga Anda dapat menghindari mengikat koneksi DB
John Gietzen

Namun, menambahkan latensi antara DB dan server web ... Dan server web harus memuatnya ke dalam memori untuk mengalirkannya ke klien alih-alih dapat melakukan streaming dari disk, kecuali Anda menggunakan cache disk.
Sungai Lilith

39

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.


35

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.


Memang sangat bagus. Pengguna Anda sekarang dapat dengan mudah menambah nama file Anda untuk mengakses file lain ...
Marijn Huizendveld

6
@Marijn: Itu hanya jika Anda mengekspos gambar ke dunia.
Seun Osewa

Kami melakukan sesuatu yang sangat mirip dengan dokumen gambar kami (kunci utama kami adalah kunci gabungan dari tiga item.), Tetapi kami menambahkan tanggal dan waktu dokumen itu dipindai sehingga kami dapat memiliki beberapa versi di direktori yang sama.
Andrew Neely

@Osewa, Bagaimana? Ya, untuk mengakses file secara langsung, pengguna akhir akan memerlukan akses ke folder. Anda bisa memiliki proses untuk melayani file melalui FTP berdasarkan permintaan, dan keamanan akan setara dengan SQL server.
Andrew Neely

31

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.


6
Saya tidak melihat ada orang yang mengklaim bahwa sistem file lebih cepat daripada DB 100% dari waktu (baca jawaban Mark Harrison). Itu agak seperti jerami. Mungkin ada situasi di mana lebih disukai untuk tidak mengenakan sabuk pengaman Anda, tetapi secara umum , mengenakan sabuk pengaman adalah ide yang bagus.
Calvin

30

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.


7
Sebenarnya, tidak, kamu bisa. Selama file gambar tidak pernah dihapus, diubah, atau ditulis ulang begitu dibuat, semua file gambar disinkronkan sebelum mencoba melakukan transaksi, tidak ada kerusakan sistem file, Anda dapat yakin bahwa file gambar dan metadata dalam sinkronisasi. Untuk beberapa aplikasi, itu terlalu banyak seandainya, kurasa.
Seun Osewa

Saya akan melangkah lebih jauh dan mengatakan bahwa dengan sistem file Jurnal dan beberapa logika program tambahan, kepatuhan ACID dapat dicapai. Langkah-langkahnya adalah menulis catatan db, menulis file. Jika file melakukan, lakukan transaksi db.
Andrew Neely

28

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.


27

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.


Saya berpendapat bahwa database lebih baik untuk file yang sering diedit, karena konsistensi dapat menjadi masalah dalam kasus itu.
Seun Osewa

26

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.


25

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.


Anda mungkin berpikir begitu, tetapi masalahnya sebenarnya kecil; Saya memiliki aplikasi dengan jutaan file dalam satu direktori, diakses oleh ratusan pengguna, tanpa masalah. Itu tidak pintar, tetapi berhasil. Masalah terbesar adalah jika Anda menggunakan Explorer untuk menelusuri direktori, Anda menonton senter selamanya.
SqlACID

1
Lebih baik menggunakan sistem file yang tidak memiliki masalah dengan direktori besar
Seun Osewa

8
Saya memiliki aplikasi dengan jutaan file dalam satu direktori (server menjalankan RHEL 4) - bahkan untuk meratakan isi direktori (pemipaan ke file) membutuhkan waktu berhari-hari dan membuat file output berukuran 100-an MB. Sekarang mereka berada di database saya punya satu file yang bisa saya pindahkan atau backup dengan mudah.
Richard

1
@Seun Osewa: setiap sistem file memiliki batasan ... dan jika Anda mengetahui salah satu yang tidak memiliki masalah menyimpan jutaan entri di direktori yang sama, beri tahu saya!
Guillaume

1
@ Seun Osewa: database hingga 28GB sekarang, dengan catatan 5,4 M. Saya akhirnya harus mempartisi tabel database jadi saya punya beberapa file untuk membuat cadangan yang berukuran sekitar 5GB. Memindahkan masing-masing gambar ke Amazon S3 sekarang jadi saya hanya perlu menyimpan nama file dalam DB (dan Amazon dapat melakukan backup )
Richard

22

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.


Apa kemungkinan memiliki dua pembaruan simultan untuk gambar tertentu?
Arafangion

1
Anda tidak perlu pembaruan simultan untuk mendapatkan masalah - itu bisa berupa baca dan tulis. Dalam kasus kami ini hampir dijamin akan terjadi.
Draemon

20

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.


17

Di perusahaan tempat saya dulu bekerja, kami menyimpan 155 juta gambar dalam basis data Oracle 8i (kemudian 9i). Nilai 7,5TB.


5
Benar. Rupanya database jauh lebih besar sekarang. Memiliki data dalam database berarti bahwa mereplikasi database di situs yang berbeda juga jauh lebih mudah.
graham.reeds

Saya melihat demonstrasi Oracle di mana sebenarnya bisa me-mount sistem file ke database, atau sesuatu seperti itu. Apakah Anda tahu apakah ini yang Anda lakukan? (Maaf, saya tidak mengerti dengan Oracle jadi mungkin saya berbicara sampah.)
Stu Thompson

Saya tidak berpikir begitu - itu menyimpan gambar dalam database sebagai basis data. Basis data disetel secara agresif - Saya ingat beberapa diskusi mengenai ukuran gambar yang berubah ketika bidang ditambahkan dan dihapus. Semuanya dibatasi batas.
graham.reeds

14

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.


13

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:

  1. Kemudahan Replikasi dan Cadangan
  2. Kemampuan untuk dengan mudah menerapkan sistem versi dokumen

11

Jika ini adalah aplikasi berbasis web maka mungkin ada keuntungan untuk menyimpan gambar pada jaringan pengiriman penyimpanan pihak ketiga, seperti Amazon S3 atau platform Nirvanix.


11

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.


10

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.


+1 Ini juga memungkinkan Anda untuk menyimpan gambar asli, mengirimkan versi yang di-cache / dioptimalkan sambil memungkinkan ukuran / kompresi diubah nanti
Deebster

7

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.


Saat berhadapan dengan replikasi, menyimpan gambar dalam basis data jauh lebih unggul dari IMO.
Bip bip


7

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.


7

Saya baru-baru ini membuat aplikasi PHP / MySQL yang menyimpan file PDF / Word dalam tabel MySQL (sebesar 40MB per file sejauh ini).

Pro:

  • File yang diunggah direplikasi ke server cadangan bersama dengan yang lainnya, tidak ada strategi cadangan yang diperlukan (ketenangan pikiran).
  • Menyiapkan server web sedikit lebih sederhana karena saya tidak perlu memiliki unggahan / folder dan memberi tahu semua aplikasi saya di mana itu.
  • Saya bisa menggunakan transaksi untuk pengeditan untuk meningkatkan integritas data - Saya tidak perlu khawatir tentang file yatim dan hilang

Cons:

  • mysqldump sekarang membutuhkan waktu lama karena ada 500MB data file di salah satu tabel.
  • Secara keseluruhan tidak terlalu hemat memori / CPU jika dibandingkan dengan sistem file

Saya sebut implementasi saya sukses, itu mengurus persyaratan cadangan dan menyederhanakan tata letak proyek. Performanya baik untuk 20-30 orang yang menggunakan aplikasi.


6

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.


4

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.


4

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.


3

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.


3

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.


3

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:

  • integritas basis data
  • ini mudah dikelola karena Anda tidak perlu khawatir tentang menjaga sistem file tetap sinkron ketika gambar ditambahkan atau dihapus

-saya:

  • penalti kinerja - pencarian basis data biasanya lebih lambat daripada pencarian sistem file
  • Anda tidak dapat mengedit gambar secara langsung (memotong, mengubah ukuran)

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.

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.