Тож я використовую додаток, який значно зберігає зображення в БД. Який ваш прогноз щодо цього? Я більше типу зберігати розташування у файловій системі, ніж зберігати його безпосередньо в БД.
Як ви думаєте, які плюси та мінуси?
Відповіді:
Я відповідаю за деякі програми, які керують багатьма зображеннями ТБ. Ми виявили, що найкраще зберігати шляхи до файлів у базі даних.
Є кілька питань:
Як і в більшості питань, це не так просто, як це звучить. Бувають випадки, коли було б сенс зберігати зображення в базі даних.
З іншого боку, пов'язані проблеми
Магазин файлів. Інженери Facebook вели чудову розмову про це. Одне з них було знати практичний ліміт файлів у каталозі.
Голка в стозі сіна: ефективне зберігання мільярдів фотографій
Це може бути досить довгим знімком, але якщо ви використовуєте (або плануєте використовувати) SQL Server 2008, рекомендую ознайомитися з новим типом даних FileStream .
FileStream вирішує більшість проблем навколо зберігання файлів у БД:
Однак "Прозоре шифрування даних" SQL не шифрує об'єкти FileStream, тому, якщо це врахування, вам може бути краще просто зберігати їх як варбінарні.
З статті MSDN:
Оператори Transact-SQL можуть вставляти, оновлювати, запитувати, шукати та створювати резервні копії даних FILESTREAM. Інтерфейси файлової системи Win32 забезпечують потоковий доступ до даних.
FILESTREAM використовує системний кеш NT для кешування даних файлів. Це допомагає зменшити будь-який ефект, який можуть мати дані FILESTREAM на продуктивність Database Engine. Буферний пул SQL Server не використовується; тому ця пам'ять доступна для обробки запитів.
Шлях файлів у БД - це, безумовно, шлях - я чув за сюжетом від клієнтів із ТБ зображень, що це стало кошмаром, який намагався зберігати будь-яку значну кількість зображень у БД - один показник ефективності занадто великий.
На мій досвід, іноді найпростішим рішенням є назви зображень відповідно до первинного ключа . Тож легко знайти зображення, яке належить до певного запису, і навпаки. Але в той же час ви нічого не зберігаєте про зображення в базі даних.
Хитрість тут - не стати завзятим.
Тут слід зауважити, що ніхто в таборі файлових систем не вказав конкретну файлову систему. Чи означає це, що все від FAT16 до ZFS зручно перемагає кожну базу даних?
Ні.
Правда полягає в тому, що багато баз даних перемагають багато файлових систем, навіть якщо ми говоримо лише про швидкість необробленого.
Правильний хід дій полягає в тому, щоб прийняти правильне рішення за вашим точним сценарієм, і для цього вам знадобляться деякі цифри та деякі оцінки використання.
У місцях, де Ви ОБОВ'ЯЗКОВО гарантуєте референтну цілісність та відповідність ACID, зберігання зображень у базі даних не потрібно.
Ви не можете напросто гарантувати, що зображення та метадані про це зображення, що зберігаються в базі даних, посилаються на один і той самий файл. Іншими словами, неможливо гарантувати, що файл у файловій системі змінюється лише коли-небудь одночасно і в тій же транзакції, що і метадані.
Як говорили інші, SQL 2008 поставляється з типом Filestream, який дозволяє зберігати ім'я файлу або ідентифікатор як вказівник у db і автоматично зберігає зображення у вашій файловій системі, що є прекрасним сценарієм.
Якщо ви перебуваєте в більш старій базі даних, то я б сказав, що якщо ви зберігаєте її як дані з блобу, то ви дійсно не збираєтеся нічого витягувати з бази даних за допомогою пошуку функцій, тому, мабуть, найкраще щоб зберегти адресу у файловій системі та зберегти зображення таким чином.
Таким чином ви також економите простір у вашій файловій системі, оскільки збираєтесь лише заощадити точну кількість простору або навіть ущільнити простір у файловій системі.
Крім того, ви можете вирішити зберегти за допомогою якоїсь структури або елементів, які дозволяють переглядати необроблені зображення у вашій файловій системі без будь-яких хітів db, або переносити файли масово на іншу систему, жорсткий диск, S3 або інший сценарій - оновлення місця в вашої програми, але зберігайте структуру, знову без особливого удару, намагаючись вивести зображення з вашого db, намагаючись збільшити обсяг пам’яті.
Ймовірно, це також дозволить вам кинути якийсь елемент кешування на основі часто вражених URL-адрес зображення у свій веб-движок / програму, тож ви також економите там.
Невеликі статичні зображення (не більше пари мег), які не часто редагуються, повинні зберігатися в базі даних. Цей метод має ряд переваг, включаючи простішу портативність (зображення передаються в базу даних), легше резервне копіювання / відновлення (зображення створюються резервними копіями в базі даних) та кращу масштабованість (папка файлової системи з тисячами маленьких мініатюрних файлів звучить як кошмар масштабованості мене).
Обслуговування зображень із бази даних просто, просто реалізуйте оброблювач http, який обслуговує масив байтів, повернутий із сервера БД, як двійковий потік.
Ось цікава довідка з цієї теми.
Для BLOB чи не для BLOB: велике сховище об’єктів у базі даних або файловій системі
Відповідь "Це залежить". Звичайно, це буде залежати від сервера баз даних та його підходу до блокового зберігання. Це також залежить від типу даних, що зберігаються в краплі, а також від того, яким чином доступ до цих даних.
Файли меншого розміру можна ефективно зберігати та доставляти, використовуючи базу даних як механізм зберігання. Більш великі файли, ймовірно, найкраще зберігати за допомогою файлової системи, особливо якщо вони будуть часто змінюватися / оновлюватися. (фрагментація краплі стає проблемою щодо ефективності.)
Ось додатковий момент, який потрібно пам’ятати. Однією з причин, що підтримують використання бази даних для зберігання крапів, є відповідність ACID. Однак підхід, який використовували тестери у Білій книжці (опція масової реєстрації SQL Server), яка подвоювала пропускну здатність SQL Server, фактично змінила значення "D" в ACID на "d", оскільки дані про краплі не реєструвалися початкові записи для транзакції. Тому, якщо повна відповідність ACID є важливою вимогою для вашої системи, зменшіть удвічі цифри пропускної здатності SQL Server для запису бази даних при порівнянні вводу / виводу файлів з блоком вводу / виводу бази даних.
Одне, що я ще не бачив, щоб хтось згадував, але, безумовно, варто зазначити, що є проблеми, пов’язані зі зберіганням великої кількості зображень і в більшості файлових систем. Наприклад, якщо ви скористаєтеся вищезгаданим підходом та назвали кожен файл зображень після первинного ключа, у більшості файлових систем ви будете стикатися з проблемами, якщо спробуєте помістити всі зображення в одну велику директорію, як тільки ви отримаєте дуже велику кількість зображень ( наприклад, у сотнях тисяч чи мільйонах).
Колись загальним рішенням цього є хешування їх у збалансоване дерево підкаталогів.
Щось ніхто не згадував, це те, що БД гарантує атомні дії, транзакційну цілісність і має справу з одночасністю. Навіть референтна цілісність знаходиться поза вікном з файловою системою - тож як ви знаєте, що імена файлів насправді все-таки правильні?
Якщо у вас є зображення у файловій системі, і хтось читає файл, коли ви пишете нову версію або навіть видаляєте файл - що станеться?
Ми використовуємо краплі, тому що ними легше керувати (резервне копіювання, реплікація, передача). Вони добре працюють на нас.
Проблема із збереженням лише файлових шляхів до зображень у базі даних полягає в тому, що цілісність бази даних вже не може бути примусовою.
Якщо фактичне зображення, на яке вказує файловий шлях, стає недоступним, база даних мимоволі має помилку цілісності.
Зважаючи на те, що зображення - це фактичні дані, які шукаються, і керувати ними можна простіше (зображення не раптом зникнуть) в одній інтегрованій базі даних, а не взаємодії з якоюсь файловою системою (якщо до файлової системи здійснюється незалежний доступ, зображення МОЖУТЬ раптово «зникати»), я б хотів їх зберігати безпосередньо як BLOB або подібні.
У компанії, де я працював, ми зберігали 155 мільйонів зображень у базі даних Oracle 8i (тоді 9i). 7,5 ТБ вартістю.
Як правило, я рішуче проти того, щоб зайняти найдорожчу і найважчу для масштабування частину вашої інфраструктури (базу даних) і вкладати в неї все навантаження. З іншого боку: Це значно спрощує стратегію резервного копіювання, особливо коли у вас є кілька веб-серверів і вам потрібно якось підтримувати синхронізацію даних.
Як і більшість інших речей, це залежить від очікуваного розміру та бюджету.
Ми впровадили систему зображень документів, яка зберігає всі її зображення у полях SQL2005. На даний момент є кілька сотень ГБ, і ми спостерігаємо чудові часи відгуку та малоефективну деградацію продуктивності. Крім того, у відповідності до регуляторних норм, у нас є проміжний рівень, який архівує нещодавно опубліковані документи в оптичну систему автоматів, яка виставляє їх як стандартну файлову систему NTFS.
Ми були дуже задоволені результатами, особливо стосовно:
Припущення: Додаток увімкнено в Інтернеті / на веб-основі
Я здивований, що ніхто про це не згадував ... делегуйте це іншим, хто є фахівцями -> використовуйте стороннього постачальника хостингу зображень / файлів .
Зберігайте свої файли на платній онлайн-службі, як-от
Інші теми StackOverflow тут говорять про це .
Цей потік пояснює, чому слід використовувати стороннього хостинг-провайдера.
Це так варте того. Вони зберігають його ефективно. Немає пропускної спроможності завантажуватися з ваших серверів на запити клієнта тощо.
Якщо ви не на SQL Server 2008 і у вас є вагомі причини для розміщення певних файлів зображень у базі даних, ви можете скористатися підходом "обидва" та використовувати файлову систему як тимчасовий кеш і використовувати базу даних як головне сховище .
Наприклад, ваша бізнес-логіка може перевірити, чи існує файл зображення на диску, перш ніж подавати його, вилучаючи з бази даних, коли це необхідно. Це дає вам можливість використовувати декілька веб-серверів і менше проблем із синхронізацією.
Я не впевнений, наскільки це приклад "реального світу", але в даний час у мене є додаток, який зберігає деталі для гри в торговельну карту, включаючи зображення для карт. Наразі кількість записів для бази даних на сьогодні складає лише 2851 запис, але, враховуючи той факт, що певні картки випускаються багаторазово і мають альтернативні твори ілюстрації, насправді було більш ефективним розміром сканування "первинного квадрата" твори, а потім динамічно генерувати межі та інші ефекти для картки, коли вони вимагаються.
Оригінальний творець цієї бібліотеки зображень створив клас доступу до даних, який надає зображення на основі запиту, і це робить це досить швидко для перегляду та індивідуальної картки.
Це також полегшує розгортання / оновлення, коли випускаються нові картки, замість того, щоб накопичувати цілу папку зображень і надсилати їх по трубі та забезпечувати створення належної структури папок, я просто оновлюю базу даних і змушую користувача завантажити її знову. Цей розмір наразі до 56 Мб, що не чудово, але я працюю над функцією додаткового оновлення для майбутніх версій. Крім того, існує версія програми "без зображень", яка дозволяє тим, хто перебуває на комунальній мережі, отримати програму без затримки завантаження.
Це рішення на сьогодні спрацювало чудово, оскільки саме додаток орієнтовано як єдиний екземпляр на робочому столі. Є веб-сайт, на якому всі ці дані архівуються для доступу в Інтернет, але я ні в якому разі не використовував би для цього те саме рішення. Я погоджуюсь, що доступ до файлів був би кращим, оскільки він би краще масштабував частоту та обсяг запитів, що надсилаються для зображень.
Сподіваюсь, це не надто хитрощі, але я побачив цю тему і хотів надати деякі мої уявлення щодо порівняно успішної програми для малого / середнього масштабу.
SQL Server 2008 пропонує рішення, яке має найкраще з обох світів: Тип даних файлового потоку .
Керуйте нею, як звичайна таблиця, і мати продуктивність файлової системи.
Це залежить від кількості зображень, які ви збираєтесь зберігати, а також їх розмірів. Я використовував бази даних для зберігання зображень у минулому, і мій досвід був досить хорошим.
IMO, плюси використання бази даних для зберігання зображень,
A. Вам не потрібна структура FS для зберігання зображень
B. Індекси баз даних працюють краще, ніж дерева дерев FS, коли потрібно зберігати більшу кількість елементів
C. Розумно налаштована база даних виконує хорошу роботу при кешуванні результатів запиту
D. Резервні копії прості. Він також добре працює, якщо у вас налаштована реплікація і вміст доставляється з сервера, близького до користувача. У таких випадках явна синхронізація не потрібна.
Якщо ваші зображення будуть невеликими (скажімо, <64k), а система зберігання вашого db підтримує вбудовані (записуючі) BLOB, це ще більше покращує продуктивність, оскільки не потрібно ніяких опосередкованих дій (досягається локальність посилання).
Зберігання зображень може бути поганою ідеєю, коли ви маєте справу з невеликою кількістю зображень величезного розміру. Ще одна проблема зі збереженням зображень у db полягає в тому, що такі метадані, як створення, дати модифікації повинні оброблятися вашою програмою.
Нещодавно я створив додаток PHP / MySQL, який зберігає файли PDF / Word у таблиці MySQL (до цих пір становить 40 Мб на файл).
Плюси:
Мінуси:
Я б назвав мою реалізацію успішною, вона піклується про резервні вимоги та спрощує макет проекту. Продуктивність прекрасна для 20-30 людей, які використовують додаток.
Своїм досвідом мені довелося керувати обома ситуаціями: зображеннями, що зберігаються в базі даних, та зображеннями у файловій системі із шлях, що зберігається у db.
Перше рішення, зображення в базі даних, є дещо «чистішим», оскільки ваш рівень доступу до даних повинен мати справу лише з об’єктами бази даних; але це добре лише тоді, коли вам доведеться мати справу з низькою кількістю.
Очевидно, що продуктивність доступу до бази даних, коли ви працюєте з великими двояковими великими об'єктами, принижує якість, а розміри бази даних зростуть значно, що призведе до знову втрати продуктивності ... і, як правило, простір баз даних набагато дорожчий, ніж простір файлової системи.
З іншого боку, великі бінарні об'єкти, що зберігаються у файловій системі, спричинить у вас резервні плани, які повинні враховувати як базу даних, так і файлову систему, і це може бути проблемою для деяких систем.
Ще одна причина для пошуку файлової системи - це коли вам потрібно ділитися своїми зображеннями (або звуками, відео, будь-яким іншим) з стороннім доступом: в цей час я розробляю веб-додаток, який використовує зображення, до яких потрібно отримати доступ "ззовні" "моя веб-ферма таким чином, що доступ до бази даних для отримання бінарних даних просто неможливий. Тож іноді виникають і дизайнерські міркування, які спонукають вас до вибору.
Також, враховуючи цей вибір, якщо вам потрібно мати справу з дозволом та автентифікацією під час доступу до бінарних об'єктів: ці реквізити зазвичай можна вирішити більш простим способом, коли дані зберігаються у db.
Я колись працював над додатком для обробки зображень. Ми зберігали завантажені зображення в каталозі, який був на зразок / images / [сьогоднішня дата] / [номер ідентифікатора]. Але ми також витягли метадані (дані exif) із зображень і зберегли їх у базі даних, разом із часовою міткою тощо.
У попередньому проекті я зберігав зображення у файловій системі, і це спричинило багато головних болів із резервними копіями, реплікацією та виведенням із системи синхронізації з базою даних.
У своєму останньому проекті я зберігаю зображення в базі даних і кешую їх у файловій системі, і це працює дуже добре. У мене поки що проблем не було.
Друга рекомендація щодо шляхів до файлів. Я працював над декількома проектами, які потребували управління великими колекціями активів, і будь-які спроби зберігати речі безпосередньо в БД призводили до болю та розладу довгостроково.
Єдиний справжній "професіонал", про який я можу подумати щодо їх зберігання в БД, - це потенціал простоти використання окремих зображень. Якщо шляхи до файлу не використовуються, а всі зображення передаються прямо з БД, немає небезпеки, щоби користувач знайшов файли, до яких не повинен мати доступ.
Схоже, краще було б вирішити посередницький скрипт, який витягує дані з веб-недоступного файлового сховища. Таким чином, зберігання БД дійсно не потрібно.
Слово на вулиці полягає в тому, що, якщо ви не продавець баз даних, який намагається довести, що ваша база даних може це зробити (як, скажімо, Microsoft, що вихваляється тим, що Terraserver зберігає мільярд зображень на SQL Server), це не дуже гарна ідея. Коли альтернатива - зберігання зображень на файлових серверах і шляхах у базі даних, набагато простіше, навіщо турбуватися? Польові кульки схожі на позашляхові можливості позашляховиків - більшість людей їх не використовує, ті, хто зазвичай потрапляє в біду, а є і такі, хто це робить, але тільки заради цього.
Збереження зображення в базі даних все ще означає, що дані зображення закінчуються десь у файловій системі, але затемняються, щоб ви не мали доступу до нього безпосередньо.
+ ves:
-вес:
Обидва методи є загальними і практичними. Погляньте на переваги та недоліки. Так чи інакше, вам доведеться подумати про те, як подолати недоліки. Зберігання в базі даних зазвичай означає налаштування параметрів бази даних та реалізацію певного кешування. Використання файлової системи вимагає знайти спосіб синхронізації файлової системи + бази даних.