Данные в файлах XML: один большой файл или несколько маленьких?

Question

В настоящее время я работаю над CMS на основе XML, которая сохраняет данные в виде фрагментов, называемых «элементами». Они могут быть использованы на веб-сайте для отображения контента.

Теперь у меня есть отдельный XML-файл для каждого элемента. Поскольку большинство страниц на этом веб-сайте используют примерно три-четыре таких элемента, довольно маленький веб-сайт, например, 20 страниц содержит около 100 различных предметов. И для этого столько же файлов xml в моей папке / xml / items.

Желательно ли хранить все эти данные в одном файле items.xml или мой нынешний подход лучше?

Pro Single File - xml / items.xml

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

Pro Multiple Files - xml / items / *. Xml

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

Answer 1

Много вдумчивых ответов уже здесь.

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

Некоторые мысли:

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

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

• Независимо от того, выбираете ли вы 1 файл или несколько файлов, вы, скорее всего, сможете решить / абстрагировать любые проблемы с доступом к данным (блокировка, поиск и т. Д.) В коде. Чем больше кода вам нужно написать для выполнения таких задач, как блокировка, поиск, тем больше ошибок вам, вероятно, придется отлаживать.

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

Возможно, вы захотите проверить механизм ведения блога dasBlog Скотта Хансельмана . Я считаю, что по сути это система управления контентом, основанная на XML / текстовых файлах, которая использует многофайловый подход, и это может быть полезно для обзора.

Answer 2

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

Учитывая, что требуется, чтобы повредить файл, преимущество многих файлов состоит в том, что вы не получите один большой удар, а только удар по одному файлу. Блокировка также лучше - поскольку один файл за один раз блокируется для записи вместо полного «основного XML-файла».

Answer 3

Будет ли ваш пользователь работать с файлами XML напрямую или это просто способ хранения данных?

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

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

Answer 4

Я думаю, это зависит от того, сколько памяти имеет ваш сервер; насколько большие файлы XML; и какой парсер вы используете. Если на сервере достаточно памяти, я думаю, что один XML-файл предпочтительнее, поскольку он может быть кэширован в памяти, а затем легко проанализирован. Я думаю, что это перевесило бы IO при открытии / чтении многих файлов.

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

Answer 5

Если вы храните все XML-документы в одном файле и индексном файле, который отображает имя каждого документа в том месте, где он начинается в файле (документов), вы получите:

• Меньше файлов
• Меньше доступа к диску
• Ускоренный доступ к одному документу

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

Answer 6

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