документооборот и доступ к файлам

[twilight]

Цитата:

Сообщение от ivas

их достаточно много > 50гб

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

[ivas]

Цитата:

Сообщение от twilight

А разве это влияет на производительность?
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?

мысль интересная надо её подумать

[glibs]

Цитата:

Сообщение от twilight

...
А почему бы просто не хранить документы в базе?
...
А разве это влияет на производительность?
...

Вопрос в количестве документов и количестве обращений к ним. А также в том, читаются они в основном или модифицируются.

Есть еще хороший вопрос про управление конфликтами на уровне доступа к файлам. И аспекты администрирования.

С т.з. производительности влияет. Это бесспорно. Вопрос только насколько существенно (ощутимо).

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

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

Работа с документами врядли ощутимо нагрузит процессор сервера БД.

Работа с документами при интенсивной работе с большими по размеру файлами достаточно ощутимо загрузит сетевой интерфейс на сервере БД.

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

Последнее важно в связи с тем, то сервер БД сложно масштабировать.

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

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

А если, например, сервер БД сконфигурирован в режиме зеркалирования (горячий stand by), то пошло-поехало.

И наконец, стоит учитывать различия в функциональности документооборота, которые обусловлены тем или иным способом хранения файлов (скорее всего, это не полный список):
- При хранении файлов в БД файлы всегда передаются по сети. Если же файлы хранить на файловом сервере, то на удаленных инсталляциях есть возможность организации локальных файловых хранилищ для определенных видов файлов с доступом в рамках высокоскоростных локальных каналов.
- Мне пока на тестовой базе не удалось воспроизвести стабильную работу в режиме открыл файл, отредактировал, сохранил при работе с сохранением файлов в БД (я продолжу исследование данного вопроса и отпишу через некоторое время). Процесс сохранения измененных файлов при работе с файлами, которые хранятся в БД, не тривиален. В случае же если файлы хранятся на файловом сервере, то таких проблем не возникает. Если же файлы просто класть в БД... ну т.е. поправил — сохранил уже новую версию, то БД будет пухнуть. Хотя вариант имеет некотрые плюсы (версионность изменения файла хранится).
- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Цитата:

Сообщение от twilight

...
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?
...

А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?

Или что вы имеете в виду?

В общем, думайте сами, решайте сами, как говорилось... по-моему, в песне какой-то.

_____________
* Здесь и далее я буду оперировать терминологией и функциональными возможностями MS SQL. Просто я с ним работаю и в определенной степени его знаю. С Oracle я же наоборот практически не знаком. Однако я склонен считать, что все, что я написал, одинаково справедливо и для Oracle. Возможно, эксперты Oracle меня поправят, если это не так.

[ivas]

решили поступить так:
клиент будет "думать" что работает с БД, а AOS с файлами и передавать их в бинарном виде на клиента

[twilight]

Цитата:

Сообщение от glibs

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

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

Цитата:

Сообщение от glibs

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

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

Цитата:

Сообщение от glibs

- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.

Да, с совместным доступом тяжело. С другой стороны, он не так уж часто требуется.

Цитата:

Сообщение от glibs

А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?

Или что вы имеете в виду?

Под сервером я подразумевал физический сервер. А хранение организовывать средствами СУБД, как вы и описали в своем сообщении.

А насчет производительности - пока не попробуешь, не узнаешь.

[glibs]

Цитата:

Сообщение от twilight

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

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