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

Question

Вопрос:

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

Справочная информация:

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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