Как лучше хранить фото для Веб версии? На диске или в ХранилищеЗначения?
Здравствуйте.
Имеется маленькая самописная конфигурация. Там хранится информация об объектах и фотографии к ним.
Используется в основном через Веб и мобильный клиент.
База файловая, так как очень маленькая и работает достаточно шустро.
Но фото делаются на мобильный и выводятся на форму. В моем случае каждое фото с мобильника весит по 16 мб, а их штук 5 на каждой форме.
При хранении их в ХранилищеЗначения грузятся очень долго, пробовал и хранить на диске, но прироста производительности не дало.
Я понимаю что просто каждый раз фото грузиться по инету и из-за этого такая задержка...
Но все таки,
1. Как быстрее работает открытие фотографий (если не учитывать доступ по инету) из ХранилищаЗначений или из файла на диске?
2.Как лучше на практике хранить? Ведь если я храню в каталоге временных файлов то при выгрузке в *.dt все фото потеряются, ну и есть большая вероятность и потерять при других обстоятельствах... Если храню в Хранилище Значения то растет размер базы...
2.1 повлияет ли увеличение размера базы на общую производительность базы?
3. Есть ли способ кэшировать фото на клиенте, чтобы они каждый раз не грузились по сети?
4. На сколько в моем случае решит проблему переход на серверную БД?
5. На фото обычно текстовые файлы, чеки и т.п. Тоесть Хотелось бы чтоб они были хорошо читаемы, но может можно оптимизировать размер фото средствами 1С без сильное потери читаемости?
Ну может есть еще какие нибудь советы по оптимизации данной проблемы.
Заранее спасибо...
Имеется маленькая самописная конфигурация. Там хранится информация об объектах и фотографии к ним.
Используется в основном через Веб и мобильный клиент.
База файловая, так как очень маленькая и работает достаточно шустро.
Но фото делаются на мобильный и выводятся на форму. В моем случае каждое фото с мобильника весит по 16 мб, а их штук 5 на каждой форме.
При хранении их в ХранилищеЗначения грузятся очень долго, пробовал и хранить на диске, но прироста производительности не дало.
Я понимаю что просто каждый раз фото грузиться по инету и из-за этого такая задержка...
Но все таки,
1. Как быстрее работает открытие фотографий (если не учитывать доступ по инету) из ХранилищаЗначений или из файла на диске?
2.Как лучше на практике хранить? Ведь если я храню в каталоге временных файлов то при выгрузке в *.dt все фото потеряются, ну и есть большая вероятность и потерять при других обстоятельствах... Если храню в Хранилище Значения то растет размер базы...
2.1 повлияет ли увеличение размера базы на общую производительность базы?
3. Есть ли способ кэшировать фото на клиенте, чтобы они каждый раз не грузились по сети?
4. На сколько в моем случае решит проблему переход на серверную БД?
5. На фото обычно текстовые файлы, чеки и т.п. Тоесть Хотелось бы чтоб они были хорошо читаемы, но может можно оптимизировать размер фото средствами 1С без сильное потери читаемости?
Ну может есть еще какие нибудь советы по оптимизации данной проблемы.
Заранее спасибо...
Найденные решения
(1)
1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.
2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.
2.1. Теоретически, независимые объекты не должны влиять друг на друга. Например любая работа со справочником номенклатуры никак не зависит от количества записей в справочнике договоры контрагентов, при условии что они не пересекаются. Но, как я уже говорил ранее, меньшая по размеру база в файловом варианте будет быстрее открываться как минимум.
3. Каждый раз при открытии фото вы можете записывать их пользователю в пк программно на диск и при открытии сверять md5, например, который будете хранить параллельно с именем файла и при необходимости перезаписывать (обновлять) изображение. Минусы такого решения - все фото у вас будут дублироваться и на устройствах с малым количеством памяти это может оказать значительное влияние, правда скорость открытия должна вырасти тоже значительно. +вопрос безопасности открыт, если эти файлы нельзя копировать - тогда вариант не подходит. Кэшировать неопределенное количество относительно больших файлов в оперативную память мне кажется значительно худшей идеей.
4. Как минимум снимет ограничение на размер таблицы в 4Гб, если все же решите хранить файлы в базе. Если нынешняя скорость работы вас полностью устраивает - особых преимуществ в плане открытия изображений вы не получите.
5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.
Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.
2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.
2.1. Теоретически, независимые объекты не должны влиять друг на друга. Например любая работа со справочником номенклатуры никак не зависит от количества записей в справочнике договоры контрагентов, при условии что они не пересекаются. Но, как я уже говорил ранее, меньшая по размеру база в файловом варианте будет быстрее открываться как минимум.
3. Каждый раз при открытии фото вы можете записывать их пользователю в пк программно на диск и при открытии сверять md5, например, который будете хранить параллельно с именем файла и при необходимости перезаписывать (обновлять) изображение. Минусы такого решения - все фото у вас будут дублироваться и на устройствах с малым количеством памяти это может оказать значительное влияние, правда скорость открытия должна вырасти тоже значительно. +вопрос безопасности открыт, если эти файлы нельзя копировать - тогда вариант не подходит. Кэшировать неопределенное количество относительно больших файлов в оперативную память мне кажется значительно худшей идеей.
4. Как минимум снимет ограничение на размер таблицы в 4Гб, если все же решите хранить файлы в базе. Если нынешняя скорость работы вас полностью устраивает - особых преимуществ в плане открытия изображений вы не получите.
5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.
Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Я так одну базу в 70Гб чистил. Там торговые представители сохраняли фотографии выкладки майонеза и кетчупа в магазинах..... На 69Гб фотографий натолкали в базу. Уже давно майонез весь съели, а фотографии хранили....
Но фото делаются на мобильный и выводятся на форму. В моем случае каждое фото с мобильника весит по 16 мб, а их штук 5 на каждой форме.
Я так одну базу в 70Гб чистил. Там торговые представители сохраняли фотографии выкладки майонеза и кетчупа в магазинах..... На 69Гб фотографий натолкали в базу. Уже давно майонез весь съели, а фотографии хранили....
(6)
Это влияет на скорость работы базы? Мне просто не критичен сам размер базы... Пусть хоть 300 Гб, если летать также будет.
Я так одну базу в 70Гб чистил. Там торговые представители сохраняли фотографии выкладки майонеза и кетчупа в магазинах..... На 69Гб фотографий натолкали в базу. Уже давно майонез весь съели, а фотографии хранили....
Это влияет на скорость работы базы? Мне просто не критичен сам размер базы... Пусть хоть 300 Гб, если летать также будет.
(1)
1.Хранить фото в базе конечно удобно, но это всегда будет медленнее (т.к. запись в базу сама по себе медленная) чем на диске.
2.На диске не обязательно хранить в темповской папке, можно создать свою папку и в ней хранить.
3.Для удобного хранения на диске достаточно имя файла задавать как GUID объекта базы данных к которому относиться это файл - тогда при выгрузке\загрузке *DT ничего не потеряется.
1.Хранить фото в базе конечно удобно, но это всегда будет медленнее (т.к. запись в базу сама по себе медленная) чем на диске.
2.На диске не обязательно хранить в темповской папке, можно создать свою папку и в ней хранить.
3.Для удобного хранения на диске достаточно имя файла задавать как GUID объекта базы данных к которому относиться это файл - тогда при выгрузке\загрузке *DT ничего не потеряется.
(1)
1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.
2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.
2.1. Теоретически, независимые объекты не должны влиять друг на друга. Например любая работа со справочником номенклатуры никак не зависит от количества записей в справочнике договоры контрагентов, при условии что они не пересекаются. Но, как я уже говорил ранее, меньшая по размеру база в файловом варианте будет быстрее открываться как минимум.
3. Каждый раз при открытии фото вы можете записывать их пользователю в пк программно на диск и при открытии сверять md5, например, который будете хранить параллельно с именем файла и при необходимости перезаписывать (обновлять) изображение. Минусы такого решения - все фото у вас будут дублироваться и на устройствах с малым количеством памяти это может оказать значительное влияние, правда скорость открытия должна вырасти тоже значительно. +вопрос безопасности открыт, если эти файлы нельзя копировать - тогда вариант не подходит. Кэшировать неопределенное количество относительно больших файлов в оперативную память мне кажется значительно худшей идеей.
4. Как минимум снимет ограничение на размер таблицы в 4Гб, если все же решите хранить файлы в базе. Если нынешняя скорость работы вас полностью устраивает - особых преимуществ в плане открытия изображений вы не получите.
5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.
Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
1.Теоретически, в хранилище файл можно хранить в сжатом виде => он должен меньше весить на диске => быстрее считываться. Но я бы не акцентировал на этом внимание.
2. Вот на этом я бы заострил внимание. Если мне не изменяет память, то при файловом варианте базы при открытии самой базы считывается вся база. Т.е. чем легче база - тем она быстрее открывается (но это не точно). + Максимальный размер одной таблицы - 4 gb. + Затраты на обслуживание базы 100% вырастут (сохраняться бэкап будет дольше, больше весить и так далее).
Мы у себя храним в отдельном каталоге, где у всех есть доступ только на чтение, и у пары человек только на запись. Это все периодически сохраняем с бэкапами 1с. Храним только относительные пути, а общий путь хранится в константе., что бы в случае чего легко и быстро можно было все поменять.
2.1. Теоретически, независимые объекты не должны влиять друг на друга. Например любая работа со справочником номенклатуры никак не зависит от количества записей в справочнике договоры контрагентов, при условии что они не пересекаются. Но, как я уже говорил ранее, меньшая по размеру база в файловом варианте будет быстрее открываться как минимум.
3. Каждый раз при открытии фото вы можете записывать их пользователю в пк программно на диск и при открытии сверять md5, например, который будете хранить параллельно с именем файла и при необходимости перезаписывать (обновлять) изображение. Минусы такого решения - все фото у вас будут дублироваться и на устройствах с малым количеством памяти это может оказать значительное влияние, правда скорость открытия должна вырасти тоже значительно. +вопрос безопасности открыт, если эти файлы нельзя копировать - тогда вариант не подходит. Кэшировать неопределенное количество относительно больших файлов в оперативную память мне кажется значительно худшей идеей.
4. Как минимум снимет ограничение на размер таблицы в 4Гб, если все же решите хранить файлы в базе. Если нынешняя скорость работы вас полностью устраивает - особых преимуществ в плане открытия изображений вы не получите.
5.Возможно на фото много лишней информации. грубо говоря фото в 4к, а чек в нем занимает только центральную часть в 10%. Можно обрезать фото. Можно уменьшить качество фото сторонними средствами, в 1с не уверен. 15мб для 1 фото - это очень хорошее качество должно быть, либо очень большое фото. Что-то мне подсказывает, что есть там просто фото обычных чеков /ттн, то вполне легко можно сократить размеры до 1мб и менее при вполне читабельном виде.
Я бы вам посоветовал в первую очередь попробовать оптимизировать размер и качество фото, если получится сжать до 0.5-1мб, это уже даст заметный прирост в скорости.
(2)
А в чем здесь преимущество? По сути на том же серваке где лежит база и поднят Веб-сервер, там поднято и облако. Могу заливать фото туда, канал там отличный. Но как это решит проблему? Я так понимаю фото в виде файла из облака сначала будет заливаться во временноеХранилище (то есть в базу), а потом из базы будет заливаться клиенту. Или нет?
в облаке
А в чем здесь преимущество? По сути на том же серваке где лежит база и поднят Веб-сервер, там поднято и облако. Могу заливать фото туда, канал там отличный. Но как это решит проблему? Я так понимаю фото в виде файла из облака сначала будет заливаться во временноеХранилище (то есть в базу), а потом из базы будет заливаться клиенту. Или нет?
Всем спасибо. Много дельной информации....
Сейчас попробую реализовать загрузку в облако WebDAV, и отображение напрямую по ссылке, ну и точно опробую вариант с оптимизацией фото, думаю что средствами настройки камера телефона. Видел статейку что можно менять параметры разрешения и качества снимка в 1С
Сейчас попробую реализовать загрузку в облако WebDAV, и отображение напрямую по ссылке, ну и точно опробую вариант с оптимизацией фото, думаю что средствами настройки камера телефона. Видел статейку что можно менять параметры разрешения и качества снимка в 1С
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот