Захаванне карыстацкіх загружаных файлаў на вэб-сэрвэры

Я працую на вэб-сайце, які дазваляе карыстальнікам загружаць файлы (фатаграфіі і ў адваротным выпадку). У мяне няма якога-небудзь вопыту ў гэтай галіне, і ў надзеі атрымаць некаторыя ўваходны сігнал на правільным шляху, каб захоўваць і індэксаваць гэтыя файлы.

У той час як я хацеў бы мець архітэктуру, якая добра маштабуецца да дадзеных вялікага аб'ёму, я ў цяперашні час не турбавацца пра надзвычай высокіх (facebook-, Google маштаб) аб'ёмах.

Я думаў пра захоўванне файлаў у файлавай сістэме ў

/files/{username}/

А затым з базы дадзеных Загрузка , дзе кожны карыстальнік мае сваю ўласную табліцу з імёнамі файлаў (і, такім чынам URL) кожнага файла ён загружаны (і любы іншы дадатковай інфармацыі, якую я мог бы хацець захоўваць). Канчатковым база гэтага (даючы кожнаму карыстальніку свой уласны стол) здаецца вельмі неэфектыўным мне яшчэ захоўваючы запісы ўсіх файлаў у адной табліцы не здаецца правільным, а так як гэта запатрабуе пошук па ўсёй табліцы кожны раз, калі адзін файл доступ.

Мае развагі ззаду разглядае магчымасць прадастаўлення кожнаму карыстальніку свой уласны стол быў, што гэта акуратны і выдатны спосаб Шардэн дадзеныя па некалькіх табліцах і скараціць час пошуку пры пошуку файла, названага карыстальнікам.

7

2 адказы

Гэта залежыць ад прыроды і структуры вашага прыкладання і баз дадзеных. Я выкарыстаў шмат метадаў, у тым ліку на аснове тэчак, малюнкаў, захоўваемых у базе дадзеных BLOB, па-за Інтэрнэту тэчкі з файламі, доступ праз шлюз аўтэнтыфікацыі ...

Для знешніх малюнкаў, якія непасрэдна не звязаныя з дадаткам або базы дадзеных, як фатаграфіі тэмпературных ці нешта, я, як правіла, укладваць іх у тэчцы. Так як здаецца, як ваша структура карціны ад карыстальніка, то я б чакаць, што можа быць метададзеныя, звязаныя з выявай, такія як тэгі. У гэтым выпадку, я б, верагодна, захаваць малюнак у табліцы базы дадзеных, мяркуючы, што ў мяне быў патэнцыял для гэтага. Калі фатаграфіі неабходна быць забяспечанымі, недаступным іншымі карыстальнікамі без аўтэнтыфікацыі, то база дадзеных будзе мець сваю ўласную бяспеку, у той час як для захоўвання файлаў на аснове спатрэбіцца нейкі трук, каб прадухіліць несанкцыянаваны доступ.

Я б не выкарыстоўваць табліцы для кожнага карыстальніка, проста табліцы карцінкі з элементамі ID, ідэнтыфікатар карыстальніка, малюнак згустку.

Ці дапамагае гэта?

3
дададзена
Гэта сапраўды дапамагае. Тым не менш, ёсць некалькі пытанняў. У цяперашні час мы выкарыстоўваем агульны вэб-сервер, які абмяжоўвае нас на 1 Гб у базу дадзеных, такім чынам, захоўванні фатаграфій/файлы ў якасці згустку ў самой базе дадзеных не будуць магчымымі. Акрамя таго, не будуць мець усе здымкі ў адной табліцы павялічыць час пошуку для канкрэтнага малюнка? Мае развагі за сталом для кожнага карыстальніка ў тым, што, ведаючы карыстальніка, я б ведаў, якая табліца для пошуку і, такім чынам, прыйдзецца шукаць праз меншыя запісу (думаю пра яго, як сегментаванне на аснове ідэнтыфікатара карыстальніка). Хіба гэта не мае сэнсу? Ці ёсць што-то я не хапае?
дададзена аўтар xbonez, крыніца
Памер індэкса ўплывае на выкананне SQL, але вялікі набор не-індэксаваная згусткі не будзе прыкметна. Але гэта спрэчнае пытанне, калі ў вас няма месца. У гэтым выпадку вам неабходна захоўваць іх у файлавай сістэме. Структура USERID/фатаграфіі тэчкі ў парадку, калі вы будзеце мець шмат з іх, як і пазбегнуць вялікага FileCount ў адной тэчцы з'яўляецца добрай практыкай. Я б паставіў .htaccess на месцы, каб пазбегнуць прамой доступу (пры ўмове, што вам патрэбна аўтарызацыя доступу да іх), а таксама выкарыстоўваць фатаграфію? ID = усе, што змяняе загалоўкі ў малюнкі JPEG/або любы іншы, і рэха ReadFile гэтага малюнка.
дададзена аўтар Matt H, крыніца

Што Matt H прапанаваў гэта добрая ідэя, калі што вы спрабуеце дасягнуць, гэта на аднаго карыстальніка ўзроўню доступу малюнка. Але належнае, што вы абмежаваныя ў вашай базе дадзеных захоўваюцца прасторы, захавання малюнкаў у двайковых дадзеных неэфектыўна, як вы заявілі.

Выкарыстанне табліцы для кожнага карыстальніка з'яўляецца дрэнным дызайнам. Карыстальнік, які загрузіў файл павінен быць проста поле/слупок ў табліцы, у якой захоўваюцца ўсе загружаныя файлы, нароўні з любой файл метададзеных. Я прапаную генерацыі GUID для імя файла, які гарантавана будзе унікальным, і лепш, чым поле автоинкремент, які лёгка адгадаць, калі вы спрабуеце забараніць карыстальнікам доступ проста ўсе выявы.

Вы турбуецеся аб прадукцыйнасці, але пакуль вы не маеце справу з мільёнамі на мільёны запісаў, вашыя запыты для выбару выявы належаць карыстачу, загружаны ў працягу пэўнага перыяду часу (скажам вы захоўваеце змяняць час ці аналагічны), з'яўляюцца нязначнымі ў кошту. Калі хуткасць з'яўляецца праблемай, вы можаце дадаць індэкс B-дрэва на імя карыстальніка, якое будзе паскорыць вашыя канкрэтныя карыстацкія запыты малюнка значна.

Назад на тэму бяспекі, доступу і арганізацыі. Захоўвайце выявы ў тэчцы для кожнага карыстальніка (хоць у залежнасці ад колькасці карыстальнікаў, колькасць тэчак можа вырасці да некіраванага ўзроўня). Калі вы не хочаце малюнка быць агульнадаступнымі, захоўваць іх у не-вэб-тэчкі, каб ваша прыкладанне счытвае дадзеныя і струмень яго візуалізацыі малюнка для карыстальніка. Больш складаны, але схаваць фактычны файл з Інтэрнэту. Акрамя таго, вы маглі б праверыць усе запыты на малюнак прайшла праверкі сапраўднасці карыстальніка.

3
дададзена