Базы данные документов/Изображения Repository Дизайн Вопрос

Question

Вопрос:

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

фон:

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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