Вопрос по проектированию репозитория базы данных документов/изображений

Question

Вопрос:

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

Фон:

У меня есть специальное приложение для обработки изображений и рабочих процессов, которое в настоящее время хранит около 15 миллионов документов/изображений документов (более 90 % одностраничных, группа 4 tiff, остальные документы PDF, Word и Excel).Репозиторий изображений — это коммерческое стороннее приложение, которое очень дорогое и, откровенно говоря, требует слишком больших затрат.Мне просто нужна система для хранения и извлечения изображений документов.

Я подумываю о переносе образа непосредственно в базу данных SQL Server 2005.Информация об индексировании очень ограничена — в основном 2 поля индекса.Это система администрирования полисов страхования жизни, поэтому я индексирую изображения с номером полиса и уникальным идентификационным номером всей системы.Существуют и другие значения индекса, но они хранятся и поддерживаются отдельно от данных изображения.Эти значения индекса дают мне возможность искать уникальное значение идентификатора для поиска отдельного изображения.

Сервер базы данных представляет собой двухъядерный компьютер с ОС Windows 2003 и дисками SAN, на которых размещаются файлы БД.Текущий размер репозитория изображений составляет около 650 ГБ.Я не проводил никакого тестирования, чтобы определить, насколько большой будет преобразованная база данных.На самом деле я не спрашиваю о дизайне базы данных — над этим аспектом я работаю с нашими администраторами баз данных.Если что-то изменится, я вернусь :-)

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

Меня больше всего беспокоят масштабируемость и производительность, которые в значительной степени ориентированы на производительность.У меня около 100 пользователей, и в ближайшие несколько лет рост использования, вероятно, будет медленным.Большинство пользователей в основном читают — они не часто добавляют изображения в систему.У нас есть отдел, который занимается сканированием и добавлением изображений в хранилище.У нас также есть несколько других приложений, которые получают документы (через FTP) и автоматически вставляют их в репозиторий по мере их получения, либо полностью индексируя информацию, либо в виде «пакетов», которые пользователь просматривает и индексирует.

Большинство (90%+) документов/изображений очень малы, <100 КБ, возможно, < 50 КБ, поэтому я считаю, что хранение изображений в файле базы данных будет наиболее эффективным, а не использовать SQL 2008 и использование файлового потока.

Answer 1

Часто масштабируемость и производительность в конечном итоге женаты друг с другом в том смысле, что через шесть месяцев руководство возвращается и говорит: «Функция y в приложении X работает с неприемлемо медленным, как мы его ускорим?» И слишком часто ответ - обновить заднее решение.А когда дело доходит до обновления серверной части, масштабирование почти всегда обходится дешевле, чем увеличение аппаратного обеспечения.

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

Answer 2

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

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

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

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

Что касается масштабируемости, проверьте ее.Тогда вы будете знать не только, понадобится ли масштабирование, но, возможно, и когда.«Отлично работает для 100 пользователей, проблематично для 200. Если мы достигнем 150, мы, возможно, захотим еще раз взглянуть на серверную часть, но на данный момент это хорошо».

ИМХО, это должная осмотрительность и ответственная тактика проектирования.

Answer 3

Я согласен с gabriel1836.Однако дополнительным преимуществом будет то, что вы сможете какое-то время использовать гибридную систему, поскольку вы не собираетесь в одночасье конвертировать 14 миллионов документов из вашей собственной системы в собственную систему.

Кроме того, я настоятельно рекомендую вам хранить документы вне базы данных.Храните их в файловой системе (локальной, SAN, NAS не важно) и храните указатели на документы в базе данных.

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

Кроме того, не стоит недооценивать усилия по замене захвата (сканирования и импорта), предоставляемого собственной системой.