Цитата:
Сообщение от
twilight
...
А почему бы просто не хранить документы в базе?
...
А разве это влияет на производительность?
...
Вопрос в количестве документов и количестве обращений к ним. А также в том, читаются они в основном или модифицируются.
Есть еще хороший вопрос про управление конфликтами на уровне доступа к файлам. И аспекты администрирования.
С т.з. производительности влияет. Это бесспорно. Вопрос только насколько существенно (ощутимо).
Если файлов мало или к ним редко обращаются, то я бы не ожидал ощутимого влияния от хранения файлов в БД на производительность работы сервера БД.
Даже если файлы хранятся большие, то таблицу с файлами (DocuValue) можно хранить на отдельном дисковом массиве, затолкав ее в отдельную файловую группу*, которую в свою очередь можно затолкать в отдельный физический файл, который можно хранить на отдельном дисковом массиве. Т.о. влияние хранения документов на "раздутие" БД, дефрагментацию файлов данных и скорость ввода-вывода на дисковом массиве, где хранятся основные данные, можно нивелировать.
Работа с документами врядли ощутимо нагрузит процессор сервера БД.
Работа с документами при интенсивной работе с большими по размеру файлами достаточно ощутимо загрузит сетевой интерфейс на сервере БД.
Работа с документами при интенсивной работе с большими по размеру файлами отнимет память на сервере БД под выполнение задач ввода-вывода. Затрудняюсь оценить насколько много. Попробую уточнить у специалистов. Или они сами тут напишут. Знаю точно, что в файловых серверах много памяти не бывает. Думаю, это не спроста.
Последнее важно в связи с тем, то сервер БД сложно масштабировать.
Если вы что-то понимаете в задачах и процессах администрирования сервера БД, то... даже при условии хранения файлов на отдельном дисковом массиве БД (как единая сущность) будет пухнуть. А значит будет пухнуть архив БД. А это уже увеличит время на сервисные процедуры с БД (архивирование). Того же стоит ожидать и в случае, если БД будет восстанавливаться из архива при необходимости такого восстановления. А время — деньги, как известно.
Даже если учесть, что архивировать можно отдельные файлы данных, то процесс администрирования БД усложняется. И есть еще файл журнала транзакций БД. Насколько я знаю, его порезать на файловые группы не получится. А значит при вставке файла он будет расти, причем на основном массиве данных. И потом он будет архивироваться. А в случае сбоя — восстанавливаться. Но в любом случае вставка файла будет занимать ресурсы сервера БД.
А если, например, сервер БД сконфигурирован в режиме зеркалирования (горячий stand by), то пошло-поехало.
И наконец, стоит учитывать различия в функциональности документооборота, которые обусловлены тем или иным способом хранения файлов (скорее всего, это не полный список):
- При хранении файлов в БД файлы всегда передаются по сети. Если же файлы хранить на файловом сервере, то на удаленных инсталляциях есть возможность организации локальных файловых хранилищ для определенных видов файлов с доступом в рамках высокоскоростных локальных каналов.
- Мне пока на тестовой базе не удалось воспроизвести стабильную работу в режиме открыл файл, отредактировал, сохранил при работе с сохранением файлов в БД (я продолжу исследование данного вопроса и отпишу через некоторое время). Процесс сохранения измененных файлов при работе с файлами, которые хранятся в БД, не тривиален. В случае же если файлы хранятся на файловом сервере, то таких проблем не возникает. Если же файлы просто класть в БД... ну т.е. поправил — сохранил уже новую версию, то БД будет пухнуть. Хотя вариант имеет некотрые плюсы (версионность изменения файла хранится).
- Контроль совместный доступ к файлу. При хранении файла на файловом сервере совместным доступом будет управлять ОС файлового сервера. При открытии хранящегося в БД файла контроль совместного доступа не осуществляется.
Цитата:
Сообщение от
twilight
...
Почему бы не настроить хранение таблиц документооборота на отдельном сервере?
...
А разве Аксапта поддерживает конфигурации, в которых есть несколько БД, расположенных на разных серверах?
Или что вы имеете в виду?
В общем, думайте сами, решайте сами, как говорилось... по-моему, в песне какой-то.
_____________
* Здесь и далее я буду оперировать терминологией и функциональными возможностями MS SQL. Просто я с ним работаю и в определенной степени его знаю. С Oracle я же наоборот практически не знаком. Однако я склонен считать, что все, что я написал, одинаково справедливо и для Oracle. Возможно, эксперты Oracle меня поправят, если это не так.