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

Question

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

Что я имею в виду: Вместо базы данных, в которой хранится таблица блога, есть строка с «автором», «сообщением» и «датой»: Папка для определенного сообщения, затем файлы * .txt внутри этой папки, в которых хранятся «автор», «сообщение» и «дата».

Answer 1

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

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

Базы данных созданы для быстрого доступа к данным и их поиска. Файловые системы созданы для хранения данных. Используйте правильный инструмент для работы. В данном случае это абсолютно база данных.

При этом, если вы хотите создать HTML-файлы для постов, а затем сохранить эти локали в БД, чтобы вы могли легко получить к ним доступ, то это определенно хорошее решение (в стиле Movable Type).

Но если вы храните эти вещи в файловой системе, как вы можете найти свой последний пост? Самый плодовитый автор? Самый спорный автор? Все это тривиально с базой данных, и очень сложно с файловой системой. Придерживайтесь базы данных, вы будете рады, что сделали.

Answer 2

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

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

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

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

Answer 3

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

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

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

Помните, что DB не всегда горлышко системы

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

, если вы предпочитаете уходить с RDBMS, почему бы вам не попробовать другое значение ключа с открытым исходным кодом или БД документа (нереляционные БД) ..

Из вашей публикации я понимаю, что вы не собираетесь следовать никаким ACID-свойствам реляционных БД. Было бы лучше адаптировать другие значения ключей dbs (mongodb, coutchdb или hyphertable) вместо вашей собственной реализации файловой системы. дать лучшую производительность, чем существующие подходы ..

Примечание: Я также не эксперт в этом .. только начал работать над MongoDB и считаю полезным в подобных сценариях. просто хотел поделиться, если вы не знаете об этих подходах

Answer 9

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

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

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

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

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

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

Если вы посмотрите на это: у вас есть индексы и дополнительные строки в памяти, которые делают ваше кеширование неэффективным, откуда должно произойти ускорение БД?

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