Apakah praktik yang buruk untuk menyimpan file besar (10 MB) dalam database?


188

Saat ini saya sedang membuat aplikasi web yang memungkinkan pengguna untuk menyimpan dan berbagi file, berukuran 1 MB - 10 MB.

Sepertinya saya bahwa menyimpan file dalam database akan secara signifikan memperlambat akses database.

Apakah ini masalah yang valid? Apakah lebih baik menyimpan file dalam sistem file dan menyimpan nama file dan path dalam database? Adakah praktik terbaik yang terkait dengan menyimpan file saat bekerja dengan database?

Saya bekerja di PHP dan MySQL untuk proyek ini, tetapi masalah ini sama untuk sebagian besar lingkungan ( Ruby on Rails , PHP , .NET ) dan basis data (MySQL, PostgreSQL ).


9
Pertanyaan terkait pada DBA.SE: File - dalam database atau tidak?
Nick Chammas

11
Terkejut bahwa tidak ada yang memposting penelitian MS yang dilakukan pada masalah ini (untuk SQL Server 2008): Untuk BLOB atau Tidak Untuk BLOB: Penyimpanan Objek Besar dalam Database atau Filesystem
Oded

2
besar adalah jumlah relatif, saya (dan banyak lainnya mungkin) tidak melihat 10MBsebesar dalam sistem modern.

27
Ini sesuai topik menurut FAQ - sesuai dengan "pola desain" ("slash antipatterns") dan "arsitektur perangkat lunak". Kenapa ditutup?
Izkata

21
Saya tidak melihat adanya ketidakjelasan dalam pertanyaan seperti sekarang. Saya tidak tahu mengapa ditutup.
reinierpost

Jawaban:


139

Alasan yang mendukung menyimpan file dalam database:

  1. ACID konsistensi termasuk rollback dari pembaruan yang rumit ketika file disimpan di luar database. Ini tidak boleh terlalu terang. Memiliki file dan database dalam sinkronisasi dan dapat berpartisipasi dalam transaksi bisa sangat berguna.
  2. File pergi dengan database dan tidak bisa menjadi yatim dari itu.
  3. Cadangan secara otomatis menyertakan file binari.

Alasan penyimpanan file dalam database:

  1. Ukuran file biner berbeda di antara basis data. Pada SQL Server, ketika tidak menggunakan objek FILESTREAM, misalnya, itu adalah 2 GB. Jika pengguna perlu menyimpan file yang lebih besar (seperti misalnya film), Anda harus melompat melewati lingkaran untuk membuat keajaiban itu terjadi.
  2. Meningkatkan ukuran database. Satu konsep umum yang harus Anda ambil dalam hati: Tingkat pengetahuan yang diperlukan untuk memelihara basis data naik secara proporsional dengan ukuran basis data.Yaitu, database besar lebih rumit untuk dipelihara daripada database kecil. Menyimpan file dalam database dapat membuat database jauh lebih besar. Bahkan jika cadangan penuh harian sudah mencukupi, dengan ukuran basis data yang lebih besar, Anda mungkin tidak lagi dapat melakukannya. Anda mungkin harus mempertimbangkan untuk meletakkan file pada grup file yang berbeda (jika database mendukungnya), atur cadangan untuk memisahkan cadangan data dari cadangan file, dll. Tidak satu pun dari hal-hal ini yang mustahil untuk dipelajari, tetapi lakukan menambah kompleksitas untuk pemeliharaan yang berarti biaya untuk bisnis. Database yang lebih besar juga mengkonsumsi lebih banyak memori karena mereka mencoba memasukkan data sebanyak mungkin ke dalam memori.
  3. Portabilitas dapat menjadi perhatian jika Anda menggunakan fitur khusus sistem seperti objek SQL Server FILESTREAMdan perlu bermigrasi ke sistem database yang berbeda.
  4. Kode yang menulis file ke database bisa menjadi masalah. Satu perusahaan yang saya temui belum banyak bulan yang lalu di beberapa titik menghubungkan frontend Microsoft Access ke server database mereka dan menggunakan kemampuan Access untuk mengunggah "apa pun" menggunakan kontrol Ole Object-nya. Kemudian mereka berubah menggunakan kontrol yang berbeda yang masih mengandalkan Ole. Jauh kemudian seseorang mengubah antarmuka untuk menyimpan biner mentah. Mengekstrak objek Ole itu adalah level baru neraka. Ketika Anda menyimpan file di sistem file, tidak ada lapisan tambahan yang terlibat untuk membungkus / mengubah / mengubah file sumber.
  5. Lebih rumit untuk menyajikan file ke situs web. Untuk melakukannya dengan kolom biner, Anda harus menulis handler untuk mengalirkan file biner dari database. Anda juga dapat melakukan ini bahkan jika Anda menyimpan jalur file tetapi Anda tidak harus melakukan ini. Sekali lagi, menambahkan handler bukan tidak mungkin tetapi menambah kompleksitas dan merupakan titik kegagalan lainnya.
  6. Anda tidak dapat memanfaatkan penyimpanan cloud. Misalkan suatu hari Anda ingin menyimpan file Anda di ember Amazon S3. Jika yang Anda simpan di database adalah path file, Anda diberi kemampuan untuk mengubahnya ke path di S3. Sejauh yang saya ketahui, itu tidak mungkin dalam skenario apa pun dengan DBMS.

IMO, menganggap penyimpanan file dalam database atau tidak sebagai "buruk" memerlukan informasi lebih lanjut tentang keadaan dan persyaratan. Apakah ukuran dan / atau jumlah file selalu kecil? Apakah tidak ada rencana untuk menggunakan penyimpanan cloud? Apakah file akan disajikan di situs web atau biner yang dapat dijalankan seperti aplikasi Windows?

Secara umum, pengalaman saya menemukan bahwa menyimpan jalur lebih murah untuk bisnis bahkan memperhitungkan kurangnya ACID dan kemungkinan anak yatim. Namun, itu tidak berarti bahwa internet tidak banyak dengan cerita-cerita tentang kurangnya kontrol ACID yang salah dengan penyimpanan file tetapi itu berarti bahwa secara umum solusi itu lebih mudah untuk dibangun, dipahami dan dipelihara.


Mengapa Anda tidak bisa menggunakan CDN? Ini adalah skenario yang didukung dengan hampir semua CDN yang pernah saya dengar.
Billy ONeal

@BillyONeal - Anda tidak dapat menggunakan CDN dan menyimpan file dalam database. Kecuali Anda baik-baik saja dengan duplikasi, Anda tidak bisa memiliki keduanya.
Thomas

3
Eh, inti dari CDN adalah duplikasi. CDN hanya men-cache target alamat web - satu-satunya persyaratan adalah bahwa ada host HTTP yang menyajikan konten, dan bahwa konten jarang berubah. (Bagaimana CDN bisa mengatakan di mana Anda mengambil gambar itu?)
Billy ONeal

3
@Illyillyeal - Namun, saya pikir ini adalah pilihan kata yang buruk di pihak saya dan saya telah menyesuaikan jawaban saya. Khususnya, jika Anda ingin menggunakan penyimpanan cloud (dan kemudian mungkin menggunakan CDN dengan penyimpanan cloud Anda), Anda tidak dapat melakukannya secara native dengan solusi penyimpanan database. Anda harus menulis rutin sinkronisasi untuk menarik file dari database dan kemudian mengirimkannya ke penyedia penyimpanan cloud Anda.
Thomas

@BillyONeal - Bisa dibilang, komentar Anda adalah jawaban terbaik. Anda dapat memiliki semua manfaat penyimpanan DB, tetapi tidak ada masalah.
B Tujuh

89

Dalam banyak kasus, ini adalah ide yang buruk. Ini akan menggembungkan file database dan menyebabkan beberapa masalah kinerja. Jika Anda menempelkan gumpalan di sebuah meja dengan sejumlah besar kolom itu bahkan lebih buruk.

Namun! Beberapa database, seperti SQL Server memiliki tipe kolom FILESTREAM. Dalam hal ini, data Anda sebenarnya disimpan dalam file terpisah di server database dan hanya ID untuk file yang disimpan dalam tabel. Dalam hal ini saya tidak melihat banyak alasan untuk tidak menyimpan data di server SQL. File secara otomatis dimasukkan sebagai bagian dari cadangan server, dan database serta file tidak pernah tidak sinkron. Masalah dengan saran Tony untuk menyimpan nama file, adalah bahwa database dan sistem file dapat tidak sinkron. Basis data akan mengklaim file ada ketika sudah dihapus pada disk. Jika suatu proses memodifikasi database dan kemudian crash, file dan database tidak akan cocok (yaitu tidak ada ACID dengan file di luar database).


21
Saya tidak setuju dengan pernyataan `Jika suatu proses memodifikasi DB dan kemudian crash, file dan DB tidak akan cocok.` Jika Anda membungkus seluruh proses dalam transaksi (membuat file, memvalidasi file, memperbarui db) dan melempar pesan kesalahan ketika terjadi kesalahan, cukup mudah untuk menjaga mereka tetap sinkron.
pengantin

3
Saya dengan briddums tentang itu: pertimbangkan skenario: simpan file ke filesystem (tanpa menghapus yang lama), perbarui DB, pada keberhasilan menghapus file lama, pada rollback hapus file baru. Skenario kasus terburuk - jika prosesnya terputus, Anda memiliki file yatim piatu. Tetapi Anda selalu memiliki file yang dirujuk oleh DB dalam versi yang benar.
vartec

2
Masalah potensial lainnya dengan metode File / DB: 1) Anda harus melakukan pembaruan sebagai copy-on-write. Jika proses Anda macet selama pembaruan, status DB akan dibatalkan, file tidak akan. 2) Melakukan ini kemudian memerlukan semacam pengumpulan sampah dari file lama. 3) Menyimpan segala sesuatu di DB berarti bahwa versi DB dan file disinkronkan setelah cadangan. Pulihkan DB Anda ke statusnya 2 minggu lalu ... sekarang bagaimana di mana isi file pada saat itu?
Timothy Baldridge

3
@briddums - Tidak, karena SQL Server terintegrasi langsung ke dalam sistem file dan mengelola file-file itu atas nama OS. Saya belum menggunakannya sendiri, tetapi dokumentasi membuatnya tampak seperti FILESTREAM dan FileTables turunannya memberi Anda yang terbaik dari kedua dunia: File terikat erat ke basis data dan data terkait (memungkinkan Anda untuk mengelola data secara terpusat) tanpa membengkaknya basis data.
Nick Chammas

1
Saya setuju dengan Nick. Kami telah mengganti sistem Disk + DB kami dengan kolom FILESTREAM dan tidak pernah melihat ke belakang. Sangat menyenangkan bisa memiliki file yang diikat ke tabel lain melalui FK. Jadi Anda dapat benar-benar mengatakan "setiap orang harus memiliki satu atau lebih dokumen SDM yang terkait dengan mereka", atau yang lain seperti itu.
Timothy Baldridge

35

Ya, itu adalah praktik yang buruk.

Dampak kinerja pada DB:

  • jika Anda melakukan SELECTdengan kolom BLOB, Anda akan selalu melakukan akses disk, sementara tanpa BLOB Anda memiliki kesempatan untuk mendapatkan data langsung dari RAM (DB throughput tinggi akan dioptimalkan agar sesuai dengan tabel dalam RAM);
  • replikasi akan lambat, penundaan replikasi tinggi, karena harus mendorong BLOB ke budak. Penundaan replikasi tinggi akan menyebabkan semua jenis kondisi lomba dan masalah sinkronisasi lainnya, kecuali jika Anda secara eksplisit memperhitungkannya;
  • Backup / restore DB akan memakan waktu lebih lama;

Keuntungan kecepatan - tidak ada ! Sementara beberapa filesystem lama tidak akan menangani direktori dengan jutaan file, sebagian besar modern tidak memiliki masalah sama sekali dan bahkan menggunakan jenis struktur data yang sama seperti BD (biasanya B-tree). Misalnya ext4 (sistem file Linux standar) menggunakan Htree .

Kesimpulan: itu akan menghambat kinerja DB Anda dan tidak akan meningkatkan kinerja pengambilan file.

Juga, karena Anda berbicara tentang aplikasi web - melayani file statis langsung dari sistem file menggunakan server web modern, yang dapat melakukan sendfile()syscall adalah peningkatan kinerja yang luar biasa . Ini tentu saja tidak mungkin jika Anda mengambil file dari DB. Pertimbangkan misalnya benchmark ini , menunjukkan Ngnix melakukan 25K req / s dengan 1000 koneksi bersamaan pada laptop low-end. Beban semacam itu akan menggoreng jenis DB apa pun.


6
+1. Biarkan server web Anda melakukan yang terbaik, melayani file dari disk. Jangan membuatnya bertanya pada PHP, karena PHP harus bertanya pada MySQL, dll.
deizel

3
Kapan programmer akan mengetahui bahwa kinerja tidak terlalu penting?
reinierpost

2
@reinierpost: lol. mungkin ketika kita mendapatkan jurusan seni liberal ;-)
vartec

1
@BillyONeal: mengapa Anda berasumsi, bahwa Anda harus memiliki server yang sama untuk konten statis dan dinamis? Adapun untuk menyinkronkan file di server, ada alat yang dirancang khusus untuk itu, jauh lebih efisien daripada database. Menggunakan database sebagai fileserver seperti mencoba memalu palu dengan obeng.
vartec

1
@ Billyilly: Saya setuju ada beberapa "solusi" di mana itu akan bekerja, saya telah melihat cukup banyak pengaturan PHP amatir dengan gambar di MySQL. Namun, dalam pengaturan seperti itu, DB tidak akan pernah mendukung BLOB yang melayani lalu lintas tinggi.
vartec

18

Saya akan pragmatis tentang hal itu, dan mengikuti prinsip "jangan optimalkan". Buat solusi yang masuk akal saat ini, dan yang Anda punya sumber daya pengembangan untuk diimplementasikan dengan benar. Ada banyak masalah potensial . Tetapi itu tidak selalu menjadi masalah nyata. Misalnya, mungkin tidak akan menjadi masalah jika Anda memiliki 100 pengguna. Ini mungkin menjadi masalah jika Anda memiliki 100.000 atau 10.000.000 pengguna. Tetapi dalam kasus terakhir, harus ada dasar untuk sumber daya pembangunan lebih banyak untuk menangani semua masalah.

Tetapi menyimpan data dalam database tidak membebaskan Anda dari berurusan dengan masalah lain, misalnya di mana file harus disimpan, bagaimana mereka harus didukung, dll. Karena Anda menulis aplikasi web itu akan menjadi ide yang sangat bagus untuk alasan keamanan untuk memastikan bahwa proses hosting aplikasi tidak memiliki akses tulis ke sistem file, jadi Anda perlu mengkonfigurasi server agar proses tersebut memiliki akses baca / tulis ke folder tempat data disimpan.

Saya pribadi akan memilih untuk menyimpan data dalam database, tetapi pastikan bahwa BLOBS tidak dibaca sampai mereka benar-benar diperlukan, yaitu tidak ada "SELECT * FROM ..." dieksekusi pada tabel yang berisi blog. Dan saya akan memastikan bahwa desain membuatnya mudah untuk memindahkan data dari database, ke sistem file, jika Anda mendapatkan masalah kinerja. Misalnya menyimpan informasi file dalam tabel File terpisah , sehingga menjaga informasi file dari entitas bisnis lain.

Dengan asumsi bahwa Anda memiliki kelas File untuk mewakili file yang dibaca di dalam basis data, maka dampak pengkodean untuk memindahkannya nanti akan menjadi minimal.


Ini adalah saran yang bagus. Jangan mulai memecahkan masalah yang tidak Anda miliki.
Berat

16

Microsoft merilis buku putih tentang ini beberapa tahun yang lalu. Itu berkonsentrasi pada SqlServer, tetapi Anda mungkin menemukan beberapa informasi menarik di sana:

Untuk BLOB atau bukan BLOB? Penyimpanan Objek Besar dalam Database atau Sistem File?

Versi kesimpulan mereka yang sangat ringkas adalah:

Ketika membandingkan sistem file NTFS dan SQL Server 2005, BLOBS yang lebih kecil dari 256KB lebih efisien ditangani oleh SQL Server, sedangkan NTFS lebih efisien untuk BLOBS yang lebih besar dari 1MB.

Saya akan merekomendasikan Anda menulis beberapa tes kecil untuk use case khusus Anda. Ingatlah bahwa Anda harus waspada terhadap efek caching. (Saya kagum saat pertama kali saya mendapatkan kecepatan simpan ke disk yang tampaknya memiliki throughput yang lebih tinggi daripada yang dimungkinkan secara fisik!)


4
Anda harus tahu bahwa NTFS mulai berperilaku sangat tidak menentu ketika Anda meletakkan lebih dari ~ 100 ribu file dalam satu direktori. Akses file melambat sedikit (setidaknya urutan besarnya) dan operasi buka file mulai gagal (tampaknya) secara acak. Saya mengalami efek ini pada sistem Windows 2008 dan Windows 7. Ketika saya mendistribusikan kembali file di antara banyak direktori, semuanya kembali normal. Saya tidak tahu apakah situasinya telah membaik sejak saat itu.
Ferruccio

11

Kebijaksanaan konvensional lama untuk menyimpan file di luar basis data mungkin tidak lagi berlaku. Sebagai prinsip, saya lebih menyukai integritas daripada kecepatan, dan dengan DBMS modern, Anda dapat memiliki keduanya.

Tom Kyte tampaknya setuju :

Saya tahu tidak ada keuntungan untuk menyimpan data yang ingin saya simpan untuk waktu yang lama di luar basis data.

Jika ada di database saya bisa

pastikan itu dikelola secara profesional

didukung

dipulihkan (dengan sisa data)

diamankan

scalable (coba letakkan 100.000 dokumen dalam satu direktori, sekarang, letakkan di dalam tabel - yang mana 'skala' - itu bukan direktori)

Saya dapat membatalkan penghapusan (flashback) dengan mudah

Saya sudah mengunci

Saya telah membaca konsistensi ...


8

Iya.

Jika Anda menyajikan file dari sistem file Anda, server Web Anda dapat menggunakan kode kernel seperti sendfile () di BSD atau Linux untuk menyalin file secara langsung ke soket. Ini sangat cepat dan sangat efisien.

Melayani file dari database berarti Anda harus menyalin data dari disk server database ke memori server database, kemudian dari memori server db ke port jaringan server db, lalu masuk dari jaringan ke proses server Web Anda, kemudian keluar lagi ke koneksi jaringan keluar.

Kecuali Anda memiliki alasan yang sangat bagus untuk tidak melakukannya, selalu lebih baik untuk menyajikan file statis dari sistem file.


Ini benar, tetapi saya gagal melihat di mana pengguna menyatakan dalam pertanyaan bahwa ia akan melayani file statis dari database. Ini sangat baik bisa berupa file dinamis atau file yang diunggah pengguna yang jika disimpan pada sistem file yang terpisah dari basis data sekarang harus disinkronkan dan memiliki proses pencadangan / pemulihan terpisah.
maple_shaft

1
Pemahaman saya adalah pertanyaannya adalah tentang melayani file yang diunggah pengguna. "Saat ini saya membuat aplikasi web yang memungkinkan pengguna untuk menyimpan dan berbagi file [...] Sepertinya saya yang menyimpan file dalam database [...]". Saya tidak berpikir itu benar-benar nyaman untuk melakukan DB dumps dengan banyak gumpalan multi-megabyte dalam database. Juga: ya, sulit untuk berurusan dengan file; sinkronisasi, pengarsipan, semuanya lebih sulit. Namun, itu tidak jauh lebih sulit, dan mengorbankan kinerja online untuk menyimpan beberapa baris dalam skrip cadangan malam Anda adalah kesalahan besar.
Evan P.

5

Tom Kyte terkenal telah menulis bahwa mereka (Oracle) menggunakan database Oracle sebagai server file dan bekerja dengan sangat baik, bahkan lebih cepat dari sistem file normal, dengan transaksionalitas penuh, tanpa kehilangan kinerja dan dengan cadangan tunggal.

Ya, tetapi perhatikan, mereka adalah produsen Oracle DB, dan untuk pengguna lain ada masalah biaya. Menggunakan DB komersial seperti Oracle untuk penyimpanan file tidak efektif dari segi biaya.

Namun, dengan PostgreSQL misalnya, Anda bisa menjalankan contoh DB lain hanya untuk penyimpanan gumpalan. Kemudian Anda memiliki dukungan transaksional penuh. Tetapi transaksionalitas membutuhkan ruang DB. Ada kebutuhan untuk database untuk menyimpan beberapa contoh gumpalan untuk beberapa transaksi bersamaan. Pada PostgreSQL ini adalah yang paling menyakitkan, karena database ini menyimpan duplikat gumpalan yang dibuat untuk transaksi disimpan bahkan jika mereka tidak diperlukan lagi, sampai proses VACUUM dilakukan.

Dengan penyimpanan sistem file, di sisi lain, Anda harus sangat berhati-hati ketika seseorang memodifikasi file, karena transaksi dapat dibatalkan dan salinan file harus disimpan sampai versi lama tidak lagi terlihat.

Dalam sistem di mana file hanya ditambahkan dan dihapus, dan akses transaksional ke file tidak menjadi masalah, penyimpanan sistem file akan menjadi IMHO pilihan terbaik.


Hai, ketika Anda mengatakan "menggunakan ... Oracle untuk penyimpanan file tidak efektif biaya", bagaimana jika kita sudah menggunakan Oracle penyimpanan data non-file lainnya? Apakah itu masih tidak efektif biaya?
Xiao Peng - ZenUML.com

RE: "Anda harus sangat berhati-hati ketika seseorang memodifikasi file" ... sebagai mantan DBA Oracle, saya harus menyarankan bahwa file besar disimpan di luar database dan bahwa Anda tidak pernah mengizinkan file untuk dimodifikasi. Orang-orang membuat kesalahan. Satu-satunya cara praktis untuk mengelola kembalikan (undo) dari file-file itu adalah dengan menerapkan sistem Copy On Write untuk mereka. Semua versi dipertahankan dan diarsipkan. Yang tertua dapat dipindahkan ke penyimpanan jarak jauh, pos diproses untuk mengkonsolidasikan perubahan kecil menjadi satu arsip, dll.
DocSalvager

5

Biasanya yang terbaik untuk menyimpan BLOB besar di tabel terpisah dan simpan referensi kunci asing ke BLOB di tabel utama Anda. Dengan begitu, Anda masih dapat mengambil file dari database (sehingga Anda tidak memerlukan kode khusus) dan Anda menghindari masalah seputar dependensi DB eksternal (menjaga DB dan filesystem dalam sinkronisasi, dll), tetapi Anda hanya dikenakan overhead itu jika Anda secara eksplisit bergabung ke tabel itu (atau melakukan panggilan terpisah). 10MB tidak terlalu besar, kebanyakan database komersial modern tidak akan memiliki masalah. Satu-satunya alasan saya menyimpan file di sistem file adalah untuk mengurangi bandwidth database. Jika database Anda akan mengocok banyak file-file ini, maka Anda mungkin perlu membagi beban kerja dan hanya menyimpan deskriptor file. Kemudian Anda dapat memiliki panggilan terpisah untuk memuat file dari server lain,


4

Anda mungkin mengalami beberapa masalah ini:

  • Melakukan hal SELECT *yang melibatkan deretan dengan gumpalan besar memakan waktu sangat lama, bahkan jika Anda tidak memerlukan gumpalan (Tentu saja Anda harus melakukan pemilihan tertentu, tetapi terkadang aplikasi ditulis seperti ini)
  • Melakukan pencadangan bisa memakan waktu lebih lama. Tergantung pada kebutuhan Anda, Anda mungkin perlu mengunci tabel untuk waktu pencadangan, sehingga Anda mungkin ingin menjaga waktu pencadangan tetap rendah
  • Memulihkan juga akan membutuhkan lebih banyak waktu.
  • Jika Anda kehabisan ruang, Anda harus memikirkan beberapa cara (mungkin memindahkan seluruh database ke server baru) untuk menyelesaikan masalah ini. Menyimpan file pada sistem file Anda selalu dapat memasang hard drive lain dan mengatur soft link.
  • Cukup dengan mencari file untuk debugging atau informasi lain tidak mudah. Ini juga termasuk skrip yang mungkin tidak memiliki akses ke database tetapi memerlukan beberapa informasi dari berbagai file.

Tentu saja Anda juga mendapatkan beberapa manfaat:

  • Mencadangkan data dan file menas mereka sinkron
  • Menghapus file tanpa mengetahui basis data tidak mungkin
  • Anda tidak harus membaca file dari disk tetapi dapat melakukannya dalam satu pernyataan sql
  • Anda dapat mengunduh database, memasukkan dump ke lingkungan pengembangan Anda dan memiliki semua dependensi di sana

Secara pribadi saya tidak melakukannya karena saya menemukan kontra jauh lebih berat daripada pro. Tetapi seperti yang dinyatakan di atas, itu sepenuhnya tergantung pada use case Anda dan semacamnya.


1

Beberapa Sistem Manajemen Konten Enterpirse, seperti SiteCore, menggunakan satu database untuk menyimpan data halaman dan database lain untuk menyimpan file. Mereka menggunakan MS SQL Server.


bagaimana ini menjawab pertanyaan yang diajukan?
nyamuk

Jika Anda melakukan sedikit riset, Anda akan menemukan bahwa SiteCore adalah salah satu sistem manajemen konten perusahaan yang paling populer. SiteCore mendukung sejumlah besar pengguna bersamaan, dan skala cukup baik, jadi ya, menyimpan file di dalam basis data yang terpisah bukanlah praktik yang buruk jika Anda melakukannya dengan benar.
šljaker

1

Untuk implementasi praktis, berikut ini yang perlu Anda perhatikan:

Manfaat:

  1. Semua konten file pasti disinkronkan dengan tabel Anda. Seperti komentar di atas dikatakan, membuat cadangan data benar-benar nyaman karena Anda tidak perlu menyimpan data disinkronkan dengan sistem file.
  2. Dari pengkodean, Anda bisa mendapatkan konten file langsung dari pilihan SQL.
  3. Dari kueri, Anda bahkan dapat memfilter konten file atau ukurannya secara eksplisit dari pernyataan SQL.

Kerugian:

  1. Dibandingkan dengan basis data yang strukturnya secara semantik sama tetapi tidak menyimpan konten file, basis data Anda cenderung mengonsumsi lebih banyak memori secara radikal saat melakukan kueri.
  2. Pencadangan otomatis dapat menyebabkan masalah kinerja tetapi tidak banyak. Bayangkan server database Anda membuat cadangan setiap 6 jam dan database yang Anda miliki menyimpan file 10-MB per record. Skenario itu bukan yang Anda inginkan.
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.