Black Friday: Cashback 35% при покупке 1С лицензий на счет INFOSTART.RU

1. Port111 08.11.19 12:48 Сейчас в теме

Как лучше хранить фото для Веб версии? На диске или в ХранилищеЗначения?

Здравствуйте.
Имеется маленькая самописная конфигурация. Там хранится информация об объектах и фотографии к ним.
Используется в основном через Веб и мобильный клиент.
База файловая, так как очень маленькая и работает достаточно шустро.
Но фото делаются на мобильный и выводятся на форму. В моем случае каждое фото с мобильника весит по 16 мб, а их штук 5 на каждой форме.
При хранении их в ХранилищеЗначения грузятся очень долго, пробовал и хранить на диске, но прироста производительности не дало.
Я понимаю что просто каждый раз фото грузиться по инету и из-за этого такая задержка...
Но все таки,
1. Как быстрее работает открытие фотографий (если не учитывать доступ по инету) из ХранилищаЗначений или из файла на диске?
2.Как лучше на практике хранить? Ведь если я храню в каталоге временных файлов то при выгрузке в *.dt все фото потеряются, ну и есть большая вероятность и потерять при других обстоятельствах... Если храню в Хранилище Значения то растет размер базы...
2.1 повлияет ли увеличение размера базы на общую производительность базы?
3. Есть ли способ кэшировать фото на клиенте, чтобы они каждый раз не грузились по сети?
4. На сколько в моем случае решит проблему переход на серверную БД?
5. На фото обычно текстовые файлы, чеки и т.п. Тоесть Хотелось бы чтоб они были хорошо читаемы, но может можно оптимизировать размер фото средствами 1С без сильное потери читаемости?

Ну может есть еще какие нибудь советы по оптимизации данной проблемы.

Заранее спасибо...
Найденные решения
12. ice-net 18 11.11.19 12:34 Сейчас в теме
(1)

1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.

2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.

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

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

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

5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.

Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
Остальные ответы
Избранное Подписка Сортировка: Древо
6. TODD22 18 08.11.19 13:31 Сейчас в теме
(1)
Но фото делаются на мобильный и выводятся на форму. В моем случае каждое фото с мобильника весит по 16 мб, а их штук 5 на каждой форме.

Я так одну базу в 70Гб чистил. Там торговые представители сохраняли фотографии выкладки майонеза и кетчупа в магазинах..... На 69Гб фотографий натолкали в базу. Уже давно майонез весь съели, а фотографии хранили....
7. Port111 08.11.19 13:41 Сейчас в теме
(6)
Я так одну базу в 70Гб чистил. Там торговые представители сохраняли фотографии выкладки майонеза и кетчупа в магазинах..... На 69Гб фотографий натолкали в базу. Уже давно майонез весь съели, а фотографии хранили....


Это влияет на скорость работы базы? Мне просто не критичен сам размер базы... Пусть хоть 300 Гб, если летать также будет.
8. TODD22 18 08.11.19 13:44 Сейчас в теме
(7)
Это влияет на скорость работы базы?

В моём случае это влияло на скорость создания резервных копий и восстановление.
Да и смысла не было хранить этот мусор в базе.
9. VmvLer 08.11.19 13:49 Сейчас в теме
(7) вы работали с базой от 300 гб с торг. представителями, веб и моб клиентами или просто так балаболите?
10. TODD22 18 08.11.19 14:00 Сейчас в теме
(7)
Пусть хоть 300 Гб, если летать также будет.

У вас база файловая. Не знаю как она у вас будет работать если в неё натолкать фотографий, будет или нет влиять ограничение на размер таблиц, не знаю как там внутри хранятся данные помещённые в хранилище.
11. noprogrammer 195 09.11.19 12:42 Сейчас в теме
(1)
1.Хранить фото в базе конечно удобно, но это всегда будет медленнее (т.к. запись в базу сама по себе медленная) чем на диске.
2.На диске не обязательно хранить в темповской папке, можно создать свою папку и в ней хранить.
3.Для удобного хранения на диске достаточно имя файла задавать как GUID объекта базы данных к которому относиться это файл - тогда при выгрузке\загрузке *DT ничего не потеряется.
12. ice-net 18 11.11.19 12:34 Сейчас в теме
(1)

1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.

2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.

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

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

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

5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.

Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
2. VmvLer 08.11.19 12:49 Сейчас в теме
3. Port111 08.11.19 12:52 Сейчас в теме
(2)
в облаке


А в чем здесь преимущество? По сути на том же серваке где лежит база и поднят Веб-сервер, там поднято и облако. Могу заливать фото туда, канал там отличный. Но как это решит проблему? Я так понимаю фото в виде файла из облака сначала будет заливаться во временноеХранилище (то есть в базу), а потом из базы будет заливаться клиенту. Или нет?
5. VmvLer 08.11.19 13:29 Сейчас в теме
(3) я дал совет как вы просили, а что из этого выйдет решайте сами.

мое мнение хранить в БД котиков бред
4. Port111 08.11.19 13:05 Сейчас в теме
Или можно хранить в облаке, а на форму выводить фото по прямой ссылке? Но необходимо что бы фото сразу выводилось, то есть был предпросмотр миниатюры на форме
13. Port111 12.11.19 10:13 Сейчас в теме
Всем спасибо. Много дельной информации....
Сейчас попробую реализовать загрузку в облако WebDAV, и отображение напрямую по ссылке, ну и точно опробую вариант с оптимизацией фото, думаю что средствами настройки камера телефона. Видел статейку что можно менять параметры разрешения и качества снимка в 1С
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Администратор БД 1С
Санкт-Петербург
зарплата от 100 000 руб.
Полный день

Программист 1С Документооборот
Санкт-Петербург
зарплата от 110 000 руб.
Полный день

Программист 1С БП / ЗУП
Санкт-Петербург
зарплата от 110 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист/Cтарший программист 1С
Москва
зарплата от 100 000 руб. до 250 000 руб.
Полный день