Когда вы сохраняете свои изображения (предположим, что у вас их много), вы сохраняете их как капли в своей базе данных или в виде файлов? Зачем?Сохранение изображений: файлы или капли?
Дубликат: Storing Images in DB - Yea or Nay?
Я обычно хожу с хранением их в виде файлов, и сохранить путь в базе данных. Для меня это намного проще и естественнее, чем вставлять их в базу данных как капли.
Один аргумент для их хранения в базе данных: гораздо проще делать полные резервные копии, но это зависит от ваших потребностей. Если вам нужно легко получить полные снимки вашей базы данных (включая изображения), то, возможно, сохранить их в виде блоков в базе данных. В противном случае вам нужно соединить резервную копию базы данных с резервной копией файлов и как-то попытаться связать их, чтобы, если вам нужно сделать восстановление, вы знаете, какую пару восстановить.
Если я работаю на одном веб-сервере и буду работать только на одном веб-сервере, я храню их как файлы. Если я запускаю несколько веб-узлов, я помещаю ссылочный экземпляр изображения в базу данных BLOB и кеширую его как файл на веб-страницах.
Это зависит от размера изображения.
Microsoft Research имеет interesting document на тему
Резюме этого документа состояло в том, что файловая система (ntfs) имеет тенденцию работать лучше с файлами размером более 1 МБ, а db лучше работает с файлами размером менее 1 Мб (чем меньше, тем лучше). – sjdirect
То, что бумага с 2006 года, это уже 11 лет назад. Поэтому сегодня все может быть иначе. И на самом деле вывод заключается в следующем: «(...), если объекты в среднем превышают 1 мегабайт, NTFS имеет явное преимущество перед SQL Server.Если объекты находятся под 256 KiB, база данных имеет явное преимущество. Внутри этого диапазона это зависит ... » –
Blobs может быть тяжелым на дб/скрипты, то почему бы не просто хранить пути. Единственная причина, по которой мы когда-либо использовали blobs, - это то, что нужно объединить реплицированную или сверхтекущую защиту для активов (как в cant pull-изображении, если вы не вошли в систему или что-то в этом роде)
Вам нужно, чтобы мне была« супер надежная защита ». Поэтому я думаю, что лучше всего использовать blob для защищенных документов, таких как налоговые декларации, нет? Тогда все небезопасные элементы, такие как изображения и т. Д. , может быть в папке с файлами? – user982853
Учитывая, что вы можете сохранить изображение вместе с имя, краткое описание, созданная дата, созданная и т. д., вам может быть лучше сохранить в базе данных. Таким образом, все вместе. Если вы сохранили эту же информацию и сохранили изображение в виде файла, вам придется извлечь весь «объект изображения» из двух мест ... и по дороге вы можете столкнуться с проблемами синхронизации (некоторые изображения не найдены) , Надеюсь, это имеет смысл.
Сохраните его, чтобы использовать их для показа на веб-странице или что-то в этом роде? Если это так, лучшим вариантом будет использование файлов, если вы используете базу данных, он будет постоянно забиваться с запросом на фотографии. И это ситуация, которая не слишком хорошо масштабируется.
Нет изображений. Это только документы, связанные с транзакциями, поэтому ничего, что можно было бы вытащить каждый раз, когда кто-либо посетил сайт, как логотип или что-то в этом роде. Это клиентские документы, и единственный раз, когда они будут снесены, будь то профессионал или клиент, чтобы просмотреть их. – user982853
Я попытался использовать db (SQL Server и MySQL) для хранения файлов (< 5mb), и у меня было много неприятностей.
1) Некоторые DB (SQL Server Express) имеют ограничения по размеру;
2) Некоторые DB (MySQL) становятся смертельно медленными;
3) Когда вам нужно отобразить список объектов, если вы случайно сделали таблицу SELECT * FROM, тонны данных будут пытаться подниматься и опускаться с db, что приводит к аварийному медленному отклику или сбою памяти;
4) Некоторые интерфейсы (ruby ActiveRecord) имеют очень большие проблемы с манипуляциями с каплями.
Просто используйте файлы. Не храните их все в одном каталоге, используйте некоторую технику, чтобы разместить их на нескольких серверах (например, вы могли бы использовать последние два символа GUID или последние две цифры идентификатора int), а затем сохранить путь на db.
Вы продали меня на 'SELECT * FROM table' - я использую это периодически для тестирования, и это само по себе может вызвать у меня массивную головную боль. Файлы для меня! – rybo111
Вопрос в том, что ваше приложение обрабатывает BLOBS или другие файлы, такие как другие данные приложения? Ваши пользователи загружают изображения вместе с другими данными? Если это так, тогда вы должны хранить BLOB в базе данных. Это упрощает резервное копирование базы данных и, в случае возникновения проблемы, восстанавливать транзакционное состояние.
Но если вы имеете в виду образа, которые являются частью infratstructure приложения, а не пользовательские данные, то, вероятно, ответ, №
Хит производительности сервера баз данных является спорным вопросом. Если вам нужны преимущества производительности файловой системы, вы просто кешируете ее там по первому запросу. Затем последующие запросы могут быть поданы непосредственно из файловой системы по прямой ссылке (которая в случае веб-приложения вы можете переписать HTML-код перед тем, как очистить выходной буфер).
Это обеспечивает лучшее из обоих миров:
Не нужно постоянно забивать базу данных для вещей, которые не будут меняться постоянно, но важно то, что пользовательские данные все там и не разбросаны по разным местам, что делает работу с несколькими серверами и развертывание полного беспорядка. Я всегда выступаю за «базу данных как хранилище пользовательских данных, если только» не подходит, потому что это лучше архитектурно и не обязательно медленнее с эффективным кэшированием.
Сказав это, хорошей причиной для использования файловой системы в качестве авторитетного магазина было бы, когда вам действительно нужно использовать внешние независимые инструменты для доступа к нему, например. SFTP и еще много чего.
Если у вас есть веб-приложение, файлы - это путь, вы создаете HTML с информацией о пути из базы данных, которая указывает на файл, который хранится там, где браузер клиента будет сбрасывать его. –
Я создаю автономное приложение. Я обнаружил, что сохранение blob позволяет легко реплицировать базу данных. Просто мысль! –
Я написал небольшую систему доставки и закрепил изображения в базе данных. Как только он добрался до большого размера, резервные копии базы данных стали очень проблематичными (30 000 изображений). В конце концов база данных и любой запрос, возвращающий изображения, останавливаются. У SQL-сервера базы данных были серьезные проблемы, и он должен был очистить кэш запросов, чтобы исправить это. В конце концов я в конечном итоге реорганизовал его. Добавление бит управления дисками стоило того, и я больше никогда не добавляю изображение в базу данных SQL Server. – Skarsnik