Зберігання мільйона зображень у файловій системі

У мене є проект, який генеруватиме величезну кількість зображень. Близько 1 000 000 для старту. Вони не є великими зображеннями, тому я буду зберігати їх на одній машині на старті.

Як ти рекомендуєш ефективно зберігати ці зображення? (Файлова система NTFS наразі)

Я розглядаю схему іменування ... для початку всі зображення матимуть додаткове ім'я від 1 вгору, я сподіваюся, що це допоможе мені сортувати їх пізніше, якщо потрібно, і кидати їх у різні папки.

яка була б краща схема іменування:

a / b / c / 0 ... z / z / z / 999

або

a / b / c / 000 ... z / z / z / 999

якась ідея з цього приводу?

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

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

 File path = generatePathFromSequenceNumber(sequenceNumber);

Простіше впоратися, якщо вам потрібно якось змінити структуру каталогів. Можливо, вам потрібно перенести зображення в інше місце, можливо, у вас не вистачає місця, і ви починаєте зберігати деякі зображення на диску A, а деякі на диску B і т.д. Простіше змінити одну функцію, ніж змінювати шляхи до бази даних .

Я б використав такий алгоритм для генерації структури каталогу:

1. Спочатку прокладіть послідовний номер з провідними нулями, поки у вас не буде принаймні 12-значний розряд. Це ім'я для вашого файлу. Ви можете додати суфікс:
   • 12345 -> 000000012345.jpg
2. Потім розділіть рядок на 2 або 3 символьні блоки, де кожен блок позначає рівень каталогу. Мати фіксовану кількість рівнів каталогів (наприклад 3):
   • 000000012345 -> 000/000/012
3. Збережіть файл у створеному каталозі:
   • Таким чином, повний шлях та ім'я файлу для файлу з ідентифікатором послідовності 123є 000/000/012/00000000012345.jpg
   • Для файлу з ідентифікатором послідовності 12345678901234був би шлях123/456/789/12345678901234.jpg

Деякі речі, які варто врахувати щодо структур каталогів та зберігання файлів:

• Наведений вище алгоритм дає вам систему, де кожен каталог аркушів має максимум 1000 файлів (якщо у вас менше 1 000 000 000 000 файлів)
• Може існувати обмеження, скільки файлів і підкаталогів може містити каталог, наприклад, система файлів ext3 в Linux має обмеження 31998 підкаталогів на один каталог.
• Звичайні інструменти (WinZip, Windows Explorer, командний рядок, bash shell тощо) можуть не працювати дуже добре, якщо у вас є велика кількість файлів у каталозі (> 1000)
• Сама структура каталогів займе трохи дискового простору, тому вам не потрібно буде занадто багато каталогів.
• З вищевказаною структурою ви завжди можете знайти правильний шлях до файлу зображення, просто подивившись на ім’я файлу, якщо ви зіпсуєте структуру каталогу.
• Якщо вам потрібно отримати доступ до файлів з декількох машин, розгляньте можливість спільного використання файлів через мережеву файлову систему.
• Вищевказана структура каталогу не працюватиме, якщо ви видалите багато файлів. Це залишає "дірки" в структурі каталогів. Але оскільки ви не видаляєте жодних файлів, це повинно бути добре.

Я збираюся поставити свої 2 копійки на суму негативної поради: Не йдіть із базою даних.

Я працював із базами даних для зберігання зображень протягом багатьох років: великі (1 мег-> 1 гіг) файли, часто змінювані, кілька версій файлу, доступ до яких досить часто. Проблеми з базою даних, з якими ви стикаєтесь із великими файлами, що зберігаються, надзвичайно виснажливі для вирішення, проблеми з написанням та транзакціями є складними, і ви стикаєтесь із проблемами блокування, які можуть спричинити великі аварії поїздів. У мене є ще практика в написанні сценаріїв DBCC і відновлення таблиць з резервних копій , ніж будь-яка нормальна людина повинна коли - або мати.

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

Я думаю, що більшість сайтів, які мають справу з цим, використовують певний хеш, щоб гарантувати рівномірний розподіл файлів у папках.

Отже, скажіть, у вас є хеш файлу, який є приблизно подібним. 515d7eab9c29349e0cde90381ee8f810
Ви могли б зберігати його в наступному місці, і ви можете використовувати скільки завгодно глибоких рівнів, щоб зберегти низьку кількість файлів у кожній папці.
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg

Я бачив такий підхід багато разів. Вам все ще потрібна база даних для зіставлення цих хешів файлів на читабельному імені людини та будь-яких інших метаданих, які потрібно зберігати. Але такий підхід досить добре масштабує b / c, ви можете почати розподіляти хеш-адресний простір між декількома комп'ютерами та або пулами пам’яті тощо.

В ідеалі вам слід виконати кілька тестів на час випадкового доступу для різних структур, оскільки ваші конкретні настройки жорсткого диска, кешування, наявна пам'ять тощо можуть змінити ці результати.

Якщо припустити, що ви маєте контроль над іменами, я б розділив їх на рівні 1000 з кожного каталогу. Чим більше рівнів каталогів ви додаєте, тим більше входів ви записуєте, тому тут є поштовх.

Наприклад,

/ root / [0-99] / [0-99] / ім'я файлу

Зауважте, http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx має докладнішу інформацію про налаштування NTFS. Зокрема, "Якщо ви використовуєте велику кількість файлів у папці NTFS (300 000 і більше), вимкніть генерацію коротких імен файлів для кращої продуктивності, особливо якщо перші шість символів довгих імен файлів схожі".

Також слід вивчити відключення функцій файлової системи, які вам не потрібні (наприклад, час останнього доступу). http://www.pctools.com/guides/registry/detail/50/

Що б ви не робили, не зберігайте їх усіх в одному каталозі.

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

Тому:

Папка img\a\b\c\d\e\f\g\міститиме зображення, що починаються з 'abcdefg' тощо.

Ви можете ввести власну необхідну глибину.

Чудова річ у цьому рішенні полягає в тому, що структура каталогу ефективно діє як хештеб / словник. Давши ім'я файлу зображення, ви будете знати його каталог і давати каталог, ви будете знати підмножину зображень, які туди йдуть.

Я б зберігав їх у файловій системі, але це залежить від того, наскільки швидко зросте кількість файлів. Ці файли розміщені в Інтернеті? Скільки користувачів отримають доступ до цього файлу? Це питання, на які потрібно відповісти, перш ніж я зможу дати вам кращу рекомендацію. Я також хотів би поглянути на Haystack з Facebook, вони мають дуже гарне рішення для зберігання та подання зображень.

Також якщо ви виберете файлову систему, вам потрібно буде розділити ці файли на каталоги. Я розглядав це питання і пропонував рішення, але воно не є ідеальним жодним чином. Я розділяю хеш-таблицю і користувачів, які ви можете прочитати більше в моєму блозі .

У нас є система фотомагазин із 4 мільйонами зображень. Ми використовуємо базу даних лише для метаданих, і всі зображення зберігаються у файловій системі за допомогою перевернутої системи імен, де імена папок генеруються з останньої цифри файлу, last-1 тощо. наприклад: 000001234.jpg зберігається в структурі каталогів, як 4 \ 3 \ 2 \ 1 \ 000001234.jpg.

Ця схема дуже добре працює з індексом ідентичності в базі даних, оскільки вона рівномірно заповнює всю структуру каталогів.

Швидкий пункт, вам не потрібно зберігати шлях до файлу у вашій БД. Ви можете просто зберегти числове значення, якщо ваші файли названі так, як ви описуєте. Тоді, використовуючи одну з чітко визначених схем зберігання, про яку вже йшлося, ви можете отримати індекс у вигляді числа та дуже швидко знайти файл, перейшовши за структурою каталогу.

У новому MS SQL 2008 є нова функція для обробки таких випадків, вона називається FILESTREAM. Поглянь:

Огляд програми FILESTREAM Microsoft TechNet

Чи повинні ваші зображення бути названі однозначно? Чи може процес, що генерує ці зображення, давав одне і те ж ім’я файлу не один раз? Важко сказати, не знаючи, який пристрій створює ім'я файлу, але скажіть, що пристрій "скидається", і після перезавантаження він починає називати зображення, як це робилося в останній раз, коли він був "скиданням" - якщо це викликає таке занепокоєння ..

Крім того, ви кажете, що за один місяць ви потрапите на 1 мільйон зображень. А як після цього? Як швидко ці зображення продовжать заповнювати файлову систему? Чи добудуть вони в якийсь момент і вирівняють приблизно 1 мільйон ВСЕГО зображень чи продовжуватимуть зростати та зростати місяць за місяцем?

Я прошу, тому що ви можете почати проектувати свою файлову систему по місяцях, а потім по зображенню. Я можу схилити запропонувати зберегти зображення в такій структурі каталогу:

imgs\yyyy\mm\filename.ext

where: yyyy = 4 digit year
         mm = 2 digit month

example:  D:\imgs\2009\12\aaa0001.jpg
          D:\imgs\2009\12\aaa0002.jpg
          D:\imgs\2009\12\aaa0003.jpg
          D:\imgs\2009\12\aaa0004.jpg
                   |
          D:\imgs\2009\12\zzz9982.jpg
          D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
          D:\imgs\2010\01\aab0001.jpg

Місяць, рік, навіть день корисні для зображень типу безпеки. Не впевнений, що це ви робите, але я це робив із домашньою камерою безпеки, яка знімала фотографію кожні 10 секунд ... Таким чином ваша програма може деталізувати конкретний час або навіть діапазон, де ви можете подумати, що зображення було створене . Або замість року, місяця - чи є якесь інше «значення», яке можна отримати з самого файлу зображення? Деякі інші дескриптори, окрім прикладу дати, який я дав?

Я б не зберігав двійкові дані в БД. Ніколи не мав гарної продуктивності / удачі з подібними речами. Не можу уявити, що він працює добре з 1 мільйоном зображень. Я б зберігав ім'я файлу, і це все. Якщо всі вони будуть JPG, тоді навіть не зберігайте розширення. Я б створив керуючу таблицю, яка зберігала вказівник на сервер файлу, диск, шлях тощо. Таким чином ви можете перемістити ці зображення в інший ящик і все одно знайти їх. Чи потрібно тегнути ваші зображення на ключових словах? Якщо так, то ви хочете скласти відповідні таблиці, що дозволяють проводити такий тип тегів.

Ви / інші, можливо, зверталися до цих ідей, поки я відповідав. Сподіваюся, це допомагає ..

Я беру участь у проекті, який протягом року зберігає 8,4 мільйонів зображень для документування статусу різних пристроїв. До більш пізніх зображень можна звертатися частіше, а до старих зображень рідко шукати, якщо не було виявлено умови, яка спонукала когось зануритися в архіви.

Моє рішення, засноване на такому використанні, полягало в поступовому зашипуванні зображень у стислі файли. Зображення - це JPG, кожен приблизно 20 кБ, і не дуже стискається, тому схема стиснення ZIP - жодна. Це робиться лише для об'єднання їх в одну файлову систему, що значно допомагає NTFS з точки зору швидкості, якщо мова йде про переміщення їх з диска на диск або перегляд списку файлів.

Зображення, старші за добу, поєднуються у "щоденний" блискавку; блискавки старші місяця поєднуються у відповідний "місячний" поштовий індекс; і нарешті нічого більше року більше не потрібно і, отже, видаляється.

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

Я розумію, це, мабуть, не пов'язане з вашими конкретними деталями, але я думав, що поділюсь.

Можливо, схема іменування на основі дати створення - або включаючи всю інформацію в ім'я файлу, або (краще для перегляду пізніше), розділяючи її на каталоги. Я можу придумати таке, залежно від того, як часто ви створюєте зображення:

• Кілька зображень, що генеруються щодня: Year/Month/Day/Hour_Minute_Second.png
• Пара в місяць: Year/Month/Day_Hour_Minute_Second.png

і т. д. Ви розумієте мою думку ... =)

Я б схильний створити структуру папок на основі дати, наприклад, \ year \ month \ day, і використовувати часові позначки для імен файлів. Якщо необхідно, часові позначки можуть мати додатковий лічильник, якщо зображення повинні бути створені так швидко, що їх може бути більше ніж один мілісекунд. Використовуючи найбільш важливу до найменш значущої послідовності для іменного сортування, пошук та обслуговування є легким вітром. наприклад hhmmssmm [seq] .jpg

Ви розглядаєте можливість відновлення після катастроф?

Деякі із запропонованих тут рішень закінчуються керуванням іменем файлу (таким чином, якщо фізичний файл був переміщений, ви втратите інформацію про те, яким він є насправді). Я рекомендую зберегти унікальне фізичне ім'я файлу, щоб у випадку, якщо ваш головний список розташувань файлів пошкоджений, ви можете відновити його за допомогою невеликої оболонки, er, powerhell, script;)

З того, що я прочитав тут, здається, що всі ці файли будуть зберігатися в одній файловій системі. Подумайте про їх зберігання в декількох файлових системах на декількох машинах. Якщо у вас є ресурси, визначте систему зберігання кожного файлу на двох різних машинах, якщо ви втратите джерело живлення, а заміна буде 2 дні.

Розглянемо, які саме процедури потрібно створити для переміщення файлів між машинами або файловими системами. Можливість робити це за допомогою вашої системи в прямому ефірі та в Інтернеті може врятувати вам істотний головний біль у дорозі.

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

Якщо потрібно, подумайте про використання CDN, такого як Amazon S3.

Хоча я ще не подавав фотографії в такому масштабі, я раніше написав невелику програму для галереї для подачі ~ 25 К фотографій на машині 400 МГц w. 512 Мб оперативної пам’яті або близько того. Деякі переживання;

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

• Дослідження поведінки файлової системи; для ext3 (або це був ext2 у той час - не пам'ятаю), межа можливості ефективно шукати підкаталоги та файли становила близько позначки 256; тож маючи лише стільки файлів і папок у будь-якій папці. Знову помітна швидкість. Поки я не знаю про NTFS, такі речі, як XFS (для яких використовуються B-дерева, наскільки я пам’ятаю) надзвичайно швидкі, просто тому, що вони можуть робити пошук дуже швидко.

• Розподіляти дані рівномірно; коли я експериментував із вищезазначеним, я намагався розподілити дані рівномірно по всіх каталогах (я зробив MD5 URL-адреси та використав це для каталогів /1a/2b/1a2b...f.jpg). Таким чином потрібно більше часу, щоб досягти будь-якого обмеження продуктивності (а кеш файлової системи все одно недійсний на таких великих наборах даних). (навпаки, ви можете побачити, де на початку є обмеження; тоді ви хочете перекинути все в перший доступний каталог.

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

String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

Це призведе до того, що шлях буде таким:

/172/029/cat.gif

Потім ви можете знайти cat.gifв структурі каталогів, відтворивши алгоритм.

Використання HEX як імен каталогів було б таким же простим, як і перетворення intзначень:

String path = new StringBuilder(File.separator)
        .append(String.format("%02x", firstDir))
        .append(File.separator)
        .append(String.format("%02x", secondDir)
        .toString();

Результат:

/AC/1D/cat.gif

Я написав статтю про це кілька років тому і нещодавно перемістив її до Середнього. У ньому є ще кілька деталей та деякий зразок коду: Ім'я файлу Hashing: Створення структури хеш-каталогу . Сподіваюся, це допомагає!

Якщо ви знаходитесь у Windows, як щодо файлу exFat

http://msdn.microsoft.com/en-us/library/aa914353.aspx

він був розроблений з урахуванням збереження медіа-файлів на увазі та доступний зараз.

Якщо вони ВСІ не потрібні відразу, і ви можете генерувати їх на ходу, і це невеликі зображення, чому б не реалізувати пам'ять LRU або дисковий кеш над вашим генератором зображень?

Це може врятувати вас від сховища та зберегти гарячі зображення, які можна подавати з пам’яті?

Я щойно провів тест на zfs, тому що я люблю zfs, і у мене був розділ на 500 гіг, на якому я мав компресію. Я написав сценарій, який генерував 50-100k файлів і розмістив їх у вкладених каталогах 1/2/3/4/5/6/7/8 (на 5-8 рівнів глибиною) і нехай він запускається, я думаю, 1 тиждень. (це був не чудовий сценарій.) Він заповнив диск і в кінцевому підсумку мав близько 25 мільйонів файлів або близько того. Доступ до будь-якого одного файлу з відомим шляхом був миттєвим. Перерахування будь-якого каталогу із відомим шляхом було моментальним.

Оцінка списку файлів (через пошук) зайняла 68 годин.

Я також провів тест, помістивши в один каталог багато файлів. Я добув приблизно 3,7 мільйона файлів в одному каталозі, перш ніж зупинився. Перерахування каталогу для підрахунку зайняло близько 5 хвилин. Видалення всіх файлів із цього каталогу зайняло 20 годин. Але пошук і доступ до будь-якого файлу був миттєвим.

Я бачу інші згадки бази даних, але не бачу жодної згадки про це у своєму дописі. У будь-якому випадку, моя думка з цього приводу: або дотримуватися бази даних або файлової системи. Якщо вам доведеться змішати два, будьте обережні. Речі ускладнюються. Але, можливо, доведеться. Збереження мільйона фотографій у базі даних не є найкращою ідеєю.

Вас може зацікавити наступна специфікація, більшість цифрових камер дотримуються її для управління зберіганням файлів: https://en.wikipedia.org/wiki/Camera_Image_File_Format

По суті, створюється папка, наприклад, 000OLYMPUSі фотографії додаються до цієї папки (наприклад DSC0000.RAW). Коли лічильник імен файлів досягає DSC9999.RAWнової папки, створюється ( 001OLYMPUS), а зображення додаються знову, скидаючи лічильник, можливо, з іншим префіксом (наприклад:) P_0000.RAW.

Ви також можете створити папки на основі частин імені файлу (вже згадувалося кілька разів). Наприклад, якщо ваша фотографія названа IMG_A83743.JPG, зберігайте її за адресою IMG_\A8\3\IMG_A83743.JPG. Це складніше в реалізації, але полегшить пошук ваших файлів.

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

Ви можете поглянути на ZFS (файлова система, менеджер томів від Sun) З повагою

Чистий спосіб генерувати шлях з великої кількості - це легко перетворити його в шістнадцятковий, а потім розділити його!

наприклад , 1099496034834> 0xFFFF1212>FF/FF/12/12

public string GeneratePath(long val)
{  
    string hex = val.ToString("X");
    hex=hex.PadLeft(10, '0');
    string path="";
    for(int i=0; i<hex.Length; i+=2 )
    {
        path += hex.Substring(i,2);
        if(i+2<hex.Length)
            path+="/";
    }
    return path;
}

Зберігати та завантажувати:

public long Store(Stream doc)
{
   var newId = getNewId();
   var fullpath = GeneratePath(newId)
   // store into fullpath 
   return newId;
}

public Stream Load(long id)
{
   var fullpath = GeneratePath(newId)
   var stream = ... 
   return stream;
}

Повні вихідні коди: https://github.com/acrobit/AcroFS

На жаль, файлові системи дуже погані (продуктивність з багатьма файлами в каталозі або глибокими деревами каталогів, перевірка часу на перезапуск, надійність) при керуванні безліччю невеликих файлів, тому рішення вище, яке включає ZIP-файли, найкраще, якщо ви хочете використовувати файлову систему.

Використання диспетчера баз даних - це найкращий варіант; простий, наприклад, BDB або GDBM; навіть відносні СУБД, як MySQL, було б краще. Лише ледачі, які не розуміють файлові системи та бази даних (наприклад, ті, хто відхиляє транзакції), як правило, використовують файлові системи як бази даних (або дещо рідше - навпаки).

Як щодо бази даних із таблицею, що містить ідентифікатор та BLOB для зберігання зображення? Потім ви можете додавати нові таблиці, коли ви хочете пов’язати більше фотографій з фотографією.

Якщо ви розраховуєте на масштаб, чому б зараз не масштабувати? Ви заощадите час як зараз, так і пізніше IMO. Реалізуйте шар бази даних один раз, з чого досить просто. Або реалізуйте щось із папками та назви файлів і бла-бла-бла, а пізніше перейдіть на щось інше, коли ви почнете підірвати MAX_PATH.