LINUX.ORG.RU

где лучше хранить новости/статьи. в db или в filesystem?


0

0

собственно сабж.

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

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

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

так что возникает резонный вопрос. как же всё таки хранить текстовые данние. в БД, или же в файловой системе?


Лучше всего будет кеширование. На ФС хранятся готовые страницы целиком, которые формируются при изменении в базе данных. Обновление закешированных данных по таймауту и/или по факту обновления соответственной записи в БД.

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

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

к сути вопроса: таки получается, что лучше в БД хранить текстовые данные?

none
() автор топика
Ответ на: комментарий от none

Ты какую-то странную вещь написал, если честно. Уж лет 10 в вебе все хранят текст в БД, а работает всё через всякие ORM и прочие навороты.

Впрочем, не в этом суть.

Кэш - самый удобный и простой вариант для максимально быстрого доступа к данным. Особенно если использовать что-то приятное вроде memcached. Соответственно уже не очень важна производительность самого доступа к данным.

Поэтому пофигу, файлы там, или БД - со стороны кэша всё одинаково, а раз так - то тогда надо использовать тот способ, который удобнее всего для работы. ИМХО работа с БД удобнее чем файлы, возможностей больше. А значит и использовать надо БД.

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

От задачи зависит. Вообще хорошо в приложении иметь возможность кэшировать разными способами независимо от наличия всяких сторонних проксей.

anonymous
()

Храни в БД, меньше проблем. Когда тебе нужно будет выбрать новости с тегом «Медведев» через ФС это будут костыли. Я не про поиск если что.

mobile
()
Ответ на: комментарий от mobile

да.. всем спасибо.. доходчиво всё объяснили

none
() автор топика
Ответ на: комментарий от anonymous

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

а то понастроють вот так вот, и кмон

Unclown
()
Ответ на: комментарий от Unclown

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

Ну да, а граблей на самодельной БД-wannabe на файлах будет конечно же меньше.

anonymous
()
Ответ на: комментарий от anonymous

грабли на БД очевиднее, легче находятся и легче исправляются. так что в конечном итоге - меньше

Unclown
()
Ответ на: комментарий от true_admin

> Дело тут явно в архитектуре и прогерах а не в самой идее многоуровневого кэширования.

Да БД даже легче кешировать. Тупо инструментов больше готовых. Конечно когда проект станет Твиттером можно подумать и о какой-нибудь Кассандре.

mobile
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.