Comments 38
всё в основном затевалось ради уменьшения нагрузки на дисковую подсистему
И вправду уменьшилось? За счёт чего? Как сильно?
что добавляет лишнюю операцию: сначала читаем из БД, после чего записываем копию на диск
Общая нагрузка вырастет, поскольку ACID в базах данных достигается достаточно дорогой ценой большего использования диска/памяти/cpu.
Не стану спорить, что в современных СУБД кеширование реализовано отлично и за счёт этого вы получаете более отзывчивую систему. Но вместе с этим вы получаете слишком большую побочную нагрузку, из-за чего с ростом нагрузки и количества blob вы замедлитесь раньше и сильнее, чем при использовании других подходов к хранению.
Общая нагрузка вырастет, поскольку ACID в базах данных достигается достаточно дорогой ценой
Совершенно согласен, накладные расходы в случае БД окажутся несколько выше, о чём, собственно, уже писал ниже:
описанное решение даже в самом распрекрасном случае будет лишь на уровне ФС, т. к. она, по определению, и создана для наилучшего обращения с файлами
Не упрёка ради, а прояснения для, Ваши изначальные вопросы скорее всего появились из-за беглого прочтения статьи, потому что в этом проекте изображения сразу, изначально находились в базе, поэтому не получится сравнить сделанную оптимизацию с иным способом хранения.
И на всякий случай повторюсь:
Материал не про выбор места хранения, а про неизвестный многим способ извлечения файлов из БД, когда выбор уже сделан не в пользу ФС.
поставить reverse-proxy с кешем перед веб-сервером и отдавать данные картинки прямо из БД (например, кодируя ид в имени файла) и нагрузка на дисковую подсистему именно на операциях чтения картинок упадёт до пренебрежимо малых значений. Такое решение вполне универсальное.
И каково это, использовать унигуй? Как работает? Какие нюансы?
На Ваш вопрос наиболее полезно смогут ответить те, кто применяет uniGUI по прямому назначению — переносят настольное приложение в веб, например.
IIS, Delphy, картинки в бд? Ребята, куда то вы не туда свернули.
А куда стоило по вашему мнению? Пойти по дорожке React/Vue и NodeJS? PWA? Или сдуть пыть с Java Servlet?)
Для начала нормальный веб-сервер взять. Там нет поддержки делфи? Странно, дайте ка подумать почему? Наверное потому потому что никто не пишет на нем сайты? А если пишет, то, наверное, должен понимать очень хорошо этот инструмент? Иначе в ноги настрелаешь. Но судя по тому что уперлись в раздачу картинок складывается впечатление о не очень хорошем понимании работе http и понимании важности асинхронных файловых операций. Упереться в файловые операции? Не в нагрузку на хостинг? Черт подери, да как это можно сделать специально?)) На винде емнип файловые операции медленнее чем на линухе если бенчмарками заниматься.
В данном случае фронтом является uniGui, что совсем "не любой", а тот что позволяет вообще не думать о верстке и веб части в принципе.
Для начала нормальный веб-сервер взять.
Зачем? Насколько я понял IIS нужен чисто как файловое хранилище. Если его возможностей достаточно, нужно ли плодить сущности без необходимости? Не думаю.
Там нет поддержки делфи? Странно, дайте ка подумать почему? Наверное потому потому что никто не пишет на нем сайты?
Чувствуется не предвзятое и взвешенное мнение. :)
Апач + мод реврайт + правила в .ht* + простейший скрипт и можно любой элемент сайта засунуть в базу. Хоть весь сайт. Останется только индекс как единая точка входа. Проверено)
посмотрите в сторону minio
Ох уж эти сказочники...
На практике столкнулся с таким "суперским" хранением.
Затейник уже давно не работал в компании, а вот БД выросла до 2ТБ, и к моменту моего прихода продолжала рост и как следствие имела жуткие тормоза.
Реорганизация системы хранения разом избавил от всех этих напастей. Да самих полезных данных в БД осталось 0,5% от первоначальных, остальное стало обычными файлами.
В заключение осталось привести новый, значительно облегчённый по сравнению с предыдущим вариантом, код, ибо из БД уже не нужно извлекать само изображение – достаточно лишь получить имя файла с ним (из поля dbo.AlbumCover.name, имеющего в примере псевдоним CoverFileName) и в неизменном виде подставить в атрибут src
прямо напрашивается сравнение вашего решения с обычными файлами в файловой системе
Если же речь шла про сравнение производительности, то описанное решение даже в самом распрекрасном случае будет лишь на уровне ФС, т. к. она, по определению, и создана для наилучшего обращения с файлами. Статья же затрагивает вариант, когда они по какой-либо причине находятся в базе данных и требуется повысить эффективность работы с ними.
для стороннего наблюдателя файлы из FileTable и выглядят как настоящие файлы из любой реальной директории
А зачем это всё?
Можно ведь просто сделать <img src="get_file.php?id=123456">, а там простым скриптом брать из базы и возвращать (наверно можно и на asp так же). Без всякой записи в файлы и т.п.
Надо просто хранить картинки нормально на диске, в нормальной структуре с нормальными именами, а в бд хранить или пути к ним или id.
Отображение делать через прокси какой нибудь imgproxy.net и вопрос каких либо изменений, кеширования, закрыт.
Статья же затрагивает вариант, когда они по какой-либо причине находятся в базе данных
ну вот мне и непонятны эти причины
Можно использовать любой S3-совместимый storage или другой тип CDN с нормальным API и нет проблемы с нагрузкой на ФС, заодно и быстрее работать будет, т.к. грузиться будет с ближайшего сервера.
А есть ли вообще преимущество при хранении картинок в БД?
Прикольно. Я вот не знал про такую технологию у MS SQL сервера. Она вряд ли пригодится, но для общего развития интересно. У нас картинки хранятся на диске. В базе только их имена.
Для этого надо было:
использовать PHP
хранить картинки в файлах
настроить кеш
отдавать, если не хочется светить имя файла, через параметр скрипта, без всякой возни с настройкой сервера:
<img src="covers.php?3AE39458-8925-448A-A5F1-0C0A4524ACF0.jpg">
Использовать устаревшие и неподходящие технологии -- это как, хм, танцевать в гамаке и в ластах: можно, сложно, вызывает удивление окружающих, но вряд ли кому-то нужно.
Статья, конечно, хорошая... Но не нужно так делать ни в коем случае!!!
База данных - это не файловое хранилище. Если хранить файлы в БД, вы потом задолбаетесь с бэкапами и репликацией данных как минимум. Плюс есть нехилая вероятность, что закончится место на диске и встанет вообще все приложение (а не только загрузка файлов).
Хотите быстро-просто? Храните описания файлов в базе, а содержимое где-нибудь в S3, благо этот протокол много где поддерживается и не завязан целиком на Amazon (можно взять тот же minio, например).
А если хотите получить реальную экономию I/O, то лучше смотрите в сторону HTTP заголовков кеширования и ETag.
А data:uri + base64 нельзя было?
Можно было просто cloudflare бесплатный использовать
Прочитав статью, я так и не понял, так смогли ли дрим театровцы в Six Degress... достигнуть новых вершин, или же предыдущий Metropolis II - это конец, вершина их творчества? В смысле, где же лучше хранить файлы?
Несомненно смогли. Второй диск - прекрасен, на мой взгляд. Да и дальше есть хорошие альбомы, как минимум Train Of Thought и Octavarium ещё весьма торты.
Обожаю бэкапить базы с картинками, видео и другой фигнёй...
Хранение изображений сайта в БД