Вопрос о дизайне репозитория базы данных / изображений
Вопрос:
Должен ли я написать свое приложение для прямого доступа к хранилищу изображений базы данных или написать часть промежуточного программного обеспечения для обработки запросов документов.
Фон:
У меня есть собственное приложение Document Imaging и Workflow, которое в настоящее время хранит около 15 миллионов документов / изображений документов (90%+ одна страница, tiff группы 4, остальные документы PDF, Word и Excel). Репозиторий изображений - это коммерческое стороннее приложение, которое очень дорого и, честно говоря, требует слишком много накладных расходов. Мне просто нужна система для хранения и получения изображений документов.
Я рассматриваю перемещение изображений непосредственно в базу данных SQL Server 2005. Информация об индексировании очень ограничена - в основном это 2 поля индекса. Это система управления полисами страхования жизни, поэтому я индексирую изображения с помощью номера полиса и уникального общесистемного идентификатора. Существуют и другие значения индекса, но они хранятся и хранятся отдельно от данных изображения. Эти значения индекса дают мне возможность искать уникальное значение идентификатора для поиска отдельных изображений.
Сервер базы данных представляет собой двухъядерный процессор Windows 2003 с накопителями SAN, на которых размещаются файлы БД. Текущий размер репозитория изображений составляет около 650 ГБ. Я не проводил никаких тестов, чтобы увидеть, насколько большой будет конвертированная база данных. Я на самом деле не спрашиваю о дизайне базы данных - я работаю с нашими администраторами баз данных над этим аспектом. Если это изменится, я вернусь:-)
Текущая система, которая будет заменена, очевидно, является приложением промежуточного программного обеспечения, но это очень тяжелая система, распределенная на 3 сервера Windows. Если я пойду по этому пути, это будет система с одним сервером.
Мои главные проблемы - масштабируемость и производительность - в значительной степени ориентированные на производительность. У меня около 100 пользователей, и рост использования будет, вероятно, медленным в течение следующих нескольких лет. Большинство пользователей в основном читают пользователей - они не очень часто добавляют изображения в систему. У нас есть отдел, который занимается сканированием и добавлением изображений в хранилище. У нас также есть несколько других приложений, которые получают документы (через ftp), и они вставляют их в хранилище автоматически по мере их поступления, либо будут заполнять информацию индексации, либо "пакетами", которые пользователь просматривает и индексирует.
Большинство (90%+) документов / изображений очень маленькие, < 100 КБ, возможно, < 50 КБ, поэтому я считаю, что хранение изображений в файле базы данных будет наиболее эффективным, чем получение SQL 2008 и использование файлового потока.
3 ответа
Зачастую масштабируемость и производительность в конечном итоге связаны друг с другом в том смысле, что через шесть месяцев руководство возвращается и говорит: "Функция Y в Приложении X работает недопустимо медленно, как мы можем ускорить ее?" И слишком часто ответом является обновление серверного решения. А когда дело доходит до обновления бэкэндов, его масштабирование почти всегда обходится дешевле, чем масштабирование с точки зрения аппаратного обеспечения.
Итак, короче говоря, я бы порекомендовал создать приложение промежуточного программного обеспечения, которое специально обрабатывает входящие запросы от пользовательского приложения и затем направляет их в соответствующий пункт назначения. Это в достаточной степени абстрагирует ваше пользовательское приложение от внутреннего хранилища, так что, когда масштабируемость становится проблемой, необходимо обновить только промежуточное программное обеспечение.
Это просто. Запишите приложение в интерфейс, используйте какой-то заводской механизм для предоставления этого интерфейса и реализуйте этот интерфейс так, как вам удобно.
Если вы довольны своим интерфейсом, то приложение (в основном) изолировано от реализации, будь то прямая связь с БД или каким-либо другим компонентом.
Подумав немного о дизайне вашего интерфейса, но сделав глупость: "это просто, это работает здесь, это работает сейчас", реализации предлагают хороший баланс проверки системы в будущем, но не обязательно над ее разработкой.
Легко утверждать, что на данном этапе вам даже не нужен интерфейс, а просто простой класс, который вы создаете. Но если ваш контракт хорошо определен (т. Е. Интерфейс или сигнатура класса), это то, что защищает вас от изменений (например, переделывает реализацию бэкэнда). Вы всегда можете заменить класс интерфейсом позже, если сочтете это необходимым.
Что касается масштабируемости, проверьте это. Тогда вы знаете не только, если вам может понадобиться масштабировать, но, возможно, когда также. "Отлично работает для 100 пользователей, проблематично для 200, если мы наберем 150, мы могли бы рассмотреть возможность взглянуть на сервер еще раз, но пока это хорошо".
Это должная осмотрительность и ответственная тактика проектирования, ИМХО.
Я согласен с gabriel1836. Тем не менее, дополнительным преимуществом будет то, что вы можете какое-то время запускать гибридную систему, поскольку вы не собираетесь конвертировать 14 миллионов документов из вашей собственной системы в вашу домашнюю систему за одну ночь.
Кроме того, я настоятельно рекомендую вам хранить документы вне базы данных. Храните их в файловой системе (локальной, SAN, NAS это не имеет значения) и храните указатели на документы в базе данных.
Я хотел бы знать, какую систему управления документами вы используете сейчас.
Также не стоит недооценивать усилия по замене захвата (сканирования и импорта), предоставляемого проприетарной системой.