Быстрее ли получить доступ к данным из файлов или сервера баз данных?

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

1. кэширование. Если вы не очень умны, вы не можете написать кэш так же хорошо, как у сервера БД

2. оптимизатор.

однако для некоторых специализированных приложений ни одно из этих 2 преимуществ не проявляется по сравнению с хранилищем данных files+folders - поэтому ответ-громкое "зависит".

Что касается файлов/папок, трюки:

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

Как правило, базы данных работают медленнее файлов.

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

но "производительность" не является целью при выборе базы данных над решением на основе файлов.

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

Так:

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

в принципе, вопрос в том, что было бы проще разработать. Этот разница в производительности между ними не стоит тратить время на разработку.

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

мой небольшой опыт работы с PostgreSQL. У меня был стол с тремя миллионами рядов, и я пошел в обновление всего 8,000 записей. Прошло 8 секунд.

Что касается цитаты " преждевременная оптимизация-корень всего зла.- Я бы отнесся к этому с пониманием. Если вы пишете свое приложение с помощью базы данных, а затем находите его медленным, может потребоваться огромное количество времени, чтобы переключиться на подход на основе файловой системы или что-то еще (например, SQLite). Я бы сказал, что лучше всего создать очень простой прототип вашей рабочей нагрузки и протестировать его с помощью обоих подходов. Я считаю, что это важно знать, что быстрее в этом случае.

как указывали другие: это зависит!

Если вы действительно нужно выяснить, что будет более эффективным для ваших целей, вы можете создать некоторые образцы данных для хранения в каждом формате, а затем запустить некоторые тесты. Эталон.модуль pm поставляется с Perl и делает его довольно простым для параллельного сравнения с чем-то вроде этого:

use Benchmark qw(:all) ;

my $count = 1000;  # Some large-ish number of trials is recommended.

cmpthese($count, {
    'File System' => sub { ...your filesystem code... },
    'Database'    => sub { ...your database code... }
});

Вы можете perldoc Benchmark чтобы получить более полную документацию.

очень полезно использовать файлы вместо БД, когда дело доходит до изображения, если структура сайта подходит. Создайте папки, представляющие соответствующие данные, и поместите изображения внутрь. Например, у вас есть сайт статьи, вы храните свои статьи в БД. Вам не нужно размещать пути к изображениям в папках db, name с вашими первичными ключами, такими как 1,2,3.. и поместить изображения внутрь. Электронные книги, музыкальные файлы, видео, этот подход можно использовать во всех медиа-файлах. Такая же логика работает с XML-файлами, если вы не будете искать за то.

Это зависит от профиля данных и какой логики вы собираетесь использовать для доступа к нему. Если вам просто нужно сохранить и извлечь именованные узлы, база данных на основе файловой системы может быть быстрее и эффективнее. (Для этой цели вы также можете взглянуть на Berkeley DB.) Если вам нужно выполнить поиск на основе индекса, и особенно если вам нужно объединить различные наборы данных на основе ключей, то база данных SQL-ваш лучший выбор.

Я бы просто пошел с любым решением, которое кажется самый естественный для вашего применения.

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

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

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

Не зная никаких деталей, я бы предложил используя решение SQLite/DBI, затем просмотрите производительность. Эта воля дайте гибкость с разумно простым запуском и достойной производительностью.

для быстрого доступа к файлам, в зависимости от того, что вы делаете, mmap может быть очень удобным. Я только что написал об этом в Эффективный Perl блог файлы карт памяти вместо того, чтобы прихлебывать их.

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

Я собираюсь дать вам тот же ответ, все остальные дали вам, Это зависит

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

но, когда у вас есть более одного сервера вам придется управлять распределенной системой файлы, такие как glusterfs, Цеф, etc..

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

надеюсь, это поможет.