Ushbu ilovadagi ma'lumotlar bazasida yoki fayl tizimimda rasmlarni saqlashim kerakmi?

ASP.NET MVC 4 va SQL Server 2012 dan foydalanayapman. Bu echimlar uchun hech qanday muammo yo'q, lekin hozir men yaratayotgan muayyan ilovada kimga mosroq ekanini bilishni istayman.

Men kutubxona tizimiga o'xshash dasturni ishlab chiqyapman. Dastur saqlaydigan yagona rasm:

  • Foydalanuvchilarning profilidagi rasmlar (foydalanuvchi uchun 1 ta)
  • Kutubxonalarning profil rasmlari (kutubxona uchun 1)
  • Kitob mualliflarining suratlari (muallifga 1)
  • Kitobning qopqoq rasmlari (1 ta kitob)

Saqlangan tasvirlarning hech biri yuqori sifatli bo'lishi kerak emas. Shubhasizki, tasvirlar dasturning katta qismi emas va buni hisobga olsak, men hozirda ma'lumotlar bazamda saqlanyapman. Garchi men bir narsani tushungan bo'lsam-da, menimcha, bu katta kon uchun.

Rasmlar ma'lumotlar bazasiga yetib borishdan, kitobning rasmini olishdan va uni qaytarib yuborishdan oldin bookId parametrini qabul qiladigan Controller harakati usuliga olib keladigan Url.ActionLink yordamida olinadi. Shuning uchun agar foydalanuvchi kitoblarni qidirishni boshlasa va u o'zlarining tasvirlari bilan birga kitoblar ro'yxatini olishni tugatgan bo'lsa, tasvirlarni qaytaradigan va royxatdagi har bir rasm uchun ma'lumotlar bazasiga yangi so'rovni chaqiradigan ish uslubiga yangi qo'ng'iroq bo'ladi.

Buning uchun yaxshiroq yo'l bormi? Ma'lumotlar bazasida saqlanishni qayta ko'rib chiqsam bo'ladimi yoki bu katta masala emasmi?

EKRAN: Ushbu savolni ikki nusxada ko'rib chiqmaysizmi, chunki u dasturning istalgan turiga (link savol ). Albatta siz tasvirni saqlay olishingiz kerak bo'lgan ma'lumotlarga ishonchingiz komil emas, chunki fayllarni fayl tizimida saqlash uchun har doim eng yaxshisidir. Bu shunday emas. Bu erda berilgan javoblarga qarama-qarshi bo'lgan javoblar tabiatan buni ko'rsatadi.

9
Fayl tizimidagi tasvirlarga ega bo'lishning afzalligi, nginx yoki lighttpd kabi ba'zi bir engil vaznli (va shunga o'xshash tezroq) server bilan alohida xonadan xizmat qilishingiz. Lekin, albatta, bu barqarorlik muammolari uchun joy ochadi.
qo'shib qo'ydi muallif Vali Hutchison, manba
Ushbu maqsadlar uchun NoSQL ma'lumotlar bazasini ko'rib chiqdingizmi? Ushbu turdagi ma'lumotlarni samarali ishlashga imkon beruvchi ma'lumotlar bazasidan foydalanishingiz mumkin faylga kirishda aralashtirish o'rniga so'rovlarni bajarishingiz kerak.
qo'shib qo'ydi muallif user22815, manba
@Snowman Menimcha, NoSQL, bu dastur uchun, albatta, bir overkill. Men EF6 dan foydalanishni hisobga olsak, faqat men uchun axborot uzatish uchun yanada murakkablashadi.
qo'shib qo'ydi muallif Alternatex, manba

5 javoblar

Nima uchun ikkalasini ham qilmaysiz? Ma'lumotlar bazasi - rasmning yakuniy savatchasi. Jamoat tarafi dbdan oddiy o'qish bo'lishi mumkin, ammo uni osongina o'qish disk keshiga uzaytira olasiz va ishlashni yaxshilash uchun ko'plab infrastruktura pultlaridan foydalanishingiz mumkin.

Bu erda g'oliblar:

  • simpler data backup -- database backups are fun and easy, no file system touching necessary
  • simpler dev story -- you don't need to handle a bunch of files, just get the dev team a copy of the database
  • easier to write the image -- file systems are a PITA, from permissions, to changing locations from dev->qa->production, to contention to lack of transactions. If the writes are going to the db then you solve 90% of those problems.
  • modern databases can handle it -- presuming we are talking fairly typical image file sizes measuring under a few megabytes most modern database systems can handle them very well. It is not the database murdering issue that some older articles would have you believe.
8
qo'shib qo'ydi
Rahmat. Men suyakka juda yaqin deb o'ylamagan edim, lekin CD-disklar uchun ham xuddi shu fikrni o'qish keshidagi diskda qo'llash mumkin edi.
qo'shib qo'ydi muallif Mark Gibaud, manba
Buni javob sifatida tanlayman, lekin har ikkala javobim qarorimni qabul qilishda juda foydali bo'ldi. Menga hali ham ma'lumotlar bazasida rasmlarni to'g'ri saqlash usulini saqlashni ko'rib chiqishga da'vat etdim.
qo'shib qo'ydi muallif Alternatex, manba

Shunday qilib, foydalanuvchi kitoblarni izlab topishi va oldingi tasvirlari bilan birga kitoblar ro'yxatini olishni tugatishi kerak bo'lsa, tasvirlarni qayta chaqiradigan va har bir yangi ma'lumotlar bazasiga yangi so'rovni yuboradigan ish uslubiga yangi qo'ng'iroq bo'ladi. rasm.

Men buni yaxshi narsalarni taklif qilaman. Rasmlar matndan ko'ra ko'proq vaqt talab etadi, shuning uchun foydalanuvchining har ikkala DB ni yuklashini kutishini istamasangiz, matnni ko'rsatishingiz va rasmlarni alohida ko'rsatishingiz mumkin.

Bundan tashqari, sizning arizangiz muvaffaqiyatli bo'lishiga qaramasdan, veb-ilovangizni bir nechta serverlarda ishlashingiz mumkin. Har bir server ushbu nuqtada ma'lumotlar bazasiga kirish huquqiga ega bo'ladi, ammo boshqa server fayl tizimiga kirmaydi.

Biroq, tasvirni o'z tasvirlaridagi jadvalda ajratish kerak. Tasvirni kitob bilan bir xil jadvalda saqlamang; faqat rasm identifikatorini saqlab qo'ying va keyinroq tasvirni olish uchun foydalaning. Bu ma'lumotlar bazalari diskdagi ma'lumotlarni boshqarish usulini inobatga olgan holda, bu juda samarali. Agar siz kitob bilan bog'liq suratni biron-bir nuqtada o'zgartirishni rejalashtirmoqchi bo'lsangiz, ushbu bayonot juda muhimdir.

Va nihoyat, bu narsalar bilan bog'liq bo'lgan tajribam shundaki, siz tasvirni saqlash uchun Content Delivery Network (AWS CloudFront yoki Azure CDN yoki CloudFlare) ni ishlatmoqchi bo'lgan vaziyatni juda tez tezda bostirasiz, albatta, bu ikkala dunyoning eng yaxshisi - ilovangizni bezovta qilmasdan to'g'ridan-to'g'ri URL manziliga kirish mumkin bo'lgan ikkinchi darajali xotira - bu qo'shimcha ish emas. CDN-ga ko'chirish rasmlaringizni o'z stoliga ajratganingizda juda oson o'zgarish.

Yoki endi CDN yechimiga o'tishingiz mumkin va bu haqda qayg'urmang.

4
qo'shib qo'ydi
@EsbenSkovPedersen: "CDNga o'tish" degan jumlaning "bu" degan ma'noni anglatadi ... ehtimol, men bu satrni tahrir qilishim kerak.
qo'shib qo'ydi muallif fluffels, manba
"Tasvirlarni o'z stoliga ajratib qo'ygan bo'lsangiz, bu juda oson o'zgarish." CDN bilan nima qilish kerak?
qo'shib qo'ydi muallif mkuse, manba
Mening fikrimcha, CDN-ga ko'chib o'tish sizning rasmingizni qaerda saqlayotganligingizdan qat'i nazar, oson o'zgaradi.
qo'shib qo'ydi muallif mkuse, manba

Munozara har ikki tarafida ham tegishli tashvish mavjud, shuning uchun doimo talab va cheklashlaringizni ko'rib chiqing. Qancha ma'lumotlar, qancha rasm, qanchalik katta, qanchalik xavfsiz, tiklanish vaqti?

Inline/BLOB xotirasi

Yuqorida

  • Versiya boshqaruvi/tranzaksiyaviy kelishuv. Bu asosiy semantik farq. Bu JB tomonidan yaxshi ko'rib chiqiladi, shuning uchun vaqtni tiklash imkonini beradi. Fayllar tizimida bunday imkoniyat yo'q, shuning uchun siz orqaga qaytish qobiliyatiga ega bo'lmaysiz. (Men fayl tizimini mustaqil deb hisoblamayman, men sizning kodingizdan tranzaktsiyalarni boshqarish muammosiga ishora qilaman). Tasvirlar va hujjatlarni foydalanuvchi xatosi yoki sinxronlash orqali buzish mumkin, bu 2 bosqichli majburiy muammo bo'lib qoladi. Ba'zi tizimlar tashqi nazorat tizimini qo'shish orqali buni hal qiladi, biroq integratsiyani talab qiladi.
  • Dasturni soddalashtiradi
  • Barcha ilova ma'lumotlari o'z-o'zidan yo'qoladi - Blob ma'lumotlarining izlari noto'g'ri bo'lmaguncha tizimning zaxiralash va qutqarilishini yoki ko'chishini osonlashtiradi; faqat bir dump, backup, export (JB lazzati uchun atama nima bo'lishidan qat'iy nazar) va yangi ma'lumotlar bazasiga ko'chiring. Sinxronlash uchun tashqi fayllar yo'q.
  • Havfsizlik/erkin foydalanishni boshqarish toza; rasmga kirish uchun BLOB ma'lumotlar qatoriga kirish uchun xosdir. Hujjat JB dan tashqarida bo'lsa va biz HTTP serverini (MVC ilovasidan tashqarida) olib chiqsak, uni bir vaqtda bajarish va o'lchash uchun yaxshiroq bo'lishi mumkin, lekin avtorizatsiyadan tashqi fayllarga qo'llanilishini ta'minlash uchun ko'proq ehtiyot bo'lish kerak, chunki ular DB ma'lumotlar. Katta hajmdagi fayllar saqlanadigan statik, ko'p satrli URL manzillari va dastlabki sinov stsenariysi ostida tasdiqlangan statik URL-ga to'g'ridan-to'g'ri kirishni tekshirishdan iboratdir. Agar siz uy-joy xavfsizligiga oid hujjatlarni JB dan tashqarida qilsangiz, ularni statik tarzda xizmat qilmang va sizning xavfsizlik siyosatingiz ijarachilar o'rtasidagi rasmlarning erkin foydalanishni nazorat qilishiga ishonch hosil qiling. Sizning HTTP serveringiz autentifikatsiyangiz umumiy tizimning autentifikatsiyasi bilan bog'lanishi kerak. Bu ko'p qavatli ma'lumotlar bazalarida katta tashvish. Oddiy autentifikatsiyalash bilan bitta maqsadli, yagona kiruvchi tizimlarda tashvishga tushmaslik.
  • Ma'lumotlar bazasi serverining sirt maydonini qisqartirish - Ko'p tizimlarda JB ilovalar serveridan ajralib turadi va ular orasida xavfsizlik devori mavjud. Har bir narsa bir misol sifatida bitta JB port (1433/MSSQL) yoki (1521/Oracle) xizmat qilishi mumkin. Fayllar bilan siz JB ni alohida darajaga ko'chirsangiz, siz NFS yoki NASdan foydalanmoqdasiz yoki fayllar miqdori kamaytirilganda siz yoki ilovalar serverida takrorlashingiz kerak.

Salbiy

  • Zaxiralash vaqti - Albatta, katta ma'lumotlar bazalari uchun (sizga tegishli emas), zaxira va tiklash asab solishi ham muammoli va qimmatga aylanadi; aks holda siz kichik yadroli ma'lumotlar majmuiga ega bo'lishingiz mumkin, sizda ko'p sonli GB yoki TB ma'lumoti bo'lishi mumkin. Hammani bir-biriga mos keladigan ma'lumotlar bazasi sifatida bir-biriga mos keladigan ma'lumotlar bazasi nuqtai nazaridan ham yaxshi, biroq korporativ darajadagi zaxiralash va tiklash (masalan, Oracle RMAN va rolling backups, EMC BCVs yoki Netapp Snapshots) yordamida DBMS-dan foydalanmasangiz, zaxira va qutqarish uchun yomon. Bir buyurtmachida bizning JB juda kengaydi, biz uni qo'llab-quvvatlashni to'xtatdik va geografik jihatdan keraksiz replikatsiyalarni bajardik. Boshqa yaxshi ma'lum bo'lgan narsa Starbucks edi (DBAs qog'ozni onlaynda joylashtirdi, agar siz shu bilan qiziqsangiz o'qiydi).
  • Vaqtni tiklash vaqti (a Recovery Recovery Time Objective yoki Recovery SLA) - bu sizning mijozingiz tomonidan tez-tez belgilanadi. Agar DBA sifatida mijozga allaqachon shunday deb e'lon qilgan bo'lsa, buni qaytarib olishingiz kerak. Xavfsiz bo'lmagan tasvirlarni saqlash uchun ma'lumotlar bazasi hajmiga 90% qo'shsangiz, muhim ma'lumotlarning tiklash SLAga ta'sir qiladi, keyin buni qilmang.
  • Kamroq moslashuvchanlik. OS darajasidagi yordam dasturlari, qobiq komandalari va boshqalar bilan hujjatga kirish oson emas.

Shaxsan, bu jihatdan, tarozilar Inline DB xotira foydasiga to'plangan deb o'ylayman. JB katta bo'lmasa, ularni JBga saqlang.

4
qo'shib qo'ydi
Fayl tizimi versiyasi uchun siz zfs-ni qidirmoqchi bo'lishingiz yoki go'nada ham navning fayl formati deb qarashingiz mumkin.
qo'shib qo'ydi muallif user40980, manba
@MichaelT Albatta, ularning barchasi haqida bilaman va VxFS/VxLVM kabi boshqa variantlar orasida ham foydalanganman. Ular haqiqiy foyda keltiradi. Biroq, ular hali ham DBdan tashqarida. Agar siz umumiy tranzaksiya barqarorligi va tekshirishni nazorat qilishni xohlasangiz, ularni birlashtirishingiz kerak. Ma'lumotlar bazasi tranzaktsiyasi bilan sinxronlashtirishda uni saqlash 2 bosqichli majburiy muammo hisoblanadi. Boshqacha aytganda, ZFSni umumiy ma'lumotlar bazasi tranzaktsiyangizning bir qismi sifatida "topshirish yoki qaytarib olish" oson emas.
qo'shib qo'ydi muallif Sebastian, manba

Ma'lumotlar bazasidagi rasmlarni saqlashni maslahat beraman.

Ma'lumotlar bazasi nima uchun mo'ljallanmagan - bu boshqa ma'lumotlarga tegishli relatsion ma'lumotlar emas. U osongina katta hajmdagi maydonni egallaydi va ma'lumotlar bazasi bloklari ustunida manipulyatsiya qilish qiyin.

I use databases to store the name, timestamps, meta data and file location. I then store and access the image at that file location/name

Men bir necha yil avval haqiqiy dunyoda va boshqa ko'plab kishilar bilan birgalikda, ma'lumotlar bazasida tasvirni saqlab qolish noto'g'ri yondashuv degan xulosaga keldim. Versiyalarni yaratish va tarix uchun faqat kodni manba tekshirishda ishlatish kerak va ularni boshqalar bilan boshqarishingiz mumkin. Shunday qilib, har bir rasm uchun nomni o'zgartiring, tarix tamg'alarini ishlating va boshqa rasm uchun aynan bir xil fayl nomini qayta ishlatmang.

Bu vaqt ichida boshlangan ko'plab odamlar o'zlarining ma'lumotlar bazasi barcha tasvirlar tufayli juda ko'p o'sib ulgurganligi sababli kalitni biroz vaqtdan keyinga qoldirish kerak. Bu saqlash ehtiyojlariga, serverlarga, CPU va ehtimol tarmoq trafigiga qattiq ta'sir ko'rsatadi. Bundan tashqari, geografik joylashuvni, transportni va shunga o'xshashlarni hisobga oladigan bulutli fayl tizimini saqlashni qiyinlashtiradi. Ushbu metodikalar sizning kompaniyangiz o'sib borayotgani va ma'lumotlar bazasidagi tasvirlarni tanlashingizning cheklanishiga olib kelishi mumkin.

In conclusion, good for small projects with small amount of image data. Not suitable for larger shops or larger amounts of data.

3
qo'shib qo'ydi

Agar siz SQL serverini (2008 yoki undan keyingi versiya) foydalanayotgan bo'lsangiz, ularni ma'lumotlar bazasida blob yoki FILESTREAM sifatida saqlashingiz mumkin. Boshqa sharhlovchilar ta'kidlaganidek, faylni diskdagi yondashuvga mos ravishda saqlamoqchi emasman, chunki siz ushbu stsenariy bo'yicha kelishuvni boshqarishingiz kerak bo'ladi.

FILESTREAM-da yaxshi havola bu erda topishingiz mumkin:

FileStream yo'riqnomalari >

Ba'zi umumiy qoidalar:

SQL Serverda BLOBs saqlaydigan standart varbinary (max) ma'lumotlar bo'lishi mumkin   jadvaldagi ma'lumotlar yoki FILESTREAM varbinary (max) ob'ektlarini saqlaydi   fayl tizimidagi ma'lumotlar. Ma'lumotlarning o'lchami va ishlatilishi aniqlanadi   ma'lumotlar bazasini saqlash yoki fayl tizimi xotirasidan foydalanish kerakmi? Shunday qilib, ichida   qisqacha qisqacha aytganda, bu xususiyat eng yaxshi bo'lgan odatda senaryolardır   mos keladi:

     
      
  • BLOB-larni 1MB yoki o'rtacha kattalikda saqlayotgan bo'lsangiz   Ko'proq.
  •   
  • Tez o'qishga kirish qat'iydir.
  •   
  • Sizning ilovangizning o'rta darajali kodidan BLOB'larga kirishingiz kerak.
  •   
     

Umuman, FILESTREAMni boshqa imkoniyatlardan foydalanishning asosiy afzalliklari:

     
      
  • BLOB-larni saqlash va olish birlashtirilgan ma'lumotlar bilan birgalikda amalga oshiriladi   ma'lumotlar bazasi.
  •   
  • Ha, BLOB-lar ma'lumotlar bazasi zahiralariga qo'shilib, qayta tiklanadi.
  •   
  • BLOB'lar va aloqador ma'lumotlaringizni qo'shish, yangilash va o'chirish bir xil ma'lumotlar bazasi jarayonida amalga oshiriladi.
  •   
  • Bir varbinary (maksimal) ustun uchun 2 GB maksimal hajmi qo'llanilmaydi; faqat siz NTFS fayl tizimidagi bo'sh joy bilan cheklangansiz.
  •   
  • SQL Server tampon pulining xotirasi BLOB-larda ishlash uchun foydalanilmaydi; oldingi versiyalarda katta BLOBlar bu xotirani ko'p iste'mol qilishi mumkin edi.
  •   
  • Barcha BLOB kirish .NET kodidan bajarilishi mumkin, bu sizning o'rta darajali kodingiz ushbu ob'ektlar bilan osongina ishlashga imkon beradi.
  •   
  • NTFS fayl tizimi, katta BLOB'ları SQL Serverga nisbatan yanada samarali tarzda saqlashi va olishlari mumkin.
  •   
     

Shunday bo'lsa-da, FILESTREAM ilovalariga bir nechta cheklovlar qo'llaniladi:

     
      
  • FILESTREAM xususiyati bazasi aks ettirish bilan qo'llab-quvvatlanmaydi.
  •   
  • FILESTREAM ma'lumotlar konteynerlari bir xil katalogni ulashmaydi yoki ichki o'tadi.
  •   
  • Shaffof ma'lumotlar shifrlash (TDE) yoqilgan bo'lsa ham, FILESTREAM ma'lumotlari shifrlangan emas.
  •   
2
qo'shib qo'ydi