Отворен дебат за запазване на изображения


3

Здравейте колеги, тъй като смятам че и на други би било полезно и току що гледах един такъв дебат в stackoverflow , бих искал да отворя тази тема и тук и да направим един отворен дебат, като се надявам и лекторите ни да се включат.

Аз лично знам, че не е хубаво ако има много снимки да се запазват в база данни, а на файловата система, но пък лично предпочитам в базата, защото се разправя с колизии и има някакви constraints, мога да си resize-na снимката, да си търся бързо по индекс, не се разправям с колизии. Варианта за мен ако не е в базата, а в файловата система, е да се пази някакъв path в базата, но какво става ако този path се промени или някой затрие снимка и съм прецакан.

И така ако приложението ходи някъде то е вързано за папка в файловата система и да кажем да са едни 30-40 GB снимки, винаги ще ги повлича със себе си. Нали тук си говорим за количество снимки, и то не оразмерени с висока резолюция примерно 3000 х 1400. 

Това е моят кейс и се чудя как би било по - добре да го играя след като ги имам по папки имат си и някакво ID, за да няма колизии. До сега не съм се сблъсквал с такова количество изображения и нямам опита да преценя кое е по - добре или не. След ресърч реших да пусна темата тук с идеята да си помогна на себе си, да стане интересен дебат и да е полезно и за други ако им се случи да работят с голямо количество снимки. 

ПС: Ще се използват в MVC Web Application

РЕЗУЛТАТ : Общо гласове до момента 3

База

Файлова система

База и файлова за cache

Зависи

3
2
1
2



Отговори



1

Много зависи за какво ще ги ползваш снимките. Ако снимките са основното в твоето приложение и са супер важни е много по-добре да ги пазиш в база, защото там по-лесно може да си правиш бекъп. А пък ако снимките са някакви, които не са толкова важни примерно аватари на потребители или некви иконки ако слагаш някъде може да си ги пазиш на файловата система, щото и да се загубят, ще си качат нови аватари хората, ако това не е от голямо значение за приложението. Аз поне така бих направил нещата.

Ще се радвам да чуя други мнения :)

Поздрави!


от sa66eto (1945 точки)


0

Благодаря за мнението sa66eto, ако не е проблем мога ли да попитам какъв опит имаш с снимки и приложение които ги използва? Аз също подкрепям базата като storage. Ставаме 2 / 0 за базата към момента и ще постна score в main post- a. 

Нека си представим, че ситуацията е следната. 30000 снимки, които растат експоненциално с времето, важни са и с тях са формирани някакви статии, които хората четат. Ще се прехвърлят по мрежата и в всяка статия примерно има 10000 статии и всяка има по 3 снимки. Ще има caching, и се гони performance. До сега където съм правил някакви неща винаги съм ги пазил в базата и съм си ги оразмерявал преди да ги сложа вътре, но никога не съм работил с супер много снимки. Радвам се, че има хора на които им е интересно, защото темата е леко абстрактна и перфектна за открит дебат. Ще се радвам да чуя мнението и на останалите колеги :)


от a.sideriss (450 точки)

1
Амии правил съм разни неща и общо взето работя по начина, по който ти казах. Не знам дали ме разбра, но исках да кажа, че нито едното е по-добро от другото. Идеята е, че зависи, зависи от това за какво ще ползваш снимките. Примерно фейсбук предполагам, че си пазят снимките в базата, няма как да съм сигурен, но според мен, когато снимките са важни за приложението е хубаво да им се прави бекъп, което става супер лесно в базата. През файловата система по-трудно. Надявам се да съм помогнал и да си ми разбрал идеята :)

от sa66eto (1945 точки)


1
Поздравления за темата, на мен също ми е интересна.

Абсолютно съм съгласна с @sa66eto, не веднъж са ни го казвали по лекции. Винаги зависи от ситуацията - може снимките да не са основното в приложението, но да са много (примерно 10 000) и да се въвеждат на ръка от администратора. Аз и тук гласувам за база.

Пример за използване на база + файлова за един и същ ресурс е приложение за споделяне на професионални фотографии (последната отборна, в която участвах, сходен проблем с този от примера ти под отговора на @sa66eto).
Важни са ти снимките определено, то друго освен снимки няма, но пък не можеш да си позволиш да размяташ насам натам едни GB снимки, най-малкото защото ще изгърмиш с OutOfMemory  в момента, в който искаш да листнеш цяла галерия. В базата пазихме оригиналното изображение и пътища до файловата, където пазим преоразмерени изображения с намалено качество. Оригиналното изображение дърпаме само ако потребителя иска да види изображението детайлно, във всички останали случаи - преоразмерени изображения за съответните дивчета.

Поздрави!
 



0

Благодаря за отговора Мария.

Имам въпрос. Така не се ли couple- ваш мега ямо с някакъв път в файловата система където ако смениш път или име на файл гърмиш супер здраво и ако го е направил някой друг и ти не знаеш има да се нервираш допълнително. Тъй като сте пазили оригиналите в базата какъв е проблема да се дърпат по ID примерно и в моя случай аз мисля да ги пазя преоразмерени на макс 800 px largest side в базата. Вие колко снимки сте имали в тази система за професионални фотографии? Толкова ли е по - бързо в файловата система. Аз знам че операциите с файлове by default са бавни. Защо някои хора избягват базата за такъв тип файлове при положение, че търси супер бързо

ППС: Най вероятно ще имат категории и ще се дърпат по категория или в времеви период ако искам да използвам вече качена снимка

ПС: Ще се радвам да споделиш още неща за тази система, със сигурност има какво да науча за това.

Поздрави.


от a.sideriss (450 точки)

0
@a.sideriss - Първо пътя до снимките най-вероятно ще ти е изнесен в някаква константа, тоест ако преместиш папката или т.н ще ти е много по-лесно да промениш тая константа. Второ, предполагам снимките като се запазват ще им се създават имена по някакъв алгоритъм, дали ще е GUID или пък ще си измисляш собствен начин да ги записваш, това си е твое решение. Вече като трябва да запазваш снимката ще запазиш само нейното име, а самия път ще го join-ваш към името като дърпаш снимката, той ще ти е изнесен в константа, тоест ако местиш снимките само променяш пътя и заспива. Вече ако искаш да ги преименуваш, което не знам в какъв случай ще ти трябва, не знам трябва някак да ги populate-неш в базата наново :)

от sa66eto (1945 точки)



0

Принципно според мен това е някакъв междинен вариант и се прави един бутон, който ги хваща от базата и ги нахаква в файловата система, което играе ролята на Cache и после ги дърпа от там, но не мога да разбера след като операциите с статични файлове са супер бавни, как може снимките от базата да са по бавни при положение, че работи с дебееели алгоритми и работи суупер бързо за всичко останало ?


от a.sideriss (450 точки)


2

Интересен казус. Като цяло имаш доста неща, който е хубаво да вземеш в предвид.

1. Хардуерно как седят нещата? Базата ти на HDD или на SSD е? Ако е на SSD и решиш да съхраняваш изображенията си в базата - ще ти излезе по-скъпо. Ако базата ти е на HDD, това не би трябвало да е голям критерии.
2. Каква е архитектурата на самото ти приложение? Ще се намира само на един сървър или?
3. Имай в предвид, че когато базата ти стане 40Gb+, не е фън да я копираш на локалната си машина за development :D (Има много начини да се заобиколи това, но пак - много зависи, какъв ще е целия development процес).
4. Запазване на изображения в базата данни и операциите с тях може да са по-бавни отколкото ако директно достъпваш файловата система.

5. Какъв вид база данни ще ползваш?


от Teodor92 (13062 точки)


0
Да, смятам че си прав за SSD ще се счупи бързо. И мисля че е филм примерно ако е cloud based хостинг с репликирането от load-balancer ако са на файловата. Знам че като е само база си се оправя сам. Със сигурност не е много фън 40GB база пълна с снимки. Как става номера ако искам да вкарам някакъв load balancer и примерно след време реша, че мога да го хостна на няколко сървъра и на двата трябва да имам локално всички снимки с пътищата до тях нали :D .. Ти какво мислиш за варианта за storage в базата и да мога да си specify directory и да го играя все едно на cache и така базата винаги ще има снимките и няма да depend- ва на файловата тъй като само ще си ги генерира като и потрябват? MS SQL Database, а за хостинг си мисля нещо от сорта на суперхостинг за българия, знам че provide- ват виртуалки някакви не съм много запознат. During dev e v AppHarbor, но не съм наливал база. То и без това там free базата ако не се лъжа е 20 мб :D 

от a.sideriss (450 точки)


1

Трябва да помислиш и къде ще се хоства приложението, защото при някои варианти по-голяма база струва повече пари от дисково пространство или ти е ограничена до няколко GB.

Разбира се ако си голяма фирма с голям сървърен ресурс това не е на дневен ред и може да се ползва варианта оригиналите в базата и cache с оразмерени варианти на диска.


от deyan.todorov (1019 точки)


3

Аз съм на мнение, че подхода да пазиш физическия път в базата, а самият ресурс на файловата система е най-добър от към бързодействие и щадене на базата. Често чувам да казват, че ако ти е много важно изображението е хубаво да го пазиш в базата, защото на нея се правят редовно backup-и, но това за мен е невалиден аргумент, защото големите хостинг провайдъри ежедневно правят backup на databаse и hardrive storage-а, и то на повече от 1 място, за да се предотврати загуба на информация при изгаряне на диск или друга повреда.

Проблемът който Алексис отбеляза, че при смяна на физическото място на сървъра, се променят тотално пътищата които си съхранил в базата - така е, но с един семпъл скрипт можеш да минеш през всички редове в базата и да си изчислиш нов път.

За пазене на оригинален и намален размер, пазиш 2 колони в таблицата, които сочат къде е местоположението на 2-те изображения и толкова.

Това разбира се е лично мое мнение изградено върху наблюдения и споделяне опита на мои познати които поддържат по-дебели системи и не го налагам на никой.


от INKolev (4141 точки)


2

В най-общия случай, ми се струва, че подходът, който е в студентската система е доста точен.

По това, което си спомням, че Ники каза в една от лекциите, са го направили така:
Снимките от кандидатурите (заедно със CV, cover letter, допълнителни документи) се пазят в базата данни за по-лесен backup и restore, пък и са доста важна информация, която се зарежда рядко.
Аватарите са от файловата система. Това лесно се забелязва от линка (папката Content): http://telerikacademy.com/Content/Avatars/040/19040_565ba330_180x180.jpg (аватарът на dentia, :Д)
Раязделят се по папки (/040/ в линка горе), за да се спести наличието на много файлове в обща папка, което може да забави файловата система. Другото, на което трябва да се обърне внимание, е хеша в адреса(565ба330), който предпазва от това да минем с един скрипт и да си свалим всички снимки.
Файловете от домашните и изпитите също се пазят на файловата система. :)


от dentia (12519 точки)


0
Благодаря Dentia, в случая не разбрах за коя опция Vote- ваш, защото каза че важните неща в базата а аватарите, които могат да се сменят на харда, но в случая и снимките към статиите са важни защото изграждат цялостната статия. Смяташ ли както колегата Теодор Куртев каза, че ако е на обикновен хард диск е оферта да са в базата и какво мислиш за някакъв workaround с това да се пазят и в база за BackUp, която да си прави Cache в файловата и да ги реферира от там. Може и да е отделна някаква само за това. Наистина ли файловата система го играе по бързо от базата в случая на обикновен хард? Аз смятам да изтествам performance със сигурност да видя за какво иде реч, защото е някакво супер спорно и ми е доста интересно 

от a.sideriss (450 точки)


4

Няколко наблюдения от мен:

  • Базата също се пази на файловата система. Гигабайтите винаги ще си ги има.
  • Базата ще бъде по-натоварена ако постоянно трябва да се вадят снимки от нея. Също търсеното из повече информация е по-бавно.
  • Статични файлове могат да се serve-ват асинхронно и вашия сървър само да дава пътя.
  • Ако снимките са отделни файлове може да се прави incremental backup.
  • Да предположим, че се появи bad sector на харддиска или file system corruption: поне един файл си отива. Кое е по-добре, една база или една снимка?

от cuki (7696 точки)


0
+1 За споменаване на incremental backup-a и паралелното обслужване.

от INKolev (4141 точки)