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

Question

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

Answer 1

Первый раз - мера. Не просто предполагайте, что одно лучше или хуже другого.

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

Answer 2

Все очень вежливо отвечают на этот вопрос: «это зависит» ... «ты должен проверить» ... и т. Д.

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

Классический миф о SOA заключается в том, что сеть всегда доступна; Если пойти еще дальше, я бы сказал, что это миф, что сеть всегда доступна с низкой задержкой. Если ваши собственные внутренние системы не являются дерьмом, отправка HTTP-запроса через Интернет всегда будет медленнее, чем запрос к локальной БД или кластеру БД. Причин этому может быть несколько: количество переходов на удаленный сервер, проблемы с перебоями или ухудшением, которые вы не можете контролировать на удаленном конце, а также время внутренней обработки приложением удаленной веб-службы для анализа вашего запроса. собственный бэкэнд персистентности (он же DB) и возврат результата.

Запустите ваше приложение. Сделайте некоторое время ожидания и время отклика для вашей БД. Теперь сделайте то же самое с удаленным веб-сервисом. Если ваша БД также не находится в Интернете, вы заметите огромную разницу.

Для компетентного технолога совсем нетрудно масштабировать БД или для вас полностью удалить БД из кэширования, используя memcached и другие парадигмы; задержка между серверами, расположенными рядом друг с другом в центре обработки данных, значительно меньше, чем между компьютерами через Интернет (и более безопасна для загрузки). Даже если для достижения этого масштаба требуется некоторая мысль, он находится под вашим контролем, в отличие от удаленного веб-сервиса, масштабирование и задержка которого абсолютно непрозрачны для вас. Я, например, не был бы слишком доволен идеей, что доступность и отзывчивость моего сайта полностью зависит от кого-то другого.

Наконец, что произойдет, если удаленный веб-сервис недоступен? Представьте себе мир, в котором каждый запрос на ваш сайт включает в себя запрос через Интернет на какой-либо другой сайт. Что произойдет, если этот другой сайт недоступен? Ваши пользователи смотрят вращающийся курсор смерти в течение нескольких часов? Им нравится Ошибка 500, пока ваш сайт скрывается от этой неожиданной внешней зависимости?

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Некоторые вещи, которые могут повлиять на результат:

• Производительность веб-службы, которую вы используете
• Надежность веб-службы, которую вы используете
• Расстояние между серверами
• Количество возвращаемых данных

Я бы предположил, что если он кешируется, то кешированная версия данных будет быстрее, но это не обязательно означает использование локальной СУБД, это может означать что-то вроде memcached или кеша в памяти вашего приложения.

Answer 6

Звучит так, как будто вы действительно хотите кешировать результаты, и вам интересно, стоит ли это того. Но если так, я бы НЕ использовал базу данных (я полагаю, вы думаете о реляционной БД): СУБД не годятся для кэширования; хотя многие используют их. Вам не нужно ни настойчивости, ни КИСЛОТЫ. Если бы выбор был между Oracle / MySQL и внешним веб-сервисом, я бы начал с использования только сервиса.

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

Answer 7

Тест определенно. Как правило, XML удобен для обмена данными между приложениями, но как только у вас есть данные внутри приложения, все должно войти в таблицу базы данных. Это может применяться не во всех случаях, но в 95% случаев это для меня. Каждый раз, когда я пытался хранить данные любым другим способом (например, XML в системе управления контентом), я заканчивал тем, что хотел бы просто использовать старые добрые sprocs и SQL Server.

Answer 8

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

Часто внешние службы работают медленно, и их кэширование локально (в базе данных в памяти, например, с memcached) происходит быстрее. Но, возможно, нет.

К счастью, это дешево и легко тестируется.

Answer 9

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

Вам придется рассмотреть несколько вещей.

Веб-сервис

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

DB

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

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

Кэширование данных в вашем приложении, если применимо, вероятно, хорошая идея.