v7: файловое хранилище для сканов #760731

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

ждем гусар

для начала определитесь с количеством файлов (например за 10 лет) и максимальным размером одного файла.... например у меня стоит ограничение 0.5 метра на 1 файл, этого хватает на хороший скан А4

ну вопрос второй бекапы делать надо ?

Больше всего заставило задуматься "с оптимизацией доступа по быстродействию." ..... - это что означает?

и вде поддал перчику про бекапы ;)

первое что пришло в голову DROPBOX - можно на каждом компе поставить и путь "c:dropboxpic" и тогда по сети не будут гоняться файлы , не надо думать про бекап  ....

"Гусары - они, сударыня, вообще грубияны. они даже коз - того-с"©

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

да твою ж...

ачо? "пока работает - не трожь!" я вот тут узнал недавно, что в одной конторке БЭСТ без пригляду проработал аж до 2014 года...

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

сетевая папка , в базе имена файлов просто прописаны а путь в настройках. Объемы десятки тысяч сертификатов по 3-5 листов. Пять лет полет нормальный

Если есть домен, то можешь развернуть NFS (сетевая файловая система), по сути куча расшаренных ресурсов собранных в вид каталога, есть возможность синхронизации каталогов. Т.е. решаешь проблему быстродействия раскладывая файлы оптимальным для доступа способом и одновременно, если хочешь, делаешь ночную синхронизацию папок. И остаётся реализовать хранение пути к файлу. Это уж как нравится.

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

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

с этого места поподробнее . это будет медленнее, чем обращение к файлу напрямую? при прямом доступе будут проверяться полномочия пользователя, а через СКУЛь - нет..

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

Файловая система это БД оптимизированная для хранения файлов Скуль это БД оптимизированная для хранения данных.

Какое именно быстродействие вас интересует? Множественный доступ, большого количества пользователей? Быстрый поиск?

мне понравился вариант с дропбокс, если не надо покупать лицензию и давать дропбоксу выход в интернет

Доступ будет всегда через 1с, или возможно напрямую?

Дропбопокс? Платный сервис для таких целей? Если уж нужна синхронизация, то проще поставить BtSync. Ибо бесплатно и данные под контролем, на своей инфраструктуре. Только какое это отношение имеет к вопросу заданному в непонятно.

из 1С. напрямую... наверно, нет. имена файлов генерируются случайным образом.

Выделяете диск, или папку для этих целей, организовываете структуру, чтобы не валить все в одну кучу. Группируете по дате, или по смыслу. В 1с храните путь от корня хранилища.

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

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

Используем FileStream на MS SQL 2008

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

Тогда просто файловая шара, доступная по сети всем кому надо, с прописанными правами, и структурой каталогов для хранения сканов.

+ Сканы зашиваются в PDF, скан обычно не более 100 КБ, файлов 1500, открываются быстро.

в чем профит FileStream?

есть 100500 способов. мы уже разобрались, "почему так оптимально, а сяк - неоптимально". а вам - не поможет...

По той простой причине, что это большой объем информации прогоняемый через SQL. А MSSQL обычно ставят для других целей. Поэтому будем хранить файлы - и ресурсы железа будут работать на файлы, а не на 1c/

с чем связана твоя нервозность?

это не нервозность, а констатация факта...

Миф. Файлы в этом случае хранятся в отдельном каталоге. В  таблицах хранятся ссылки.

один спец из нашей конторы с большим авторитетом у руководства предложил mssql и прямой доступ к базе через объект ADODB.RECORDSET. мне надо пояснить, почему файловая шара лучше. кстати, сеть в конторе слабая. один терминал там, другой сям ))

совершенно верно. так и предложил сделать наш суперспец.

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

Ну файл все равно придется гнать по сети. Какой бы вариант хранения вы не выбрали.

подробнее тут И тут

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

В Википедии файлы хранятся путем раскладывания по папкам 2 или 3 уровней, имя которых формируется как кусок MD5-функции от имени файла. MD5 можно в 7-ке извлечь (надо погуглить как). Затем отрезать кусочками и формировать из них структуру подпапок.

у мну: лежит вне базы. картинки товаров: > 4000шт, 70 мб сертификаты/декларации: >600, 520 мб ни проблем с бэкапами, ни с печать, ни сотсылкой клиентам (из 1С) - нет.

[IMAGE] Шоу "За лупой" (просмотр и установка привязки товар-изображение) - я этих привязок разным клиентам в разных видах (вплоть до подбора товара по изображенимя) - обписался уже, тошнит

[IMAGE] Просмотр, масштабирование и скроллинг картинок

[ОБУЧАЛОВКА] Каким макаром к номенклатуре привязать картинку...?

любишь эпатировать? ты немного не в тему. файлы в PDF. система работает; ничего переделывать не надо. оптимизируем доступ к файлам.

с интересом рассмотрю примеры разработок под filestream в mssql

да мне пофиг - эаптировать или нет. мне что пдф, что пнг, что дежавю - один хрен  "файлы". Хранить их - кому как надо - так и хранит, в зависимости от нужд. Выходить на форум с вопросами когда для себя все уже решено - нафейхоа оно надо? то что не по душе =- отвергнешь, то что легло на душу - примешь. вот и весь профит

Храним образы (сканы, эл письма, вложенные файлы, и вообще хранилища значений) в отдельной базе MS SQL Server. Размер уже более 500 ГБ.

и это барахло кому-нибудь надо? у нас менеджеры цифровой контент генерят с дикой скоростью, а убирать его - никто не убирает...

Получи гранату

сделать свою веб файло картинко помойку на апаче и юзать ее по http

Здесь примерно так же через MD5 хеш

почему нельзя помещать все файлы в одну папку?  интерактивного доступа не предполагается. поиска по папке не будет. NTFS ведь тоже индексирует файлы, как и SQL.. так что по скорости доступа разницы не будет.

ммм принцип каталога? у файловой системы есть некая "база данных файлов" чем больше там записей то тем медленнее (возможно) найти/получить нужную запись одного файла

я так думаю, работа с индексами одинакова что в файловой системе, что в СУБД. или MSSQL справляется с индексами лучше?

причем тут индексы? вот у Вас на полке 10 книг, сколько нужно времени чтобы достать 10? стоя перед полкой а в хранилище 10 миллионов книг... сколько нужно времени чтобы, стоя перед входом в хранилище, достать 9 999 999-ю?

в среднем К * log(10,000,000) к - скорость обращения к индексному полю

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

ограничь на уровне домена.

согласна.

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

У себя для хранения файлов с привязкой к товарам сделал так: Из 1С стучусь в "облако" по http - отправляю список штрихкодов. В ответ получаю список файлов. Если файлов в локальном кеше нет (каталогиб или alluserspictures - по ситуации)  - скачиваю файлики в кеш. Отдельная форма для привязки новых файлов и заливки в веб. само "облако" - MySql с парой таблиц - таблица файл, тип, дата актуальности, оригинальное название и таблица привязок штрихкод/файл. Все файлики хранятся с именем, равным хешу МД5. Пару php в качестве api и простая веб-морда для поиска по штрихкодам. С системой работают из 7.7, из 8.х и из браузера. Всякие дропбоксы/гугльдиски и прочие синхронизаторы админы вспоминают как страшный сон. Рекомендую.

В ntfs работа с индексами файловой системы строится по аналогии с работой с индексами ms sql. Никто не удосужился почитать мою ссылку, вот и все.

Откуда такие глубокие познания?

В среднем или в худшем?

Какой смысл во всем этом огороде если надо просто по штрихкоду отдать картинку? ну и храни базу в любой БД и обращайся из 1С к этой БД напрямую.

Если сканы текстовых документов без особых требований к качеству - то формат djvu идеален. Он жутко сильно жмет их, практически это посимвольный ocr.

Последний раз(а разов с внешними файлами было несколько), извратился таким образом: база SQLite плюс здоровенный блоб-файл, в котором лежат собственно сами файлы. В базе SQLite ссылки на файлы в блоб и всякая фигня для поиска. Ну и там ВК была чтобы автоматически сохранять в БД файлы когда юзер в ворде или екселе жмет на save. Не знаю, работает оно сейчас или нет, но года три жалоб не было :) А так, задача простая, делай как хочешь. Вариантов миллион.

ах да. забыл

"клиенты" системы в разных городах

имхо хранить в рабочей базе будет ошибкой. за отдельную базу голосую красивое решение