Добрый день.
Уважаемые гуру, прошу Вашего совета по следующему вопросу.
1С 8.3, управляемое приложение, клиент-серверный режим работы.

Специфика работы склада и 1С такова, что для номенклатуры требуется хранение большого количества фотографий поступающих на склад товаров.
Фотографии делаются из-под 1С внешней WEB-камерой. Все полученные изображения товаров хранятся также в базе, что естественно, со временем приводит к ее раздуванию до больших размеров. Собственно пока товаров было не шибко много, это особо не напрягало, но сейчас ассортимент номенклатуры растет и база "пухнет" на глазах (уже перевалила за 10Гб, и 99% это как раз фотографии товаров).

Я хотел бы услышать совет, как лучше (и где) в данном случае организовать хранение изображений товаров. Т.е. как лучше всего построить взаимосвязь между справочником Номенклатура и прилагаемыми к каждому элементу справочника изображениями товаров?

Заранее благодарен за информацию.

Фотки хранить в файлах, для загрузки в 1С дать им имена, например <КодНоменклатуры_№фото>.

Храни в файлах. В базе храни ссылки на файлы.
Более лучший вариант - сделать вебсервис или отдельную базу и хранить там.

Если фотки используются только в 1с то банальная папка с файлами является лучшим решением.

>>уже перевалила за 10Гб.
Мне бы такое счастье

(4) +1

(0)гигов до 200 можешь не волноваться. База у вас пока микроскопическая.

А хранить их в базе это вообще хреново.
Почему то как в 1с появилась возможность хранить файлы в базе, все резко начали думать что надо обязательно хранить их там. А база данных все таки не предназначена для хранения файлов, хотя такая возможность и имеется.

(1) +100500

(6) серьезно? Но уже очень не удобно, все равно я думаю, что 30Гб это наверное уже предел.

(1) (2) (3) ну собственно так и думал. Таким образом создаю папку, в ней подпапки и уже туда раскидываю все фото, благо на сервере места предостаточно. В справочнике храню только ссылку на фотографии на диске.

Еще один момент - очень часто бывает что разные товара имеют одно и тоже фото.
Если держишь в базе, то тебе надо хранить их все.
Если файлы лежат в папке - достаточно одного файла. В базе будет просто несколько ссылок на файл.

(9)А зачем тебе подпапки? Хватит одной директории, так проще и удобней.
Просто свали их в кучу.

(9)Это у меня сейчас одна из баз
https://yadi.sk/i/YgekiLkAcQ9Gx

ничего, живем как то:-)

(10) Нет, у меня 100% уникальность фотографий, одинаковых не бывает.
Ну там полная куча мала мала будет со временем - мильен фотографий, запутаешься (в день делается около 500 фото). Лучше наверное все таки аккуратно разложить по подпапкам, например, обозвав их текущей датой.

(11) мелочь какая-то.... )))

(11) Как же Вы backUp делаете? Сутки?

(13)Мне хватает :-)

(14)Да нет, скулем я снимаю полный гдето за час с чем то.Но зато потом его скопировать себе на комп- часа 3 :-)

А про .dt и не вспоминаем.:-)

(12) цель-то какая? ты ни одной причины не указал для всех этих телодвижений

(12)Что значит запутаешься? Ты что с ними работать собрался?
Я так понимаю эти файлы - фотографии номенклатуры.
И работать с ними будет исключительно программа, а не человек.
Для человека конечно удобней разложить их по папкам, а для программы удобней работать с с одной папкой.

(17) я указал цель в первом сообщении темы.
Для всех поступающих и регистрирующихся на складе товаров, WEB камерой делаются их фотографии. Ежедневно около 500 фото.

До настоящего момента все изображения хранились в базе. Знаю сам и как уже подсказали (7) это не правильно. Вот и ищу метод как лучше организовать хранение.

(18) Спасибо. Вы похоже действительно правы.

(19) Очень рекомендую перед попыткой что-то сделать проверить как сервер будет работать с папкой в которой 100500+ файлов.

(20)А в чем проблема то? Прекрасно будет работать.

Т.е скорость работы с файлами не зависит от их колчиества в папке.
Так что сервер будет одинаково работать с папкой в которой 10 файлов, и с папкой в которой десять миллионов файлов.

(21) даже если изображений будет миллион?

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

(23)Хоть десять.

Всем большое спасибо за мнения и советы.
Приступаю к реализации.
Спасибо!

(24)Вы вообще представляете что такое папка? И как ОС ищет файлы?
Вы вероятно говорите про проблемы открытия в эксплорере папки с кучей файлов - такая проблема есть. Это вполне логично - одна программа обращается к тысячам файлов.
Но в 1с то не надо обращаться к тысяче файлов, ей надо открыть 1файл.

Некоторые люди считают что файлы хранятся в папках.
Это не верно.
Папок как таковых вообще нет, это просто абстракция удобная для человека.
Все файлы лежат на диске, в одной куче, они никак не упорядочены по папкам.
Папка это всего лишь свойство файла.
И когда пользователь открывает папку с миллионом файлов, то операционная система ищет все файлы имеющие в свойствах эту папку, и выводит их список, выполняя при этом кучу работы, считывает их атрибуты.
Понятно что это будет долго.
А когда нужно открыть 1 файл  неважно принадлежит он папке или нет, и сколько еще файлов принадлежат этой папке, их программа искать не будет.

(28) Все предельно ясно. Спасибо.

(27) Не упрощайте. Для открытия ОДНОГО файла из папки нужно найти его начальные кластеры с помощью чтения каталога.  При миллионах записей это было бы вообще дико тормозно, если бы в современных ФС (в частности NTFS) не было индексирования каталога. И тогда мы приходим к выводу - принципиальной разницы между хранением файлов в базе и в каталоге нет, ибо ФС - такая же база, только более узкоспециализированная..

(7) полный бред  :)
Автор - не нужно париться с размером БД, данная СУБД спроектирована для работы с ооочень большими данными. А ваши масштабы - это мизер, будьте уверены.
Чисто практически - когда все храниться в одном месте, т.е. все в самой БД гораздо меньше заморочек с изготовлением резервных копий.
А вот когда части БД физически разделены - вот настоящая головная боль. Вы это ощутите, когда вам придётся (не дай бог конечно) восстанавливать инфраструктуру БД с нуля. Я это уже прошёл и никому не пожелаю.
Вердикт - ВСЕ ХРАНИТЬ В САМОЙ БД !!!

Я бы сделал отдельную базу "хранилище файлов" и работал с ней через COM.

(32) НАХРЕНА ???
Чтобы быстродействие снизить по максимуму ?

(30)Для открытия одного файла нужно найти начальные кластеры одного файла, их адрес добывается из базы данных файловой системы, где проиндексированы все файлы которые хранятся в ФС.

А вот если вы открываете какталог - то нужно найти все файлы входящие в этот каталог, а потом найти начальные кластера для всех файлов.

В первом случае это делается для одного файла
Во втором для всех файлов каталога.

Когда вы работаете с файлом программно, вы не открываете каталог, вы получаете сразу файл.

(32) А я не морочу голову и храню всё в базе. Максимум что можно сделать, это организовать отдельные файловые группы, чтобы основную базу держать на SSD, а картинки - на HDD. Максимальный размер базы SQL - 524272 ТБ. Я до него ещё не скоро доберусь.

Существует множество различных баз данных, с разным функционалом, и разными предназначениями.

Для работы с файлами сделаны специальные базы данных  они называются - файловая система.
Так вот эта БД заточена именно под работу с файлами, и наиболее эффективно с ними работает.

А скуль вообще то заточен под работу не с файлами, а с записями. Запихать туда файлы особой проблемы не представляет, но вот ожидать что она будет работать с ними эффективно не стоит, ибо она для этого не предназначена.

(0) Лучше всего в файлах, а в БД хранить только ссылки

+(37) Но если файлов мало, то можно и в БД :)

Если файл хранится на диске
1с запросила файл у ФС, ФС нашла и отдала файл.
Если файл хранится в базе
1с запросила файл у БД, БД запросила чтение куска файла в котором она размещается у ФС, ФС отдала кусок файла БД, та выдернула из него данные и отдала 1с.

В результате куча ненужных телодвижений.

(38)Разумеется если у тебя сотня небольших файлов, то можно не париться и хранить их в БД, это не оптимально с точки зрения производительности системы, но удобнее человеку.

Но если файлов много, то начинает падать и производительность, и появляться куча других проблем.

(39) Нет принципиальной разницы, где именно хранится каталог - в sql-базе или в блоках файловой системы на диске. В обеих случаях нужно прочитать с диска данные в примерно одинаковом объеме. Да, sql-база имеет больше накладных расходов, но эти расходны намного более низкого порядка, чем физическое чтение с диска.

(18) Ну, после 100 тыс. файлов в одной папке начинаются тормоза с поиском конкретного файла...

(42) Даже Microsoft говорит, что если вы храните более 300000 файлов в папке, то нужно делать дополнительный тюнинг настроек NTFS. Только у уважаемого Джампа всё отлично работает с 10000000 файлов.

(22) Пробовал? Эта папка будет дико фрагментирована, что в случае с HDD будет означать, что на поиск одного из последних файлов в папке при непопадании в кеш будет уходить довольно заметное количество времени. Как дискового, так и процессорного. Ну и при добавлении будет то же самое.

(27) Для этого ей надо его сначала найти на диске.

(28) Если бы ты знал, какой конкретно файл из всей этой кучи тебе нужен - да. А иначе придется сначала поискать этот файл в папке. Потому что ты знаешь только его путь через папку.

(31) А вот тут весьма спорно. Очевидно, что файлы можно забэкапить 1 (один) раз. А БД придется бэкапить КАЖДЫЙ раз в полном объеме.

(34) Ну да, в случае открытия 1 файла из объемной папки требуется 2-3 секунды. В случае открытия этой папки - несколько минут (что, кстати, придется все равно делать для бэкапа). Но ведь проблема в том, что и 2-3 секунды - долго. Особенно если пользователей много. А когда разбросано по папкам - все гораздо быстрее выполняется.

(46) "в случае открытия 1 файла из объемной папки требуется 2-3 секунды"
Ну и где тут преимущество? sql то же самое дает.

(45)На время открытия файла влияет куча факторов.
Но вот объем папки к которой принадлежит файл, и количество файлов в этой папке никак не влияют на скорость открытия файлов.
Т.е файл откроется одинаково быстро если он один в папке, и если их в папке пара миллионов.

а у меня вопрос такой возник: как mssql ведет себя при кешировании данных их базы, где лежат терабайты картинок.
он понимает, что мне эти данные в оперативной памяти нужны в последнюю очередь, или вместо регистров все будет забито картинками?

(48) "файл откроется одинаково быстро если он один в папке, и если их в папке пара миллионов"
Нет. Чтобы найти физическое место расположения файла на диске - нужно найти запись этого файла в его каталоге. Поиск в fat - это O(n), в случае ntfs - o(log n). Фрагментация каталога всё ухудшает на порядки.

(45)По поводу бэкапа - действительно эффективнее получается бэкапить отдельно базу и папку с файлами, нежели файлы в базе.

Только вот забэкапить один раз их не получиться, т.к они добавляются постоянно, но все равно бэкап будет небольшой, обычно же бэкапят инкремент, ну и соответственно база более эффективно будет в бэкап уходить.

(49)Он понимает, что это данные, и они ничем не лучше и не хуже других данных. Поэтому они будут закэшированы наравне с другими данными.
С точки зрения БД они ничем не отличаются от регистра, или справочника.

(52) Вот не уверен. Почти наверняка для кэширования блобов применяется иная политика.

(48) Влияет объем папки. Проверено статистически. В частности, по той причине, что нужно перечитывать в среднем половину куска индекса, относящигося к папке. При добавлении же файла приходится перечитывать весь индекс папки.

С чем можно частично согласиться - хранить файлы в базе sql-сервера, который хранит каждую таблицу или индекс в отдельном файле, неоправдано. А вот в случае нормальных sql-серверов, осиливших свои собственные контейнеры (mssql, oracle, fb/ib) это вполне себе красиво.

(53)Есть механизм, но его надо настраивать, по умолчанию в MS SQL включено насколько я помню.

(55)В любом случае данные хранятся на диске, и с ними работает ФС, даже если это контейнер. За исключением случаев когда контейнер работает напрямую с железом.
Т.е получается дополнительная прослойка.

(56) Опять же, мы не знаем, какая политика кэширования у того или иного sql-сервера. Если банальная lru - то да, блобы будут вымывать из кэша актуальные данные. Но вряд ли разработчики настолько непредусмотрительны)
(57) Оракл умеет хранить базу на физическом разделе диска, как я слышал.

http://stackoverflow.com/questions/446358/storing-a-large-number-of-images

возникает мысль запилить отдельный sql-сервер, со своим блэкджеком, бэкапом и кэшированием, и пихать туда картинки через механизмы внешних источников данных.

(60)Это когда есть специализированная БД предназначенная для хранения файлов?

(61) Кстати.. при разработке висты у микрософта была идейка отказаться от ФС в принципе. Перейти к sql-подобной системе хранения, а для старых приложений эмулировать ФС.

(54)Все конечно зависит от устройства файловой системы.
Везде все по разному устроено.
Например в FAT есть структура папок, и соотвественно индексы папок. Т.е там сначала находится каталог, а потом по индексу каталога находится файл.

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

(62)Что значит отказаться от ФС в пользу БД?
ФС это и есть БД.
И кстати NTFS во многом подобна SQL подобным бд.
В частности индексы на бинарных деревьях.

Давайте теперь потеоритезируем: насколько консистентной будет система хранения изображений в файлах в случае распределенной системы?

(63) Один фиг тебе надо прочитать индекс (в FAT вообще индексов нет, кстати). В среднем - половину его, прежде чем найдется нужный файл (существующий) и полностью все записи индекса, при создании нового файла чтобы убедиться, что нет такого. Ты же к файлу обращаешься не по его номеру, а через путь.

(31) Встречал эту проблему хранения информации не в базе, а в сетевой папке. При проектировании ИБ сделал вариант хранение в базе. Потом другие продвинутые 1С-ники и системщики решили это разделить. Потом админы забыли сделать бэкап файлов, и вдруг "неожиданно" случился сбой. Все электронные документы пропали, а база 1С осталась.

(64) Не.. тут суть в полном отказе от иерархичности. Сохраняешь файл - при сохранении задаешь набор метатэгов, по которым можешь найти его впоследствии. Один из этих метатэгов - имя файла, даты создания, изменения - тоже пишутся в метатэги. Кроме того, дополнительно индексируется содержимое файлов известных типов. А в диалоге открытия ты тупо пишешь поисковый запрос (или выбираешь из заранее созданных масок поиска). Но не осилили или не рискнули.

(68) это уже NoSQL. На монгу очень похоже: там данные json-документами хранятся.

(61) насколько специализированная? у всех средств есть свои ограничения.

хранение в томах нельзя реализовать?

(68) в такой "пепеделке" самое сложное - обеспечить обратную совместимость. Не сложилось.
А "следы" этого мы наблюдаем в виде библиотек в 7 и выше.

Мы сертификаты храним так же в папке на сетевом диске. причем с базой работает несколько филиалов в разных городах. Просто привязано имя файла (он же внутренний номер сертификата) к позиции товара и все. Три года - проблем нет.

один файл фотки в приемлемом качестве примерно 0.3 метра

100 000 файлов это примерно 40 гигов в базе

так, что 1 миллион фоток база вполне может тянуть

(71) так в 1с "тома" - это и есть хранение файлами на диске. Посмотри справочники "Файлы" и "ТомаХраненияФайлов"

Лучше фото хранить отдельно , база будет быстрей бэкапиться и ресториться когда мухи будут отдельно. А бэкапить фотки можно и пореже , например раз в неделю.

Сейчас посмотрел инфу по базе, где хранится больше всего картинок: ~43'000 файлов, занимают ~3.8 гб. Используется 1с-ный механизм "томов".
База клиент-серверная, файлы лежат на отдельном от данных массиве, напрягов в общем-то не ощущается.
Но всегда интересно узнать альтернативные мнения.

(0) Тут несколько не продуман процесс. Какое бы решение не предлагали, это приведет только к временному улучшению.
Надо обговорить с бизнесом какой то процесс утилизации неактуальных фоток из базы. Наверняка не все фотки одновременно нужны всегда и прямо сейчас.
Например проклассифицировать их как то по нужности. Самые редконужные - на ленту, менее нужные на файлсервер, самые нужные в БД. Ну или еще чего придумать.

(78)А смысл?
Во первых зачем удалять фотки? Фотка привязана к номенклатуре.
Удалил номенклатуру - удалил фотку.
Фотки нужны когда идет обращение к фотке, а оно может быть когда угодно. Т.е нужны они прямо сейчас.
На ленту это вообще нечто.
Лента это устройство длительной архивации, на ленту пишут то что скорее всего не понадобиться никогда, бэкапы длительного хранения. Если ты планируешь обращаться к файлу раньше чем через год, на ленту смысла нет писать, да и уходят уже ленты в прошлое.
Раскидывать фотки по файл по всей сети это вообще песец.
Как ты их архивировать будешь? Как за целостностью следить?:

(78) вот на фейсбуке все фотки хранят и норм

качаешь exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/index.html
потом:

C:\>exiftool "-Directory<DateTimeOriginal" -d "%Y/%m/%d" %каталог с фотками%

(81)Не совсем понятно зачем работать с exif

(79) >>Фотки нужны когда идет обращение к фотке, а оно может быть когда угодно
Вот кто обращается к фотке, что он там пытается разглядеть на ней и с какой целью? Будет ответ, а там будет видно что делать