Использование XML в качестве хранилища данных [закрыто]

Я думал о формате XML и следующей цитате:

«XML не является базой данных. Это никогда не предназначалось для базы данных. Это никогда не будет база данных. Реляционные базы данных - это проверенная технология с более чем 20-летним опытом внедрения. Это твердые, стабильные, полезные продукты. Они не уходят. XML - очень полезная технология для перемещения данных между различными базами данных или между базами данных и другими программами. Тем не менее, это не сама база данных. Не используйте его , как один «. - Эффективный XML: 50 конкретных способов улучшить свой XML с помощью Эллиотт Расти Гарольд (стр 230, часть 4, пункт 41, второй абзац)

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

Лично я не согласен, и app.configфайл .NET, который используется для хранения настроек программы, является примером хранения данных в файле XML. Однако для баз данных, а не для конфигураций и т. Д. Не следует использовать XML.

Чтобы развить свою точку зрения, я буду использовать два примера:
A) Данные о клиентах с полями, которые все находятся на одном уровне, то есть имеется ряд полей, относящихся к одному клиенту без детей
B) Данные о конфигурации приложения, в котором вложенные поля и свойства имеют большой смысл

Итак, мой вопрос: это все еще допустимое утверждение и теперь допустимо ли хранить данные с использованием XML?

РЕДАКТИРОВАТЬ: Я отправил электронное письмо автору этой цитаты, чтобы попросить его ввода / дополнительный контекст.

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

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

Однако XML не совсем соответствует этим требованиям. Из-за структуры вложенных тегов невозможно определить, где в файле хранится определенное значение (с точки зрения байтового смещения в файле) без обхода всего дерева документа, по крайней мере, до совпадения. Реляционная база данных имеет индексы, и поиск значения в индексе, даже с примитивной реализацией бинарного поиска, представляет собой одиночный поиск O (log n), а затем получение к действительным значениям - не что иное, как поиск файла (например, fseek(data_file_handle, row_index * row_size)), который является O (1). В XML-файле наиболее эффективный способ - запустить SAX-парсер над вашим документом, выполняя огромное количество операций чтения и поиска, прежде чем вы получите свои настоящие данные; вы вряд ли получите это лучше, чем O (n), если только вы не используете индексы, но тогда вам придется перестраивать весь индекс для каждой вставки (см. ниже).

Вставка еще хуже. Реляционные базы данных не гарантируют порядок строк, что означает, что они могут просто добавлять новые строки или перезаписывать любые строки, помеченные как «удаленные». Это очень быстро: БД может просто хранить пул доступных для записи мест; получение записи из пула - O (1), если пул не пуст; в худшем случае пул пуст, и необходимо создать новую страницу, но это тоже O (1). В отличие от базы данных на основе XML придется перемещать все после точки вставки, чтобы освободить место; это O (n). Когда в игру вступают индексы, все становится еще интереснее: типичные индексы реляционных баз данных могут обновляться с относительно низкой сложностью, например, O (log n); но если вы хотите проиндексировать ваши XML-файлы, каждая вставка потенциально меняет расположение на диске каждого значения в документе, поэтому вам нужноперестроить весь индекс . Это также относится и к обновлениям, потому что обновление, скажем, текстового содержимого элемента может изменить его размер, что означает, что последовательный XML должен сместиться. Реляционная база данных вообще не должна касаться индекса, если вы обновляете неиндексированный столбец; базе данных XML придется перестраивать весь индекс для каждого обновления, которое изменяет размер обновленного узла XML.

Это самые важные недостатки, но есть и другие. XML очень многословен, что хорошо для межсерверного взаимодействия, поскольку он добавляет безопасность (принимающий сервер может выполнять все виды проверок целостности XML, и если что-то пошло не так при передаче, документ вряд ли будет проверен ). Однако для массового хранилища это убивает: нередко бывает, что 100% или больше накладных расходов для данных XML (довольно часто можно видеть коэффициенты накладных расходов в диапазоне 1000% для таких вещей, как сообщения SOAP), в то время как типичное реляционное хранилище БД схемы имеют только постоянные издержки для метаданных таблицы, плюс крошечный бит на строку; большая часть накладных расходов в реляционных базах данных приходится на фиксированную ширину столбцов. Если у вас есть терабайт данных, 500% накладных расходов просто неприемлемо по многим причинам.

XML паршит для хранения данных. Во-первых, это очень многословно. Данные, хранящиеся в файле XML, занимают гораздо больше места на диске, чем те же данные, хранящиеся в любой разумной системе баз данных. В записи XML имя отдельного поля будет сохранено дважды вместе со строковым представлением данных. Так, например, чтобы сохранить один целое в поле с именем «foobar», вы получите 19-байтовую строку:

<foobar>42</foobar>

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

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

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

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

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

XML является жизнеспособным в зависимости от контекста. Если ваши данные довольно статичны и не сильно меняются (например, пример данных), да, XML - это хорошее применение.

Настройки конфигурации, примеры данных (даже если это миллионы строк, но редко меняются) - все это хорошее использование XML.

Чтение / запись на жесткий диск обходятся дороже, чем доступ к данным из стека Oracle / Sql.

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

Ваша предпосылка ошибочна.

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

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

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

Это действительно субъективно. Эта цитата, чье-то мнение, человек.

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

Взгляните на dasBlog и BlogEngine . Оба этих приложения используют XML для хранения по умолчанию.

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

мой вопрос: это все еще допустимое утверждение и теперь приемлемо ли хранить данные с использованием XML?

Я вижу в вашем примере пример файлов конфигурации .NET. Однако можно использовать любой другой формат файла. Фактически, в прежние времена такие параметры хранили в обычных текстовых файлах, называемых INI-файлами.

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

Определение XML в XML-Definition гласит, что «(XML) - это язык разметки, который определяет набор правил для кодирования документов в формате, который читается человеком и читается машиной».

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

По сравнению с РСУБД XML не предоставляет средств для случайной вставки и удаления строк в XML-файле. Например, если у вас есть 1000000 строк, и вы хотите удалить строки случайным образом даже в однопользовательской среде, XML-файл не будет хорошим выбором для базы данных. Кроме того, XML не предоставляет никаких собственных механизмов для блокировки данных. Фактически, поскольку XML не является программным обеспечением, все свойства ACID (атомарность, непротиворечивость, изоляция, долговечность), которые гарантируют, что транзакции базы данных обрабатываются надежно в общей среде, остаются за разработчиком для разработки (за исключением Durability). XML не имеет надежной спецификации для обработки целостности данных в файлах XML, не говоря уже о разных серверах (например, XML-файл клиента и XML-файл заказов - нет FK для обеспечения целостности).

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

XML никогда не хотел быть базой данных или заменить ее.

XML в основном определен для веб-документов, которые allows for the creation of customized tags for individual information fields., тем не менее, никогда не обеспечат централизованное реляционное управление данными.

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

Хотя можно утверждать, что это гибкий и простой для понимания формат, он применяется только тогда, когда вам нужно вручную редактировать файлы. Когда вы на самом деле взаимодействуете с базой данных с помощью общего интерфейса (выборка данных X, которая отвечает требованиям Y и Z, сохранение / обновление данных X, ...), эти преимущества становятся недействительными.

Краткий ответ: это зависит.

Длинный ответ: С моей точки зрения, это сильно зависит от объема данных, которые вы хотите сохранить. Например, если у вас есть пара объектов в приложении во время выполнения, и вы хотите сохранить их после запуска инструмента, файл XML отлично подойдет. Однако, если ваш интернет-магазин имеет 5000 клиентов и даже больше заказов, база данных будет более подходящим хранилищем данных.

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

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

XML обычно не следует использовать в качестве основного источника данных для любых нетривиальных приложений. Только издержки сериализации / десериализации требуют другого решения.

Термин « база данных» может относиться либо только к необработанным данным, либо к системе управления базой данных. Это определение имеет большое значение во всем аргументе.

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

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

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

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

Базы данных, с другой стороны, превосходны, когда у вас есть тысячи (или миллионы / миллиарды) записей, и многие пользователи одновременно обновляют их. Так что да, XML не является базой данных, и вы не должны использовать его как один. Ваш пример оказался одной из тех ситуаций, когда вам не нужна БД, и XML лучше подходит.

Я вижу это так: если вы используете XML в качестве БД (скажем, в качестве резервного хранилища для транзакционной системы), вы в конечном итоге заново изобретаете и переписываете СУБД . Это действительно плохой способ тратить свое время и энергию. Я думаю, что это то, что говорила эта цитата.

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

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

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

Вы можете использовать инструменты ORM, такие как Hibernate, и инструменты, такие как Apache Axis, чтобы автоматически генерировать практически весь код, необходимый для создания службы, которая просто обрабатывает простые операции CRU. Конечно, вы должны будете обернуть это в аутентификацию и, возможно, захотите разделить данные в зависимости от пользователя, уровня доступа и т. Д. Возможно, вы даже захотите ограничить операции, которые данному пользователю разрешено выполнять через службу SOAP для пример.

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