Проектирование системы управления документами .NET - вопросы производительности

Question

Мне нужно разработать базовую систему управления документами .NET со следующими спецификациями:

1. Данные должны быть переносимыми и автономными, поэтому я буду сериализовывать документы (типичные форматы Word, PDF, Excel и Powerpoint) в двоичные данные. Затем я буду хранить указанные двоичные данные в базе данных SQL Server 2005. Когда пользователю необходимо загрузить документ, система десериализует двоичные данные и представит их в оригинальном формате.

2. Средний размер строки не может превышать 200 тыс.

3. Мы ожидаем, что максимум 500 документов будут загружаться ежемесячно в течение трех лет.

4. Мы не ожидаем, что размер базы данных когда-либо превысит 6 ГБ

5. Максимальная цель - 20 000 человек, которые потенциально могут получить доступ к системе одновременно.

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

Я начинающий разработчик и не знаком с такой архитектурой и дизайном.

Answer 1

Это больше, чем просто «базовая» система. Итак, вот мои проблемы с самого начала:

• 500 документов в месяц в течение 3 лет, похоже, что для базы данных она может превышать 6 ГБ. Возможно, вы захотите определить максимальный размер документа и посмотреть, выдержит ли этот расчет.
• 20 000 пользователей - это много. Сколько вы можете ожидать сразу? Если это более 100 одновременно работающих пользователей, я бы начал исследовать кластеризацию серверов / веб-фермы, чтобы справиться с нагрузкой
• просто ниточка, но вы не будете "сериализовать" в смысле .NET "Serializable". Вы просто будете хранить необработанные байты документа в БД
• если вам нужна высокая доступность, вам нужно будет посмотреть репликацию БД на другой экземпляр БД на случай, если ваш сервер БД выйдет из строя

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

Mike

Answer 2

В чем причина необходимости хранить файлы в базе данных, а не просто сохранять путь к документу на файловом сервере или CDN? Будет намного меньше нагрузки на ваш сервер БД и даст вам более гибкие возможности для хранения документов.

Если у вас есть проблемы с перемещенными / удаленными файлами в системе, подобной той, которую я предложил, то, возможно, также рассмотрите другие варианты, такие как:

• Блокировка разрешений в базовой файловой системе для всех, кроме роли, под которой работает приложение (самый простой вариант)
• Запуск фоновой службы, которая прослушивает изменения папок и т. Д. И соответственно обновляет базу данных

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

Answer 3

Важной частью программирования является знание того, когда вы над головой. Если опубликованные вами CTQ являются реальными, в частности требование одновременного доступа, то вас ждет мир боли. Даже те из нас, у кого достаточно много времени в окопах, окажутся в мире страданий с таким требованием. Я бы решил эту проблему следующим образом:

Я пойму это неправильно во многих отношениях, которые я могу себе представить.

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

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

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

Если по какой-то причине у вас есть только SQL Server 2005, вам придется иметь дело с BLOB s, что не совсем сложно, но несколько беспорядочно. Я предлагаю вам прочитать В BLOB или Не в BLOB от Microsoft Research, чтобы принять решение, если хранение данных в SQL Server 2005 является лучшим выбором для вас. Если это так, существует множество статей, в которых подробно описывается, как помещать файлы в SQL Server BLOB s. Просто знайте, что это редко является наиболее эффективным или масштабируемым решением.