Существуют ли веские причины для внутреннего хранения данных в виде XML?

Question

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

Веб-сервис

Первое приложение, веб-служба, предоставляет доступ к потенциально большому объему данных в базе данных SQL. При запуске он более или менее извлекает все эти данные из базы данных и сохраняет их в памяти в виде XML. (Три раза.) Владельцы этого приложения называют его кешем. Я называю это медленным, потому что каждая проблема с перфорированием, с которой столкнулись при работе с этим, была непосредственно прослежена до этой вещи. (Это корпоративная среда, поэтому не удивительно, что клиент виноват в сбое perf, а не в сервисе.) Это приложение использует XML DOM.

Импортер

Второе приложение считывает файл XML, созданный в результате экспорта из сторонней базы данных. Цель состоит в том, чтобы импортировать эти данные в проприетарную систему (принадлежит нам). Приложение, которое делает это, считывает весь XML-файл и поддерживает по крайней мере две, иногда до четырех, копии XML-файла во всей последовательности импорта. Обратите внимание, что данные могут быть обработаны, преобразованы, и конфигурация может произойти до того, как произойдет импорт, поэтому импортер владеет этими данными в формате XML на протяжении всего срока их службы. Неудивительно, что этот импортер затем взрывается, когда предоставляется XML-файл умеренного размера. Это приложение использует XML DOM только для одной из своих копий, а все остальные являются необработанными XML-строками.

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

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

Answer 1

Все данные, хранящиеся в памяти, должны быть в классах. Чем выше объем данных, о которых мы говорим, тем важнее это становится. Xml - чрезвычайно раздутый формат, который снижает производительность. Xml следует использовать только для передачи данных между приложениями. ИМХО.

Answer 2

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

Во-вторых, вы должны как можно скорее преобразовать XML в полезное представление, возможно, в базу данных, а затем работать с ним таким образом. Только если это небольшой объем данных, было бы целесообразно выполнять всю работу в памяти как XmlDocument (например, с использованием XPath). Разбор строк должен использоваться очень экономно.

Answer 3

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

Мы все постоянно учимся чему-то новому и все делаем ошибки. Хотя я согласен с тем, что это похоже на «скучную» проблему, я уверен, что другие разработчики пытались оптимизировать код с помощью концепции кеша.

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

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

Удачи!

Answer 4

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

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

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

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

Answer 5

Для больших объемов данных ответ отрицательный, нет веских причин хранить данные непосредственно в виде XML-строк в памяти.

Однако вот интересная презентация Алекса Брауна о том, как сохранить XML в памяти более эффективным способом. Как «Ледяной поток».

Также есть видео об этом и другие презентации, представленные на XML Prague 2009 здесь .

текст ссылки

Answer 6

Грег

в нескольких приложениях я следовал более или менее точно описанному вами шаблону:

Редактировать: не надо ничего царапать. Я никогда не хранил XML как строку (или несколько строк). Я просто разобрал его в DOM и работал с этим. Это было полезно.

Я импортировал источники XML в DOM (Microsoft Parser) и сохранил их там для всей необходимой обработки. Я хорошо осведомлен о накладных расходах памяти, вызываемых DOM, но, тем не менее, я нашел это применение весьма полезным.

• Некоторые проверки во время обработки требуют произвольного доступа к данным. Оператор selectPath работает довольно хорошо для этой цели.

• Узлы DOM могут передаваться в приложении взад и вперед в качестве аргументов. Альтернативой является написание классов, обертывающих каждый тип объекта, и обновление их по мере развития схемы XML. Это подход бедного (VB6 / VBA) человека к полиморфизму.

• Применение преобразования XSLT ко всем или частям DOM совсем несложно

• Файловый ввод / вывод позаботится и о DOM (xmldoc.save ...)

Связанный список объектов будет занимать сопоставимый объем памяти и потребовать больше кода. Все функции поиска и ввода / вывода я должен был бы кодировать сам.

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

Answer 7

как насчет ООП и баз данных? Xml использует его, но могут быть проблемы (как вы видите) с его использованием для всего.

Базы данных могут включать индексацию, транзакции и т. Д., Что ускорит доступ к вашим данным

С объектами в большинстве случаев проще работать, они дают лучшую картину вашего домена и т. Д.

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

Answer 8

Я обнаружил, что должен был сделать это, чтобы взаимодействовать с устаревшим COM-объектом. COM-объект может принимать либо xml, либо класс. Затраты на взаимодействие для заполнения каждого члена класса были слишком большими, и обработка xml была намного более быстрой альтернативой. Мы могли бы создать класс c #, идентичный классу COM, но это было слишком сложно сделать в наши сроки. Так что XML это было. Не то чтобы это когда-либо было бы хорошим дизайнерским решением, но когда речь шла о взаимодействии для больших структур данных, это было самое быстрое, что мы могли сделать.

Я должен сказать, что мы используем LinqtoXML на стороне C #, поэтому с ним немного легче работать.

Answer 9

Я тоже согласен, и я думаю, что есть элемент невезения.

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