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

Question

Если бы у меня была статическая база данных, состоящая из папок и файлов, был бы доступ и манипулирование быстрее, чем у баз данных типа SQL-сервера, учитывая, что это будет использоваться в сценарии CGI?

При работе с файлами и папками, какие приемы повышения производительности?

Answer 1

Я добавлю к толпе, которая зависит от этого.

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

Некоторые вопросы, которые я хотел бы задать себепри выборе необходимо указать:

1. Как я потребляю данные?Например, я буду просто читать строки от начала до конца в указанном порядке?Или я буду искать строки, которые соответствуют нескольким критериям?

2. Как часто я буду получать доступ к данным во время выполнения одной программы?Пойду ли я один раз, чтобы получить все книги с Сэлинджером в качестве автора, или я пойду несколько раз, чтобы получить нескольких разных авторов?Пойду ли я несколько раз по нескольким критериям?

3. Как я буду добавлять данные?Могу ли я просто добавить строку в конец, и это идеально подходит для моего поиска, или его нужно будет восстановить?

4. Насколько логичным будет выглядеть код через шесть месяцев? Я подчеркиваю это, потому что я думаю, что об этом слишком часто забывают при проектировании вещей (не просто код, эта лошадь-хобби на самом деле из моих дней, когда механик ВМС проклинал инженеров-механиков).Через шесть месяцев, когда мне придется поддерживать ваш код (или вы делаете после работы над другим проектом), какой способ хранения и извлечения данных будет более целесообразным.Если переход от простых файлов к БД приводит к повышению эффективности на 1%, но добавляет неделю на то, чтобы выяснить, когда вам нужно обновить код, действительно ли вы улучшили вещи.

Answer 2

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

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

2. Optimizer.

Однако для некоторых специализированных приложений ни одно из этих двух преимуществ не проявляется по сравнению с хранилищем данных файлов + папок - поэтому ответ является громоздким «зависит».

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

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

Answer 3

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

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

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

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

Итак:

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

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

Answer 4

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

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

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

Answer 5

Как уже отмечали другие: это зависит!

Если вам действительно необходимо выяснить, какие из них будут более эффективными для ваших целей, вы можете сгенерировать некоторые примеры данных для хранения в каждом формате и затем выполнить некоторые тесты. Модуль 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, чтобы получить более полную документацию.

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

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

Answer 10

Как и другие, упомянутая БД - это инструмент, и он создает некоторые накладные расходы, но в случае, если ваши данные статичны и они доступны только для чтения, каталог чтения данных из файлов будет быстрее: Вот несколько тестов, которые я сделал: У меня были файлы с именем файла .csv В базе данных я проиндексировал столбец как «дата», чтобы найти те же записи в базе данных. Каждый день содержит 30–50 тыс. Записей / строк и 100 столбцов данных различного типа (с плавающей запятой 90%).

Информация о БД: PostgreSQL 11,5, 16 ГБ ОЗУ

  Table:
    335,162,867 records
    Table size: 110GB
    Index size: 7GB
    Total size: 117GB
  Files:
    Number of files: 8033
    Total Files size: 158GB
    Number of records/lines per file/date: 30K - 50K

Чтение данных для случайной даты (1986-2019) из файла постоянно В 4-5 раз быстрее, чем чтение данных за ту же дату в PostgreSQL