Если у меня есть статическая база данных, состоящая из папок и файлов, доступ и манипуляции будут быстрее баз данных типа SQL-сервера, учитывая, что это будет использоваться в CGI script?
При работе с файлами и папками, какие уловки улучшают производительность?
Я добавлю, что это зависит от толпы.
Это вопрос, который не имеет общего ответа, но сильно зависит от текущей ситуации. Я даже недавно перенес некоторые данные из базы данных SQL в плоскую файловую систему, потому что накладные расходы БД в сочетании с некоторыми проблемами надежности соединения с БД сделали использование плоских файлов лучшим выбором.
Некоторые вопросы, которые я задавал себе при выборе:
Как я использую данные? Например, я просто буду читать от начала до конца строк в указанном порядке? Или я буду искать строки, соответствующие нескольким критериям?
Как часто я получаю доступ к данным во время выполнения одной программы? Пойду ли я один раз, чтобы получить все книги с Сэлинджером в качестве автора или я буду идти несколько раз, чтобы получить несколько разных авторов? Я буду идти несколько раз для нескольких разных критериев?
Как я буду добавлять данные? Могу ли я просто добавить строку до конца и идеально подходит для моего поиска или вам нужно будет прибегнуть?
Насколько логичным будет выглядеть код за полгода? Я подчеркиваю это, потому что я думаю, что это слишком часто забывается при разработке вещей (а не только кода, эта лошадь-хобби на самом деле с моих дней, как механик-механик, проклинающий инженеров-механиков). Через шесть месяцев, когда я должен поддерживать ваш код (или вы после работы с другим проектом), какой способ хранения и получения данных будет иметь больше смысла. Если переход от плоских файлов к БД приводит к повышению эффективности на 1%, но добавляет неделю, когда выясняется, когда вам нужно обновлять код, вы действительно улучшили ситуацию.
В зависимости от вашей информации и ваших шаблонов доступа и масштаба. Два из самых больших преимуществ реляционных баз данных:
. Если вы не очень умны, вы не можете записать кеш так же хорошо, как на сервере БД
Оптимизатор.
Однако для некоторых специализированных приложений ни одно из этих двух преимуществ не проявляется по сравнению с хранилищем данных файлов и папок, поэтому ответ звучит "зависит".
Что касается файлов/папок, трюки:
Как правило, базы данных медленнее, чем файлы.
Если вам требуется индексирование ваших файлов, жестко закодированный путь доступа к настраиваемым структурам индексирования всегда будет иметь потенциал быть быстрее, если вы сделаете это правильно.
Но "производительность" не является целью при выборе базы данных по решению на основе файлов.
Вы должны спросить себя, нуждается ли ваша система в каких-либо преимуществах, предоставляемых базой данных. Если это так, то небольшие эксплуатационные издержки вполне приемлемы.
Итак:
В основном, вопрос состоит в том, что более легко будет развиваться. Разница в производительности между двумя не стоит тратить время разработки.
Из моего небольшого опыта серверные базы данных (даже те, которые обслуживаются на локальной машине) имеют тенденцию к очень низкой пропускной способности по сравнению с локальными файловыми системами. Однако это зависит от некоторых вещей, одна из которых является асимптотической сложностью. Сравнивая сканирование большого списка файлов с использованием базы данных с индексом для поиска элемента, база данных выигрывает.
Мой небольшой опыт работы с PostgreSQL. У меня был стол с тремя миллионами строк, и я пошел обновлять всего 8000 записей. Это заняло 8 секунд.
Что касается цитаты "Преждевременная оптимизация - это корень всего зла", я бы взял это с солью. Если вы пишете свое приложение с использованием базы данных, то обнаружите, что он работает медленно, для переключения на подсистему на основе файловой системы или что-то еще (например, SQLite) может потребоваться огромное количество времени. Я бы сказал, что ваш лучший выбор - создать очень простой прототип вашей рабочей нагрузки и протестировать его с помощью обоих подходов. Я считаю, что важно знать, что быстрее в этом случае.
Как указывали другие: это зависит!
Если вам действительно нужно выяснить, что будет более эффективным для ваших целей, вы можете захотеть сгенерировать некоторые выборочные данные для хранения в каждом формате, а затем запустить некоторые тесты. Модуль Benchmark.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, когда дело касается изображений, если подходит структура сайта. Создавайте папки, представляющие соответствующие данные, и размещайте изображения внутри. Например, у вас есть сайт статьи, вы храните свои статьи в db. Вам не нужно размещать пути изображения на db, имена папок с вашими первичными ключами, такими как 1,2,3.. и помещать изображения внутрь. Электронные книги, музыкальные файлы, видеоролики, этот подход можно использовать во всех медиафайлах. Такая же логика работает с файлами xml, если вы не будете что-то искать.
Это зависит от профиля данных и от того, какую логику вы собираетесь использовать для доступа к нему. Если вам просто нужно сохранить и получить именованные узлы, тогда база данных на базе файловой системы может быть более быстрой и эффективной. (Вы могли бы также взглянуть на Berkeley DB для этой цели.) Если вам нужно делать индексированные поисковые запросы, и особенно если вам нужно присоединиться к различным наборам данных на основе ключей, тогда вам лучше всего будет база данных SQL.
Я бы просто пошел с любым решением, наиболее естественным для вашего приложения.
Как говорили другие, зависит: от размера и характера данных и от операций, которые вы планируете запускать на нем.
В частности, для CGI script, вы будете подвержены влиянию производительности для подключения к серверу базы данных на каждом просмотре страницы. Однако, если вы создаете наивный подход, основанный на файлах, вы можете легко создать худшие проблемы с производительностью; -)
Как и решение Berkeley DB File, вы также можете использовать SQLite. Это создает интерфейс SQL для базы данных, хранящейся в локальном файле. Вы можете получить доступ к нему с помощью DBI и SQL, но нет сервера, конфигурации или сетевого протокола. Это может обеспечить более легкую миграцию, если в будущем необходим сервер базы данных (пример: если вы решили иметь несколько интерфейсных серверов, но вам нужно предоставить общее состояние).
Не зная подробностей, я предлагаю с помощью решения SQLite/DBI, а затем просмотрю производительность. Это даст гибкость при достаточно простом запуске и достойной производительности.
Чтобы быстро получить доступ к файлам, в зависимости от того, что вы делаете, mmap может быть очень удобным. Я только что написал об этом в блоге Эффективный Perl как Карта памяти файлы вместо того, чтобы разрывать их.
Однако я ожидаю, что сервер базы данных будет намного быстрее. Трудно сказать, что было бы быстрее для вас, когда мы понятия не имеем, что вы делаете, какие данные вам нужны для доступа и т.д.