Недостатки к наличию (потенциально) тысяч каталогов в сервере вместо базы данных?

Я думаю, главное здесь то, что ваши данные НЕ будут индексироваться. SO, чтобы получить что-либо, скажем, поиск будет до смешного медленным по сравнению с индексированной базой данных. Кроме того, операции ввода-вывода дороги, база данных может (частично) находиться в памяти, что делает доступными данные намного быстрее.

Это действительно зависит от:

• Каков размер файла
• Какие у вас требования к долговечности?
• Сколько обновлений вы выполняете?
• Что такое файловая система?

Не очевидно, что MySQL будет быстрее:

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

File System:   XFS     ext3 
-----------------------------
Writes/s:      322     20,000

Data Base \  Indexes:    Key Only   Key+Timeout
-----------------------------------------------
Berkeley DB              34,400      1,450
Sqlite No Sync            4,600      3,400
Sqlite Delayed Commit    20,800     11,700

Как видите, с простой файловой системой Ext3 было быстрее или так же быстро, как Sqlite3 для хранения данных, потому что он делает не даст вам (D) ACID.

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

Помните, что БД не всегда бутылочное горлышко системы

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

Я думаю, что развитие модели было бы труднее сделать в структуре папок, чем в БД.

Кроме того, базы данных обычно НАМНОГО быстрее, чем доступ к файлам из-за индексации и кэширования памяти.

Забудьте о длинных ответах, вот простейшие причины, по которым хранение данных в файлах с открытым текстом - плохая идея:

1. Практически невозможно запросить. Как бы вы отсортировали сообщения в блоге по дате? Вам придется читать все файлы и сравнивать их даты или поддерживать свой собственный индексный файл (по сути, написать свою собственную систему баз данных).

2. Резервное копирование - кошмар. tar cjf не будет вырежьте его, и если вы попытаетесь, у вас может получиться несовместимый снимок.

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

IIRC Fudforum использовал хранилище файлов из соображений скорости, гораздо быстрее захватить файл, чем искать по индексу БД, извлекать данные из БД и отправлять их пользователю. . Вы обмениваете интерфейс файловой системы с интерфейсами DB и DB-библиотеки.

Однако это не значит, что он будет быстрее или медленнее. Я думаю, вы обнаружите, что запись в файловой системе выполняется быстрее, но при общих проблемах чтение в БД происходит быстрее. Если, как и у fudforum, у вас есть относительно неизменяемые данные, которые вы хотите показать несколько сообщений в одном, то подход на основе файлов может быть намного быстрее: например, им не нужно искать все связанные сообщения, они вставляют все это в 1 текстовый файл и отобразить его один раз. Если вы сможете использовать такую ​​оптимизацию, то ваш файловый подход будет работать.

Кроме того, почтовые серверы также работают с файловым подходом, в формате Maildir каждое сообщение электронной почты хранится в виде файла в каталоге, а не в базе данных.

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

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

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

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

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

@ Комментарий Эрика: Это зависит от того, что вам нужно. Если вам нужно только точное содержимое файла для каждого запроса, и вы можете определить местоположение и имя файла детерминированным способом, прямой доступ будет быстрее, чем то, что делает база данных, что примерно:

• доступ к группе записи индекса, чтобы
• получить доступ к набору строк таблицы (rdbms обычно читают блоки, содержащие несколько строк), чтобы
• выбрать одну строку из блока.

Если вы посмотрите на нее: вы имеют индексы и дополнительные строки в памяти, что делает ваше кеширование неэффективным, откуда взяться ускорению базы данных?

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

... а затем вы хотите выполнить поиск по всем сообщениям автора, и вы можете прочитать миллион файлов вместо простого запроса SQL ...

if you are preferred to go away with RDBMS, why dont u try the other open source key value or document DBs (Non- relational Dbs)..

From ur posting i understand that u r not goin to follow any ACID properties of relational db.. it would be better to adapt other key value dbs (mongodb,coutchdb or hyphertable) instead of your own file system implementation.. it will give better performance than the existing approaches..

Note: I am not also expert in this.. just started working on MongoDB and find useful in similar scenarios. just wanted to share in case u r not aware of these approaches