1 Тема від ktretyak

  • ktretyak
  • Replace Group
  • Поза форумом
  • Дата реєстрації: 30.01.2014
  • Повідомлень: 2 080
    • Репутація: 758

Тема: Обмеження по кількості файлів в одну теку.

Зараз проектую сховище для зберігання зображень на hub.org.ua. По-гуглив трохи, знайшов ось це питання на stackoverflow.

Судячи з відповіді, однієї теки мені достаньо "з головою". Але виникає питання: "Навіщо тоді усі оці традиційні розбиття на субтеки?". Наприклад, у хабра-сховищі ми бачимо три- (чи чотири-) рівневе розбиття. Схожу картину я бачив не раз, коли розглядав різні системи кешування.

Припускаю, може це історично так склалось, бо раніше були значно скромніші ліміти для однієї теки, і зараз люди за інерцією таку архітектуру сховища повторюють. Хоча, може це через потребу відкривати конкретну теку в GUI, і в такому разі дійсно кількість має значення. Але ж, якщо ніколи не користуватись тим GUI, чи варто все ж так розбивати теки, є у цьому сенс?

2 Відповідь від P.Y.

  • P.Y.
  • P.Y.
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 19.02.2013
  • Повідомлень: 7 660
    • Репутація: 4983

Re: Обмеження по кількості файлів в одну теку.

Здається, причина такого структурування — не технічне обмеження на максимальну кількість файлів на рівні ОС, а сповільнення дій із текою, коли файлів у ній забагато. Крім того, якщо файли лежать у багатьох теках, відкривається можливість досить легко розкидати їх по кількох серверах, а з головного сервера робити перенаправлення, в залежності від того, в якій теці лежить зображення (утім, щось подібне можна реалізувати і без додаткових тек).

Подякували: koala1

3 Відповідь від ktretyak

  • ktretyak
  • Replace Group
  • Поза форумом
  • Дата реєстрації: 30.01.2014
  • Повідомлень: 2 080
    • Репутація: 758

Re: Обмеження по кількості файлів в одну теку.

утім, щось подібне можна реалізувати і без додаткових тек

Отож бо й воно. Десь я краєм вуха чув, що розбиття на теки - умовне, бо насправді усі файли знаходяться в одній глобальній теці, і на швидкодію пошуку впливає хіба що довжина повного імені (абсолютний шлях). З іншого боку, по тому ліку, що я навів вище, коментатори кажуть, що проблеми виникають не лише у GUI, а й у інших утиліт для файлової системи, що вони повноцінно працюють, коли у теці не більше 32 тис. файлів.

Мабуть не буду мудрувати, зроблю традиційним способом, благо - це досить легко організувати.

4 Відповідь від HetmanNet

  • HetmanNet
  • HetmanNet
  • Ліцензований троль форуму Replace
  • Поза форумом
  • Звідки: Кременчук, Україна
  • Дата реєстрації: 18.07.2012
  • Повідомлень: 4 740
    • Репутація: 2494

Re: Обмеження по кількості файлів в одну теку.

P.Y. написав:

Здається, причина такого структурування — не технічне обмеження на максимальну кількість файлів на рівні ОС, а сповільнення дій із текою, коли файлів у ній забагато. Крім того, якщо файли лежать у багатьох теках, відкривається можливість досить легко розкидати їх по кількох серверах, а з головного сервера робити перенаправлення, в залежності від того, в якій теці лежить зображення (утім, щось подібне можна реалізувати і без додаткових тек).

Без додаткових тек воно буде вкрай повільне..

5 Відповідь від ktretyak

  • ktretyak
  • Replace Group
  • Поза форумом
  • Дата реєстрації: 30.01.2014
  • Повідомлень: 2 080
    • Репутація: 758

Re: Обмеження по кількості файлів в одну теку.

Те що на desctop'і в GUI буде повільно відкриватись, у мене сумнівів немає. На моїй попередній роботі, колега налатував log-shipping (усі транзакції в БД) в одну теку. Здається, через тиждень цей логшиппінг "відвалився", на моїх очах він поліз дивитись "Що сталось" і не зміг відкрити теку на протязі, мабуть, хвилин п'яти.

З одного боку цей випадок міг би свідчити про проблеми не тільки з GUI, а з іншого - то була таки Windows, я сподівався що у Linux таких проблем немає. Схоже, таки є.

6 Відповідь від HetmanNet

  • HetmanNet
  • HetmanNet
  • Ліцензований троль форуму Replace
  • Поза форумом
  • Звідки: Кременчук, Україна
  • Дата реєстрації: 18.07.2012
  • Повідомлень: 4 740
    • Репутація: 2494

Re: Обмеження по кількості файлів в одну теку.

ktretyak написав:

Те що на desctop'і в GUI буде повільно відкриватись, у мене сумнівів немає. На моїй попередній роботі, колега налатував log-shipping (усі транзакції в БД) в одну теку. Здається, через тиждень цей логшиппінг "відвалився", на моїх очах він поліз дивитись "Що сталось" і не зміг відкрити теку на протязі, мабуть, хвилин п'яти.

З одного боку цей випадок міг би свідчити про проблеми не тільки з GUI, а з іншого - то була таки Windows, я сподівався що у Linux таких проблем немає. Схоже, таки є.

Вони є.. але при значно більших масштабах ніж на windows.. тому часто таке роблять.. йдуть місяці і потім по троху починає працювати повільніше і повільніше.. знаю чуваків у яких десь рік пройшов поки їм не дійшло що система в рази три повільніша ніж мала бути..

7 Відповідь від iovchynnikov Востаннє редагувалося iovchynnikov (22.05.2017 21:35:06)

  • Звідки: Спочивальня Бандери
  • Дата реєстрації: 24.01.2016
  • Повідомлень: 496
    • Репутація: 589

Re: Обмеження по кількості файлів в одну теку.

Можна подумати й про зберігання файлів в базі. Спокійно можна зберегти дані в блобах. База мінусує ще одне місце яке треба бекапити (не треба вигадувати як збирати бекапи і з бази, і з fs.) Так як часто це все розкидане, зробити централізований бекап стає дійсно викликом. Ви також не переймається про будь які обмеження фс, housekeeping операціях і тд.

Проте, ідеальним варіантом imho буде подумати про якийсь Amazon S3.