Много файлове в една директория

[tedy]

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

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

Обаче да пъхна 10-20 хил. файла, да не говорим за 100-200 хиляди или 1,000,000, в една директория, си е харакири, та номерът е избирането на файла от ОС да е кратко, т.е. като имам името, да го намира бързо във файловата си система. Елегантен начин да разхвърлям файловете по много директории съм намерил (всъщност един приятел ми го подсказа и се оказа доста прост начин), като тука вече стои дилемата:

Брой директории vs. Брой файлове в директория.

Директориите няма да са в едно ниво всичките, а в йерархия с по Х максимален брой файлове в директория.

 

Приложението ще работи най-вероятно под Linux хостинг, та да питам знаещите, колко е максималният брой файлове в една директория, с който Линуx ext2/3 или с която работят сървърите, може да се справи без проблем?

 

Мисля по 100 или 1000 файла да ръгам, но ако има възможност и по повече или пък най-ефективно е по по-малко, ще се радвам ако някой има експертно или от опит мнение.

Благодаря предварително.

[Godfather]

Теоретичният лимит на ext3 файловата система е някъде към 130 милиона файла (и ако не се лъжа 32000 поддиректории) в една директрория. Нямаш никакви проблеми с 1000 файла в една директория. Само трябва да имаш в предвид, че за 1000 фаила отиват някъде към 4MB, а ако са директории - двойно повече и да си направиш сметка за тотала памет, която ще ти трябва за подобна структура. Това трябва да е съобразено с количеството RAM, за да може да използваш ефективно кеширането на файловата ситема. Естествено, винаги е добре да имаш йерархия, която да допринася максимално за бързото претърсване на цялата структура.

[karaman]

не забравяйте и inodes

[notor1ous]

Обаче да пъхна 10-20 хил. файла, да не говорим за 100-200 хиляди или 1,000,000, в една директория, си е харакири, та номерът е избирането на файла от ОС да е кратко, т.е. като имам името, да го намира бързо във файловата си система. Елегантен начин да разхвърлям файловете по много директории съм намерил (всъщност един приятел ми го подсказа и се оказа доста прост начин), като тука вече стои дилемата:

Брой директории vs. Брой файлове в директория.

Директориите няма да са в едно ниво всичките, а в йерархия с по Х максимален брой файлове в директория.

Определено прилятеля ти е дал добра идея. Иначе ще е много трудна подръжката. В Linux директориите представляват вид специализан файл.

Като качваш снимките не забравя в скрипта да сложиш и код за промяна на правата за достъп, четене и запис на всеки файл. Аз съм имал такъв проблем на РНР - РНР се изпълнява през някакъв юзър (името може да е nobody, daemon и т.н.), скрипта качва файловете и после тези файлове могат да се манипулират само от root или от юзъра, с който са качени. Не съм много сигурен това с този юзър дали беше особенност на apache или на PHP, направено е заради общата сигурност на сървъра, но при качване на файлове може да създаде проблеми, ако нямаш root парола. Най-добре им слагай права 0755, освен ако не искаш да има някой по спечифични ограницения.

[tedy]

Мерси на всички за разясненията.

В крайна сметка ще са по 1000 в директория и като файловете ще са в последното ниво с общо 3 нива, т.е. заедно с файловете няма да има и директории.

Що се отнася до изчисляването на нужното пространство, то е на втори план, защото не може да кажеш на юзъра Не качвай сега щото няма място на сървъра . Ще се ограничат размерите на картинките просто, чрез resize при качването, с което и юзърът няма да е насилван да си обрбаотва картинката предварително.

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

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

[notor1ous]

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

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

Права винаги се сетват, въпроса е че по подразбиране са доста ограничени. През FTP дори и да нямаш проблеми, през SSH ще имаш ядове, ако нямаш root парола.

А това за съхранение на картинки или каквито и да е други файлове като бинарна информация в базата е лудост! В базата трябва да направих един вид хеш референция към файла, т.е. да има таблица за фаиловете и от нея да изчисвяваш ключ чрез който еднодначно да се посочва файла.

[tedy]

Права винаги се сетват, въпроса е че по подразбиране са доста ограничени. През FTP дори и да нямаш проблеми, през SSH ще имаш ядове, ако нямаш root парола.

А това за съхранение на картинки или каквито и да е други файлове като бинарна информация в базата е лудост! В базата трябва да направих един вид хеш референция към файла, т.е. да има таблица за фаиловете и от нея да изчисвяваш ключ чрез който еднодначно да се посочва файла.

Досега никога не съм сетвал права на качени файлове, просто защото не се е налагало, и не съм имал проблеми нито през PHP, нито през FTP. За един-два проекта съм имал достъп и през SFTP, но SSH не . И без това не разбирам от комаден ред на Lainux, SSH никога не бих ползвал, и не ми се е налагало so far.

Имам си таблица за файловете разбира се, но никакви хешове не пазя в базата, от които да изчислявам имена, а просто се ползва основното IDENTITY id поле (тук се нарича auto_increment де), от което се получава и пътя и името на файла.

[notor1ous]

Досега никога не съм сетвал права на качени файлове, просто защото не се е налагало, и не съм имал проблеми нито през PHP, нито през FTP. За един-два проекта съм имал достъп и през SFTP, но SSH не . И без това не разбирам от комаден ред на Lainux, SSH никога не бих ползвал, и не ми се е налагало so far.

Имам си таблица за файловете разбира се, но никакви хешове не пазя в базата, от които да изчислявам имена, а просто се ползва основното IDENTITY id поле (тук се нарича auto_increment де), от което се получава и пътя и името на файла.

Ако полето, което е auto_increment представлява PRIMARY KEY или UNIQUE, то неговата стойност е хеш Не е задължително алгоритъмът за хеширане да е с кой знае каква сложност, за да е хеширане

 

За SSH въобще не съм съгласен. Не може да се сравнява FTP достъпа с SSH. Има много хватки, който Linux позволява, за разлика от други ОС, които могат да подобрят приложението (дори елементарен web сайт) и да го направят по-сигурно без да се налага да се пишат специални скриптове. Не случайно има такава разлика в цените на хостингите с SSH достъп и тези, само с FTP.

[tedy]

Ако полето, което е auto_increment представлява PRIMARY KEY или UNIQUE, то неговата стойност е хеш Не е задължително алгоритъмът за хеширане да е с кой знае каква сложност, за да е хеширане

 

За SSH въобще не съм съгласен. Не може да се сравнява FTP достъпа с SSH. Има много хватки, който Linux позволява, за разлика от други ОС, които могат да подобрят приложението (дори елементарен web сайт) и да го направят по-сигурно без да се налага да се пишат специални скриптове. Не случайно има такава разлика в цените на хостингите с SSH достъп и тези, само с FTP.

Да, зависи от гледната точка относо кое може да се нарече hash. Строго погледнато PRIMARY IDENTITY поле не е hash, понеже то не произлиза от от някакъв стринг чрез алгоритъм, или message digest.

Това е просто поле, което се увеличава с единица или с колкото е зададено при дефиницията на полето.

И да, алгоритъмът хич не е сложен по получаването на имената на дир+файла .

 

За SSH - Windows си има remote desktop, който си ползвам от време на време с един хостинг в USA, и също позволява да правя каквото си искам без да е нужно да пиша като луд в промпт . Да не говорим че в това отношение и Windows си има инструменти като слънце, не само RD.

Така е, много неща могат да се направят ако имаш достъп до машината, но както сам каза, по-скъпи са тези хостинги с SSH/RD, за по-малки проекти е излишно да се дават такива пари, а и приложението е добре да се прави да работи Ок на повече хостинги без винаги да се налага да се пипа през SSH. Бидейки под Windows, първо гледам да работи под него, чак след това се тревожа за Linux , макар че тва беше шега, не обичам да завися само от линукс или Вин, що се отнася до PHP, а вече другите неща са си само за Windows така или иначе. Не ползвам Linux почти, за да се тревожа за Linux-only приложения, или такива, зависещи от Apache за да работят (да ме пази Бог от Апаче, амин!)

[notor1ous]

Да, зависи от гледната точка относо кое може да се нарече hash. Строго погледнато PRIMARY IDENTITY поле не е hash, понеже то не произлиза от от някакъв стринг чрез алгоритъм, или message digest.

Това е просто поле, което се увеличава с единица или с колкото е зададено при дефиницията на полето.

И да, алгоритъмът хич не е сложен по получаването на имената на дир+файла .

PRIMARY KEY e уникален ключ, който е и индекс на таблицата. auto_increment и primary key са различни неща, които могат и в повечето случай се използват заедно за една и съща колона. Имах предвид, че чрез него се изчислява стринга за името на файла, което си е вид елементарно хеширане.

А за windows хостингите - win на мен не ми изглежда като "сериозна" ОС за сървър, не че е лоша, но до е далеч от Linux приложенията и е доста скъпо решение. До преди Vista win нямаше дори символни линкове. А това за remote desktop, ако искаш да ползваш графичната среда не е проблем и за Linux. Ако не използваш графичната среда на win пак ще има много писане Все пак не случайно почти всички големи фирми, който предлагат непрекъснати услуги в областта на телекомуникацията и/или ИТ ползват UNIX базирани ОС.

ЗА платформената независимост съм съгласен в генерален план, ако се предоставя изпълними файлове на клиента, но при web приложениеята за мен е важно да вървят еднакво добре на всички Unix базирани ОС. Аз пиша на РНР и досега не съм слагал нещо, освен за тестване на машина с win ОС. Езици като PHP и PERL са си наследствено обременени и свързани с UNIX базираните ОС.

[tedy]

PRIMARY KEY e уникален ключ, който е и индекс на таблицата. auto_increment и primary key са различни неща, които могат и в повечето случай се използват заедно за една и съща колона. Имах предвид, че чрез него се изчислява стринга за името на файла, което си е вид елементарно хеширане.

Абсолютно, различни неща са двете понятия, аз затова ги споменах като едно в комбинация - PRIMARY IDENTITY (auto_increment), приликата между хеш и случая е че и двете се използват за пособни цели, тук малко издребняхме наистина .

А за windows хостингите - win на мен не ми изглежда като "сериозна" ОС за сървър, не че е лоша, но до е далеч от Linux приложенията и е доста скъпо решение. ... Все пак не случайно почти всички големи фирми, който предлагат непрекъснати услуги в областта на телекомуникацията и/или ИТ ползват UNIX базирани ОС.

Ако става дума за ХР да, но не и за Windows Server 2003. За справка Netcraft, където в Top10 на най-надеждните сървъри има 2 пъти Win2003 и само 3 пъти Линукс (който уж владее много повече от пазара), останалите Соларис, фрееБСД и т.н. Т.е. Win Server не отстъпва по нищо на конкурентите . (Трябваше малко флейм да има) .

Все трябва да има някаква причина въпросния хостинг, в който 'бъркам' от време на време, да разчита на Win2003 Standard+MS SQL+CF. Между другото намира се в Тексас, един от големите хостинг центрове.

ЗА платформената независимост съм съгласен в генерален план, ако се предоставя изпълними файлове на клиента, но при web приложениеята за мен е важно да вървят еднакво добре на всички Unix базирани ОС. Аз пиша на РНР и досега не съм слагал нещо, освен за тестване на машина с win ОС. Езици като PHP и PERL са си наследствено обременени и свързани с UNIX базираните ОС.

Така е, и аз не съм слагал нещо на Win хостинг досега (на PHP писано де), и за мен е важно да работят на линукс ОС независимо от дистрибуцията, доколкото е възможно с PHP. Гледам да се ползват по възможност само платформено независими функции, или wrappers като включвам задължително поддръжка на Windows (очевидно защо ).

Но факт е, че PHP под Windows е също толкова стабилно и добро както и под Линукс, даже под Вин май работи по-добре (шегичка бе Уили). Наистина, PHP под IIS си работи супер добре, даже има професионални хостинги с IIS, които освен .NET 2.0, предлагат и PHP като бонус.

Що се отнася до .NET/C#/MS SQL Server, във всяко отношение технологиите са по-добри от PHP, недостаътка е че са Windows-обвързани, което обаче е предимство от други гледни точки .

За жалост PHP е завлядял масовите по-малки проекти, и интерес към .NET няма у нас, освен при по-големите и сериозни проекти, за които .NET предлага много повече от PHP.

Понеже ми се случва и ColdFusion да ползвам, него го има и за Линукс доколкото знам, но него не го уважавам като език, не ми допада и това е. Май е по-разпространен в USA. И под Win се чувства като у дома си, в USA май има много такива хостинги.

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

[Godfather]

...

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

 

Tedy, 1000 файла в една директория са нищо за файлова система като ext3 (все пак това не е уиндоус). Можеш спокойно и 10000 да ги направиш, че и 100000.

[djadomraz]

Tedy, 1000 файла в една директория са нищо за файлова система като ext3 (все пак това не е уиндоус). Можеш спокойно и 10000 да ги направиш, че и 100000.

 

 

С риск да стана пак на "всяка манджа - мерудия", нека задам въпрос за бързодействието, защото май точно за това са на теди колебанията като гледам. Ако са 100,000 в една директория по-бързо ли ще е отварянето на файловете отколкото са по 100 в директория като нивата на вложеност са с 2 повече? Аз залагам на вложените директории в тоя случай...

[notor1ous]

Що се отнася до .NET/C#/MS SQL Server, във всяко отношение технологиите са по-добри от PHP, недостаътка е че са Windows-обвързани, което обаче е предимство от други гледни точки .

Имам съвсем малък, учебен опит с .NET технологии - безспорно си имат някой добри страни и решения, но... страшно много минуси. Като почнеш от това, че Microsoft е отмъкнал екипа на Borland, че е направен не за програмисти, а за хора, които трябва да знаят точното разположение на менютата им адски неинтуативния интерфейс, има разни несъвместимост между версиите и е изключително и само win зависима.

Сори за офтопика, но .NET е технология гениална в маркетингово отношение и с крайно съмнителни качества в научно-професионален план според мен. Просто програмирането е минимилизирано, изполсва се готови компоненти и т.н. Познавам хора, които пишат на C# и не знаят какво е референция и указател, едва ли могат да направят самостоятелно и сортировка на масив. .NET създава потребители, програмиращи от твърде високо ниво, който са зависими от графичния интерфейс на microsoft средата за писане/генериране на код.

Извинявайте пак за отклонението, но Теди имай милост - не намесвай .NET в раздела Linux

А колкото до статистиката за ползването на ОС - Соларис, фрееБСД също както Linux са UNIX базирани. Така, че в онзи сайт статистиката сочи 7 UNIX базирани ОС, една незнайна и 2 уин-а.

 

 

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

Броя на файловете в една директория няма нищо общо с отварянето и работата със самите файлове.

[tedy]

Виж ся ,

UNIX го уважавам адски много, както и сериозните сървърни системи, които подчертавам НЕ се бъркат навсякъде, както се опитва Linux с неговите един милион дистрибуции и фанатици .

UNIX за домашно ползване за десктоп и сериозен несървърен софтуер като графични програми от сорта на 3DS, *CAD, развойни среди - е sorry, малко така в 21 век сме.

А иначе в netcraft сега има два Win2003-та, в половината от другите месечни ъпдейти на статистиката досега съм засичал и по 3 и 4 броя в Топ10. Но не е там въпроса, и един да е постоянно присъстващ в спиосъка, е показателно. FreeBSD май най-често е на върха, и често 2003 е бил на 2 и 3-то място.

Толкова като коментар.

 

За .NET съм сигурен, че Djadomraz има МНОГО какво да каже по въпроса и аз ще се пазя от тази тема, където мозъците ще ти опонират здраво, но наистина това не е мястото за този оффтопик спор все пак де

 

Иначе както каза Djadomraz, интересуваше ме бързодействието при откриването на файла по файловата структура, а че самата работа с файловете не зависи от броя им няма спор, разликата идва във времето, след което ще е достъпен файла след заявяването му към ОС, както и колко ресурси ще глътне намирането му по диска .

 

Спорът ми беше полезен, и в крайна сметка пак се спирам на 1000 файла като компромисен вариант, подочух, че мозък е казал (човек с доста сървърен опит), че 100 файла е най-бързия вариант. А и поне до една година не се очаква да се натрупат повече от 100, 200 хил. файла. Не е сигурно най-ефективния вариант, но едва ли е и най-лошия, за супер оптимизации и теория в това отношение хората дават луди пари,с което по-късно си избиват разходите, а в този случай въпросните луди пари са твърде далеч от реалността, за да навлизам толкова дълбоко в точно тази част.

[notor1ous]

void Offtopic {

 

UNIX го уважавам адски много, както и сериозните сървърни системи, които подчертавам НЕ се бъркат навсякъде, както се опитва Linux с неговите един милион дистрибуции и фанатици .

Linux e open source версия на UNIX, затова са и милионите дистрибуции. Реално погтледнато всеки с малко по-задълбочени познания по програмиране на C/C++ и много свободно време може да си направи собствена дистрибуция

 

UNIX за домашно ползване за десктоп и сериозен несървърен софтуер като графични програми от сорта на 3DS, *CAD, развойни среди - е sorry, малко така в 21 век сме.

За това спор няма! UNIX си е конзола. А за Linux KDE и GNOME са готини на външен вид, но и аз предпочитам Win за десктоп работа. Но сървърните и "офис" (аз така ги наричам за по-обощено и универсално ) са си напълно различни неща.

 

}

 

[djadomraz]

Имам съвсем малък, учебен опит с .NET технологии - безспорно си имат някой добри страни и решения, но... страшно много минуси. Като почнеш от това, че Microsoft е отмъкнал екипа на Borland, че е направен не за програмисти, а за хора, които трябва да знаят точното разположение на менютата им адски неинтуативния интерфейс, има разни несъвместимост между версиите и е изключително и само win зависима.

Сори за офтопика, но .NET е технология гениална в маркетингово отношение и с крайно съмнителни качества в научно-професионален план според мен.

 

Пристрастен си и освен това не си ползвал .NET а само си гледал отдалече и като ви видял Visual Studio-то си решил че писането става с драгване на компоненти, цъкане насам-натам, задаване на property & events, което изобщо не е така... не че не може, но си е доста по-добре да пипаш направо HTML-a и някои неща да ги правиш с малко код вместо да драгваш компоненти и да кликаш наляво надясно. За "адски неинтуативния интерфейс" може да поспорим, но нека сключим примирие на "непознат за теб" като по-подходящ термин. Виж за "изключително win зависима" вече си прав...

 

Но сравнено с PHP е несравнимо повече като възможности и начин на работа. Най-бегло зачекнато - разделен е кода от дизайна, обектно ориентирано е всичко за разлика от php за което нееднократно е писано че е добър пример за неподходящо именуване на функциите... не мисля да продължавам че пак ще стане flame war...

 

 

 

има разни несъвместимост между версиите

 

Искаш да кажеш че при никой друг език/среда (примерно PHP) няма грам несъвместимост между различните версии??? Айде айде...

 

 

Просто програмирането е минимилизирано, изполсва се готови компоненти и т.н. Познавам хора, които пишат на C# и не знаят какво е референция и указател, едва ли могат да направят самостоятелно и сортировка на масив.

 

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

 

Между другото мога да се запозная с доста хора които бъкел не разбират от алгоритми и пишат на PHP - примерно термина двоично търсене никога не са го чували... това доказва ли нещо според теб? Мога също така да те запозная и с един приятел който пише на VB главно и е страхотно добър програмист (всъщност може да пише на какво ли не но повечето време напоследък пише на VB).

 

 

.NET създава потребители, програмиращи от твърде високо ниво, който са зависими от графичния интерфейс на microsoft средата за писане/генериране на код.

 

Не че JAVA е много по-ниско ниво и не че има указатели, но какво от това? Всеки език си има приложение. Крайно неудобно е да се пише потребителски интерфейс ползвайки асемблер - направо по-добре си направи харакири. То и със C++ и API calls също не е особено приятно, затова и има RAD среди и езици... Виж драйвер не можеш да напишеш на тях но пък определено е по-лесно, бързо и стабилно да направиш въвеждане на данните за клиент, попълване на фактура и прочее простотии които са 99% обработка на кликания и натискане на клавиши.

 

 

 

Броя на файловете в една директория няма нищо общо с отварянето и работата със самите файлове.

 

Хайде бе... сигурен ли си че има индекс с иметата на файловете и може да се прави двоично търсене, защото ако няма линейното сканиране даже на вече кеширани данни ще е доста трудоемко за процесора... Общо взето това питах аз. Защото в тоя случай достъпът ще е случаен и ще се отварят данните ту за един ту за друг но без никаква последователност, а когато има много заявки на секунда това ще утежни доста положението за търсенето, не е като да е без значение дали заема 0.01 сек или 0.18 сек. С просто око отварянето на на 1-2 файла не може да се усети ама при 1000 заявки (примерно) на секунда това е разликата между работене и неработене на въпросният сървър...

[notor1ous]

Започвам да мисля, че срещу мен се оформя нещо като коалиция Това в кръга на шегата.

Накратко:

Не смятам, че PHP е пример за подражание или е идеалния език, даже напротив. PHP е доста по-специализиран и не може да се сравнява с .NET, защото .NET дава много по-големи възможности за правене на най-разнообразни приложения. Не съм направил генерален извод за уменията на хората, пишещи на C#, PHP или каквото и да е друго. Просто казах, че според мен microsoft се опитва да създаде твърде "приятелска" среда, в която има готови функции за почти всичко (при РНР е горе-долу същото) и за програмиста остава само да подреди. За JAVA - на мен лично повече ли допада като концепция от .NET. Има доста плюсове, най-големият от който е универсалността.

 

За файловете в директориите:

търсенето на файл в директория и работата с файл са различни неща. На всеки е ясно, че ако направих grep в дирекория с 100000 файла ще отнеме повече време отколкото при 100 файла, заради повишаване на обема. Колкото до локализирането на файловете - според мен времената,които примерно си дал са или доста завишени или си правил тестове на слаба машина. Ще направя тестови скрипчета Но според мен е абсурдно да се говори за спиране на сървъра при 1000 заявки за отваряне на файл в папка, съдържаща голям брой файлове.

[djadomraz]

Просто казах, че според мен microsoft се опитва да създаде твърде "приятелска" среда, в която има готови функции за почти всичко (при РНР е горе-долу същото) и за програмиста остава само да подреди.

 

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

 

 

 

За JAVA - на мен лично повече ли допада като концепция от .NET. Има доста плюсове, най-големият от който е универсалността.

 

То иначе като език голяма разлика няма - само namespaces са с други имена. Аз съм правил copy & paste на java code в моя C# програма и след промяната на toString на ToString всичко тръгва без проблем - последно което си спомням беше че намерих една функция която double генерираше "с думи", така че не беше 5 реда ами поне 3-4 екрана код.

 

 

 

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

 

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

 

Та на въпроса - ext3 файловата система има ли индекс по имената на файловете и за търсенето на файл измежду стотици други става ли чрез двоично търсене или е обикновено линейно сканиране? Ако е с двоично търсене тогава по-добре да са 100,000 на едно място, ако не най-добре не повече от 100 според мен - така ако имаш 1,000,000 файла търсенето ще се ограничи максимум до 3 * 100 проверки - т.е. 300 сравнения, докато ако са по 1000 на едно място проверките стават максимум 2000 - разликата е близо 3 пъти. А при двоично търсене ако всички са на 1 място - необходимите проверки ще са максимум 40 (ако смятам правилно - 1,000,000 = 0xF4240 което прави 5 байта или иначе казано 40 бита)... абе под 50 са както и да го гледаш.

[tedy]

...

Нищо подобно, не се оформя коалиция, просто се изяснявахме, че .NET няма тези недостатъци, за които ти спомена. Без съмнение Java има предимството на универсалността. Но голям минус е неефективността. Тя просто работи бавно и мудно, особено в интерфейсно отношение. И другото е, че си е бъгава още, последно преди 2г. попаднах на някакъв супер малоумен бъг в математиката на Java, който ме втрещи как е възможно, нещо беше че не смята правилно някаква проста артиметика, ама забравих вече.

Ама тоя офтопик аз го почнах, за което съжалявам, влязохме в излишни спорове.

 

Относно файловете. Тия времена на Djadomraz бяха напълно измислени и дадени с изключително сравнителна цел. Сървърът може и да не спре да работи, но това е подобно, като се задръсти със заявки, в един момент последните чакащи ще трябва да чакат сигурно часове докато им дойде редът (аз повече от 30 сек. не бих чакал), и сървърът през това време ще удари 100% активност или на диска, или на процесора . Но за да не се случва това, все пак няма да изсипвам всички файлове в една директория, това е ясно.

По времето, когато FAT беше по- на мода и го познавах в детайли как работи, съм запомнил как се пазят данните в една директория, която не е главната. Най-общо: Като се започне дадено търсене, започва от главната директория, която има ентрита в началото на диска, веднага след FAT таблиците. Оттам нататък поддиректориите всичките се пазят по секторите на диска на общо основание, наред с файловете и данните (в резервирани сектори все пак, а не смесени със самите данни). Като се получава верига (chain), и всяко ентри на директория е отговорно за намирането на следващото ентри (точно йерархична структура). Файловете в една директория също са навързани по подобен начин. Линеен начин. С указатели за следващ файл в ентритата на директорията (които са в различни навързани сектори). Т.е. линейно се търсят първите клъстери от файла в една директория според реда, в който са указателите за директорията. При едно raw сканиране на файловете в директория, те излизат в напълно случаен ред (случаен за нас, но винаги по един и същ начин според chain-a), а вече Explorer ни ги подрежда по азбучен ред. При създаване на нов файл, той се добавя към веригата, а при изтриване, се премахва от веригата и става т.нар. късо съединение, ако мога така да се изразя.

Колкото повече файлове има в дир-а, толкова повече елементи средностатистически трябва линейно да се преминат докато се намери указателя към първия клъстер на файла (локализирането на файла).

Т.е. това преминава през FAT с указателя, но не е важно.

Това всичко за FAT.

 

При NTFS не знам как точно става, доколкото знам беше с по-организирана структура като двоична база данни или нещо такова, т.е. самата структура е осъвременена и подсигурена и предполагам по-ефективно работи всичко на база на двоични търсения или не знам точно.

При линукс пък съвсем не знам ext3 как е, и затова попитах, ако има хора с опит и са наясно дали ext3 и съответните кешове и настройки на един сървър се справя успешно с много файлове и по-важното - доколко макс. мога да сложа в директория без осезаемо да се увеличи натоварването и времената (осезаемо в смисъл като товар, а не като човешко възприятие). Защото не е и практично да има пък 100,000 директории с по 10 файла все пак

Но това ми беше и мисълта де, че броя файлове винаги има значение за бързодействието, въпросът беше доколко и дали изобщо това е проблем от толкова голямо значение на фона на ефективността на файловата система.

[notor1ous]

Направих тестове за времето необходимо за откриване на файл в дир.

Тествах на сървър, който е COMPAQ P3 650MHz с 128MB RAM.

ОС e Linux Debian.

С един доста примитивен скрипт генерирам файлове:

<?php
$i = 0;
while (!$i) {
	$name = rand(100000,1000000);
	echo $cmd = "touch file{$name}.txt";
	system($cmd);
}
?>

Ръчно пусках и спирах този скрипт, за да имам данни при различен брой файлове.

 

След това засичам за колко време се изпълнява възможно най-простата UNIX команда за показване на файл от директория:

<?php
$time_start = microtime();
system("ls test.txt");
$time_end = microtime();
$time = $time_end - $time_start;
echo "$time seconds\n";
?>

Файлът text.txt го създадох предварително в директирията.

 

А това е командата за показване на общия брой файлове в директорията:

ls | wc -l

 

 

Ето ги и резултатите:

 

2 files - 0.013187 seconds

10 files - 0.013259 seconds

5923 files - 0.013404 seconds

7383 files - 0.013225 seconds

9063 files - 0.012848 seconds

15417 files - 0.013957 seconds

20766 files - 0.013323 seconds

33698 files - 0.013283 seconds

 

Извод:

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

[Godfather]

При NTFS не знам как точно става, доколкото знам беше с по-организирана структура като двоична база данни или нещо такова, т.е. самата структура е осъвременена и подсигурена и предполагам по-ефективно работи всичко на база на двоични търсения или не знам точно.

При линукс пък съвсем не знам ext3 как е, и затова попитах, ако има хора с опит и са наясно дали ext3 и съответните кешове и настройки на един сървър се справя успешно с много файлове и по-важното - доколко макс. мога да сложа в директория без осезаемо да се увеличи натоварването и времената (осезаемо в смисъл като товар, а не като човешко възприятие). Защото не е и практично да има пък 100,000 директории с по 10 файла все пак

Но това ми беше и мисълта де, че броя файлове винаги има значение за бързодействието, въпросът беше доколко и дали изобщо това е проблем от толкова голямо значение на фона на ефективността на файловата система.

 

Вече ти казах, че параметрите, които си задал са твърде далече от идеята да затормозиш файловата система. Можеш да си направиш експерименти, но лично аз се съмнявам, че може да усетиш някаква разлика между 1000 и 10000 файла в една директория. От файловите системи, с които Линукс работи, най-оптимизирана в това отношение е RaiserFS - тя използва много бърз b-tree (binary tree) алгоритъм, който няма как да не даде сериозно отражение, ако се използват много (имам в пред вид над 100000) файлове в една директория. Друга подобна файлова система е XFS на SGI, която също стандартно се поддържа под Linux и използва b-tree алгоритъм. Аз лично предпочитам да използвам последната, поради други предимства, свързани най-вече с възможностите за journaling на големи масиви.

 

Въпросът с производителността тук изцяло е свързан с възможностите на дисковата подсистема на машината. При работа с 10000 файла в една директория почти не може да се хване разлика между отделни файлови системи и дори ОС - всички дават почти еднакви времена при изпълнението на цикъл от създаване на 10000 файла с нулев размер. При различни хардуерни конфигурации се получават доста осезаеми разлики. Например този скрипт се изпълнява на лаптопа ми (който е с AMD Turion64x2 1.6GHz) средно за 29 сек независимо под Windows или Linux. На друга десктоп машина с Pentium 4 на 2GHz, но с доста добри SATA дискове този скрипт се изпълнява стредно за 9 сек. На сървър с 10К SCSI дискове времето пада под 4 сек. За да се усети разлика между файловите системи с по-добри b-tree алгоритми, според мен трябва да се отиде на съвсем друго количество от поне 100000 файла и нагоре.

 

ПП. Хайде да оставим .Net на мира в тази тема, както и въпроса за фанатизма, че специално за последното би трябвало да отворим цяла отделна тема, посветена само на Бил Гейтс и Стив Бoлмър.

[tedy]

Благодаря на всички за усилията, явно се оказва, че проблемът не е толкова голям, даже почти е нямало значение колко са файловете в директорията.

Така или иначе колкото и да бях избрал като число (1000 или 10000), е нямало да има осезаема разлика и приложението ще си работи без проблеми от 'броен' характер.

И 100 в директория, едва ли щеше да има значение, но щом от 100,000 вече може да се усети някаква разлика, забивам ги на 10 хил. и се свършва одисеята.

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

За мен въпросът е приключил, благодаря отново.

[tedy]

Вярно ли е това за ext3:

There is a limit of 31998 sub-directories per one directory, stemming from its limit of 32000 links per inode.

?

Ако е вярно, става лоша хава, защото ако потребителите, които са качили снимки, нарастнат над 32 хиляди, става доста лошо какво ще се прави. Щото не всеки качва снимки. Даже може би към 30-40% качват.

Под NTFS четох някъде че май има подобни ограничения, на други места пише че няма, но не намерих при бързо търсене нещо по-конкретно.

[shadowhand]

Не е ясно за какви снимки говориш и какво общо има с поддиректории?