Вход | Регистрация


1С:Предприятие ::

Метки: 

Хранение документов в отдельной базе

Я
   Falex
 
14.04.17 - 21:10
Здравствуйте.

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

Как лучше организовать такое хранение и сопоставление? Через внешние источники данных?

ЗЫ: пользователю на выбор для каждого контрагента будет даваться право где хранить данные: в отдельной базе данных или на компьютере (в папке).
 
 
   Волшебник
 
Модератор
1 - 14.04.17 - 21:13
Беги оттуда
   Falex
 
2 - 14.04.17 - 21:20
Почему? Объем документов большой, поэтому, есть такая идея.
   vfire1000
 
3 - 14.04.17 - 22:12
Делай вьюшку на другую базу. Только с точки зрения лицензионной политики 1С это айяйяй )
   vde69
 
4 - 14.04.17 - 22:14
читай про интеграцию документооборота...

например в УХ это реализовано...
   RomanYS
 
5 - 14.04.17 - 23:43
Речь я так понимаю про файловое хранилище. Тут два варианта: хранить в базе или на диске сервера. У этих вариантов свои плюсы и минусы, но разница только в части администрирования. Смысл хранить файлы в другой базе(особенно если это 1с) не понимаю. Если мы конечно не говорим про системы типа ДО со своим самостоятельным функционалом.

(0)Зачем всё это?
   Волшебник
 
Модератор
6 - 15.04.17 - 00:11
Зачем всё это? Кто платит за весь этот банкет?
   Лефмихалыч
 
7 - 15.04.17 - 08:20
(0) В этой отдельной базе делаешь вебсервис, к которому будет обращаться твоя основная база. Вебсервис принимает файлы на хранение и выдает файлы по запросу. В основной базе на некий период лучше кешировать.
(6) Да мало ли. Например, чтобы обновление конфигурации основной базы не зависело от количество картинок в базе. Требования к резерезвному копированию данных и картинок этих могут быть разными. Много вариантов.
   Лефмихалыч
 
8 - 15.04.17 - 08:24
Да еще лучше так.
Пользователь прикрепляет файлы к объектам БД и они хранятся, как принято, в справочнике.
Потом регламентное раз в Х часов проходит по справочнику и:
1. Передает через вебсервис в отдельную базу всё, чего в отдельной базе нет, и то, что изменилось с последней передачи
2. Удаляет все файлы, срок хранения которых во временном кэше истек.
3. Когда польователь обращается к файлу, сначала поиск производится в локальном кэше и, если там пусто, делается запрос к вебсервису.
   Jump
 
9 - 15.04.17 - 09:47
(0) Документы проще, удобнее и дешевле хранить на файловой системе.
Файловая система - самая лучшая БД для документов.
   Falex
 
10 - 15.04.17 - 10:05
Файловая это конечно проще всех. Но как производить поиск в нем? Например, файлы будут прикрепляться не к договору,а документам. Как тогда найти на сервере файлы именно этого документа?
 
  Рекламное место пустует
   Falex
 
11 - 15.04.17 - 10:07
УХ в интеграции документоборота - это что?
   RomanYS
 
12 - 15.04.17 - 11:23
(10) с точки зрения пользователя отличий никаких, просто вместо реквизита с типом ХЗ у тебя строка с адресом файла на диске.

(8) Клёвый мопед, приведи хоть один плюс по сравнению с хранением на диске. Интеграцию с третьими системами не рассматриваем.
   Jump
 
13 - 15.04.17 - 18:49
(10) Точно так же как и в базе.
У вас же в базе будет хранится  путь к этому документу.

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

Вот и вся разница в поиске.
   Jump
 
14 - 15.04.17 - 18:58
Фишка в том что документ по своей сути это файл.
А файловая система это как раз самая удобная и продуманная база данных для хранения файлов.

А вот база 1с, и база SQL не самые оптимальные вещи для этого.
В итоге если вы храните файлы в ФС у вас не распухает база, меньше требования к железу, удобней все это дело бэкапить.
   mehfk
 
15 - 15.04.17 - 19:03
(14) А еще MS SQL начиная с определенной версии умеет FileStream.
   mehfk
 
16 - 15.04.17 - 19:03
(14) А еще MS SQL начиная с определенной версии умеет File Stream.
   vcv
 
17 - 15.04.17 - 19:14
> А файловая система это как раз самая удобная и продуманная база данных для хранения файлов.
Смотря какие файлы, размеры и количества.
По крайней мере на винде разница в скорости обращения к каталогу с <1000 файлов и >100000 файлов просто драматическая. А для SQL что тысяча, что миллион - нормально тянет.
   Jump
 
18 - 16.04.17 - 06:15
(17) А в чем драматизм папки с 100000файлов?
Не замечал.
Раньше да, было такое - такую папку проводник мог час открывать, особенно когда оперативки мало.
Сейчас проводник открывает папку моментально.
Если прямой доступ к файлу из скрипта - разницы нет что 1 файл в папке, что 100000.
Ну по крайней мере в ntfs так.
   Falex
 
19 - 16.04.17 - 09:18
Если брать по масштабам, то для каждого ключа "Контрагент-Проект" может быть до 10Гб файлов.
Если же все же использовать SQL базы для хранения этих файлов, то как лучше быть на платформе 8.3 если для каждого ключа "Контрагент-Проект" создавать свою базу?
Пользоваться внешними источниками данных или без них? Будет ли преимущество?
   Jump
 
20 - 16.04.17 - 09:20
(19) Что за файлы? Тип, размер? Общий объем который планируется?
   vcv
 
21 - 16.04.17 - 09:33
(18) Проводник?!? :) Вы, наверное, из тех айтишников, которые замеряют скорость дисковой подсистемы на сервере пару раз скопировав файл в ФАРе?

Проводник не показатель, нужно измерять реальные процессы. У меня когда-то на сервере с рэйдом и приличными дисками с нагрузкой порядка 150 пользователей чтение папки ~60000 файлов  с помощью rsync для синхронизации занимало несколько минут.
   Лефмихалыч
 
22 - 16.04.17 - 09:45
(12) с какой радости я тебе должен какие-то примеры приводить? Я ответил на вопрос автора, как сабж лучше сделать. Зачем он автору, я понятия не имею. Но имею в опыте ситуацию, когда такой велосипед был необходим. И нет, ни какой скорости он, естественно, не добавляет и пользовательский экспириенс не улучшает. Это делается для технических или безопасных целей чаще всего.
   Jump
 
23 - 16.04.17 - 11:58
(21) Поясню для непонятливых - вы говорите что скорость обращения к файлам в папке с множеством файлов низкая.
Так вот - нихрена подобного.
Она высокая.
Низкая она была раньше - в проводнике, ибо проводник прожевать не мог такой вывод.
А прямой доступ - высокий всегда.
Сейчас даже проводник моментально прожеввывает такие папки.
   Jump
 
24 - 16.04.17 - 12:03
Вот сейчас проверял - создал папку с миллионом файлов размером 4к  и попробовал скопировать из нее сотню файлов
Потом попробовал скопировать сотню файлов из папки где всего сто файлов - скорость копирования такая же (в пределах погрешности)
   marvak
 
25 - 16.04.17 - 12:07
(0)
Хранение документов на диске - используется многими и давно и успешно.
Единственный момент, чтобы в случае работы с копией базы, том, где хранятся документы, не уничтожили и не испортили документы. То есть нужен какой-то предохранитель
Я недавно допиливал одну базу, пользовался как основой вот этой статьей.
http://catalog.mista.ru/public/529067/

Там правда для обычных форм.
   Jump
 
26 - 16.04.17 - 12:17
(25) Ну обычно на сервере где продакшен крутится с тестовыми не работают.

Если работают - монтировать папку симлинком с  ID базы например.
   vde69
 
27 - 16.04.17 - 12:17
(11)
УХ - 1с:Управление холдингом
в нем предусмотрена интеграция с 1с:Документооборот в плане хранения файлов
   Falex
 
28 - 16.04.17 - 12:44
"Что за файлы? Тип, размер? Общий объем который планируется?": word, excel, отсканированные документы.
Проектов в год порядка 200 штук. На каждый проект порядка 10 Гб файлов - файлов очень много может быть.

Еще такой момент: если каждый проект нужно сопоставлять с данными файла (название, идентификатор, еще какие-нибудь параметры), то лучше хранить эту информацию в подчиненном справочнике или связывать через регистр сведений?
Однако, если в проекте планируется хранение файлов в виде иерархической структуры (т.к. файлом может быть много, то лучше папки под них создавать), то получится ли хранить через регистр сведений?
   vcv
 
29 - 16.04.17 - 12:59
(23)
>> Поясню для непонятливых - вы говорите что скорость обращения к файлам в папке с множеством файлов низкая.

Я говорю "разница в скорости обращения к каталогу...". Где вы видите слово "файлы"?
И описываю рабочий кейс: синхронизация каталогов с помощью rsync. Такой сценарий работы подразумевает большое количество чтений содержимого каталога и малое - файлов.

>> Низкая она была раньше - в проводнике

А раньше, это когда? А где ТС описал свою инфраструктуру? Может быть у него легаси на NT4.

>> А прямой доступ - высокий всегда.

У вас есть информация о том, как у ТС организован доступ к файлам? Может быть по сети, тогда ваш "прямой доступ" мимо кассы.
   Beuenj
 
30 - 16.04.17 - 13:01
(21)Не обязательно все хранить в одном. Раскидывай по подпапкам разделяя их по количеству, дате или любому другому признаку, который позволит +- равномерно размазать файлы по подпапкам. И нет проблемы.
   Jump
 
31 - 16.04.17 - 14:09
(29) А зачем к каталогу обращаться?

Обычное хранение - к документу в базе 1с привязываются например сканы первички в pdf.
Потом их нужно будет выдергивать оттуда.

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

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

По сети или не по сети - пофиг.
   Jump
 
32 - 16.04.17 - 14:13
(30) Ну по дате не лучший способ.

Самое удобное - при сохранении файла считается его хэш.
Имя файла - хэш файла.

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

Если надо по папкам то делается один-два уровня иерархии по первым символам хэша.
   vde69
 
33 - 16.04.17 - 14:47
(31) если запись в ОДНОМ каталоге - то лям файлов завалят любой сервак...

уже поле 20 тысяч файлов заметны проблемы, 100 тыс файлов валят вполне приличный сервер...

по этому по любому нужно делать каталоги...

я в свое время писал ТЗ на подобную систему, в кратце

1. каталоги по годам
2. внутри каталогов по годам каталоги по функциональным направлениям (например юридические, и бух хранятся отдельно)
3. при большом количестве файлов нужно дробить еще глубже...
 
 
   vde69
 
34 - 16.04.17 - 14:49
ну и еще замечание - ОБЯЗАТЕЛЬНО нужно ограничивать размер файлов...

стандартный скан А4 влезает в 300кб, по этому я ставлю ограничение 500кб на картинки и файлы, а на зипы 5 мегов...
   Jump
 
35 - 16.04.17 - 15:17
(33)Завалит в каком смысле?
Случайное чтение будет медленно идти, при множественных запросах к файлам?
Так обычно прикрепленные файлы это статика - они больше хранятся чем используются.
   Лефмихалыч
 
36 - 16.04.17 - 15:45
По поводу максимального количества файлов в каталоге и его влияния на производительность.
Проще применить решение, автоматически распределяющее файлы по разным каталогам, чем сидеть и ждать подтверждения, что в 21м веке может случиться то же самое, что случалось в 20м. Это как руки мыть после туалета. Если этого не делать, то в большинстве случаев ни чего тебе не будет. Но, когда будет, ты сразу поймешь, что риск был бессмысленный, однако будет уже поздно.
   Лефмихалыч
 
37 - 16.04.17 - 15:47
Это все равно, что говорить: "Best practices - гогно потому, что я не встречал случаев, когда не следование им приводило к негативным последствиям". Когда встретишь, поздно будет что-то менять
   Jump
 
38 - 16.04.17 - 15:55
(36) Дык потестить можно какая там предполагаемая нагрузка будет.
$array = New-Object -TypeName Byte[] -ArgumentList 4kb
$obj = New-Object -TypeName System.Random
$obj.NextBytes($array)
for ($i=1; $i -le 1000000; $i++) {
Set-Content -Path F:\test\File$i.txt -Value $array -Encoding Byte
}

Ну и потом выборку нужную сделать и замерить время.
   Лефмихалыч
 
39 - 16.04.17 - 15:59
(38) к (37) надо что-то еще добавлять разве?
все эти твои тесты не будут стоить ни черта, когда продуктивная инфраструктура изменится относительно тестовой. Переедет в дудущем вся эта халабуда на другую какую-то СДХ или/и ОС и выяснится, что количество таки имеет значение. Что ты будешь с тестами своими делать? Вопрос риторический.
   Лефмихалыч
 
40 - 16.04.17 - 15:59
СХД, а не СДХ
   Fragster
 
41 - 16.04.17 - 16:48
что, про стандартный функционал БСП действительно никто не знает?
   Jump
 
42 - 16.04.17 - 17:18
(39) Ну разбивку по папкам как я уже говорил сделать не трудно.
Делается по первым буквам хэша.
И распределяется равномерно и поиск шустрее, и по дискам раскидать можно, ежели объем большой.
   Falex
 
43 - 16.04.17 - 18:50
"что, про стандартный функционал БСП действительно никто не знает?" - а что в ней относительно данной задачи есть? Подскажите пожалуйста.

И Так все таки лучше хранить связь с объектом 1С в регистре сведений или справочнике с учетом огромного количества файлов?
И при рассмотрении хранения файлов в другой базе (хотя для проекта будет предусмотрен вариант хранения) пользоваться ли объектом внешние источники данных?
   RomanYS
 
44 - 16.04.17 - 18:53
(43) тут вроде очевидно: если тебе надо на файл ссылаться, то справочник. Если достаточно к чему-либо прикрепить - РС. В типовых как правило делают справочник или справочники.
   Falex
 
45 - 16.04.17 - 20:12
Мне фактически надо что:
1) Возможность сохранения файла, прикрепленного к объекту.
2) Открытие/редактирование файла, прикрепленного к объекту.

И тут выбор почему между справочником и регистром сведений: при большом массиве данные какое обращение будет быстрее и объем хранения данных?

В типовых и в частности БСП используют "Присоединенные файлы".
   Falex
 
46 - 16.04.17 - 20:28
Читал про "Веб-сервис работы с файлами" в Документообороте. но если у каждого проекта будет своя база, то поднимать для каждой базы веб-сервис это затратно...
   Fish
 
47 - 16.04.17 - 20:28
(45) В БСП всё, что тебе надо, уже реализовано.
   Falex
 
48 - 16.04.17 - 20:35
"В БСП всё, что тебе надо, уже реализовано." - и даже хранение файлов в другой базе данных?
   Йохохо
 
49 - 16.04.17 - 21:21
(48) посмотрели бы документооборот просто, если права сильно не развешивать и хранить в томах, вероятно не станет тяжелой и получите в довесок извлечение текстов и полнотектовый поиск. мб еще какие плюшки понравятся
 
 
   Fragster
 
50 - 17.04.17 - 12:28
(43) все - хранение на диске, в облаке, индексирование и поиск по текстовому содержимому файлов, прикрепление к объектам, версионирование файлов, раскладывание файлов по папкам....
   Fragster
 
51 - 17.04.17 - 12:29
(48) зачем "в базе"?
   Falex
 
52 - 17.04.17 - 21:32
То есть все-таки большинство к хранению файлов на диске с использованием томов хранения файлов (как в БСП)?



Список тем форума
Рекламное место пустует  
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует