Какой рекомендуемый метод хранения огромного контента?

Question

Я планирую начать сайт на основе статьи, где пользователи будут печатать свои статьи и загружать изображения.

Теперь я немного смущен, каким образом я мог бы сохранить данные. Либо в базе данных, либо в файловой системе в виде файла .txt или .html-файла или любым другим способом. Сохранение данных в базе данных вызывает у меня немного смущения, потому что изначально я планирую запустить сайт на общем сервере. Так будет ли общий объем сервера достаточным для огромного контента? Или это рекомендуется сохранить содержимое как отдельный файл .txt или .html-файл?

соображения: функциональность

1. Поиск будет использоваться только для названия статьи. Заголовок статьи будет сохранен в базе данных. Функция поиска не распространяется на содержимое статьи.
2. Я планировал использовать редактор WYSIWYG и разрешать вкладчикам форматировать их содержимое. Поэтому, очевидно, что сохраненные данные будут содержать коды HTML. Таким образом, сохранение содержимого в файловой системе безопасно, потому что это XSS-атака в базе данных, является ли это истиной?
3. Изображения сохраняются в файловой системе, а не в базе данных.

a. Каковы точки, которые необходимо сконцентрировать, чтобы предотвратить атаку XSS при этом?

b. Если сохранение в базе данных является рекомендуемым решением, каков должен быть тип данных? ТЕКСТ или LONGTEXT?

Answer 1

Это 2 самых общих решений я могу думать:

1. хранить все в базе данных.
2. Храните «маленькие» данные в базе данных и все вложения (двоичный файл, такой как JPEG и PDF) за пределами базы данных в файловой системе.

Оба решения имеют преимущества и недостатки.

Решение # 1: Хранить все в базе данных

Преимущества:

• С некоторыми (мощные) базы данных вы можете даже индекс (Seach) содержание общих форматов файлов, таких как PDF (Oracle interMedia является пример).
• Вы можете легко обеспечить целостность данных.
• Вы можете легко обеспечить безопасность данных.

Недостатки:

• делает базу данных огромны и может быть мучительно медленным, если вы никогда не содержанием ваших баз данных/таблиц.
• Может быть сложнее «просматривать» двоичный контент для отладки.
• Вам особенно необходимо запустить обслуживание базы данных/таблицы, если в вашем проекте имеется огромная база данных, в которой многие пользователи читают/записывают.
• Резервное копирование базы данных может быть труднее выполнить и восстановить.
• Может быть когда-нибудь сложно использовать файл в веб-приложениях (необходимо знать тип MIME для правильного отображения файлов).

Решения # 2 - Магазин «малые» данные в базе данных, и все вложения за пределами базы данных в файловой системе

Преимущество:

• HTTP кэширования файлов являются несколько проще делать.
• Легче просматривать файлы (для отладки или чего-то еще).
• Легче поддерживать быструю систему, не делая ничего особенного.

Недостатки:

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

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

Для общей среды я бы, вероятно, пошел с # 2, поскольку общая среда обычно не очень мощная.

Answer 2

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

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

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