解析外部 XML 或访问数据库更有效吗？答案

【问题标题】：Is it more efficient to parse external XML or to hit the database?解析外部 XML 或访问数据库更有效吗？
【发布时间】：2010-11-01 23:46:11
【问题描述】：

我想知道在处理返回 XML 的 Web 服务 API 时，每次只调用外部服务并解析 XML（使用 ElementTree）以显示在您的网站上还是将记录保存到中是否更好（更快）数据库（在您每天需要解析一次或多次之后）并为相同的信息进行数据库调用。

【问题讨论】：

标签： python mysql xml django parsing

【解决方案1】：

首先——测量。不要只是假设一个比另一个更好或更差。

其次，如果你真的不想测量，我猜数据库会快一点（假设数据库与 Web 服务相比是相对本地的）。网络延迟通常超过解析时间，除非我们谈论的是非常复杂的数据库或非常复杂的 XML。

【讨论】：

【解决方案2】：

每个人在回答这个问题时都非常有礼貌：“这取决于”......“你应该测试”......等等。

的确，这个问题并没有详细介绍所涉及的应用程序和网络拓扑，但如果甚至有人问这个问题，那么很可能 a) 数据库对于应用程序来说是“本地的”（在同一个子网上，或同一台机器，或在内存中），并且b）网络服务不是。毕竟，OP 使用“外部服务”和“在您自己的站点上显示”这样的短语。短语“每天需要解析一次或多次”也暗示了一组数据并不是每秒都在变化。

经典的 SOA 神话是网络始终可用；更进一步，我会说网络始终以低延迟可用是一个神话。除非您自己的内部系统很糟糕，否则通过 Internet 发送 HTTP 查询总是比查询本地数据库或数据库集群慢。造成这种情况的原因有很多：远程服务器的跳数、您无法在远程端控制的中断或降级问题，以及远程 Web 服务应用程序分析您的请求的内部处理时间，点击它自己的持久化后端（又名 DB），并返回结果。

启动您的应用程序。对您的数据库做一些延迟和响应时间。现在对远程 Web 服务执行相同的操作。除非您的数据库也在互联网上，否则您会发现巨大的差异。

对于一个称职的技术人员来说，扩展数据库并不难，或者您使用 memcached 和其他范例完全从缓存中删除数据库；数据中心中彼此靠近的服务器之间的延迟远小于 Internet 上的机器之间的延迟（并且更安全，可以启动）。即使实现这个规模需要一些思考，它在你的控制之下，不像远程 Web 服务，它的扩展和延迟对你来说是完全不透明的。一方面，我对我的网站的可用性和响应能力完全基于其他人的想法不太满意。

最后，如果远程 Web 服务不可用怎么办？想象一个世界，对您的站点的每个请求都涉及通过 Internet 对某个其他站点的请求。如果该其他站点不可用怎么办？您的用户是否会连续数小时观看旋转的死亡光标？当您的网站因这种意外的外部依赖而陷入困境时，他们是否享受错误 500？

如果您发现自己采用的架构的基本功能取决于每个请求的远程 Internet 调用，请在决定是否可以承受后果之前仔细考虑您的应用程序。

【讨论】：

你仔细阅读问题了吗？听起来主要结果总是来自外部 Web 服务，所以网络中断已经是需要处理的事情了。此外，听起来有问题的 Web 服务仅在客户端主机外部，但在宏伟的计划中可能是本地的。

【解决方案3】：

使用 Web 服务更有效，因为您可以做很多事情来扩展您的 Web 服务和 Web 服务器（通过缓存等）。通过使用中间层，您还可以选择更改返回的数据格式（例如，您可以决定使用 JSON 而不是 XML）。扩展数据库要困难得多（涉及复制等），所以一般来说，如果可以的话，减少对 DB 的访问。

【讨论】：

【解决方案4】：

在一般情况下，没有足够的信息可以肯定地说。你为什么不做一些测试并找出答案？因为听起来你正在使用 python，所以你可能想要使用 timeit 模块。

一些可能影响结果的事情：

您正在使用的网络服务的性能
您使用的网络服务的可靠性
服务器之间的距离
返回的数据量

我猜如果它是可缓存的，数据的缓存版本会更快，但这并不一定意味着使用本地 RDBMS，它可能意味着类似 memcached 或应用程序中的内存缓存。

【讨论】：

也许更重要的是：远程站点的更新频率与本地站点的访问频率。

【解决方案5】：

这取决于 - 谁在调用 Web 服务？每次用户点击页面时都会调用 Web 服务吗？如果是这种情况，我建议您引入某种缓存层 - 许多 Web 服务 API 会限制您每小时可以进行的点击量。

您是选择动态解析缓存的 XML 还是从数据库中调用数据可能并不重要（除非我们在这里讨论的是企业扩展）。就个人而言，我宁愿做一个简单的 SQL 调用，也不愿编写一个 DOM 解析器（这更容易出现异常情况）。

【讨论】：

【解决方案6】：

这取决于具体情况，您必须衡量（或至少做出有根据的猜测）。

你必须考虑几件事情。

网络服务

它可能会攻击数据库本身
可以缓存
它会引入网络延迟并且可能不可靠
或者它可以在本地网络中，甚至比访问本地磁盘更快

数据库

可能会很慢，因为它需要访问磁盘（虽然数据库有内部缓存，但这些通常不是目标）
应该是可靠的

技术本身在速度方面并没有多大意义——在一种情况下，数据库解析 SQL，在另一种 XML 解析器中解析 XML，并且数据库通常也通过套接字访问，因此在任何一种情况下你都有解析和网络。

在您的应用程序中缓存数据（如果适用）可能是个好主意。

【讨论】：

【解决方案7】：

正如一些人所说，这取决于，你应该测试它。

通常外部服务很慢，在本地缓存它们（在内存中的数据库中，例如，使用 memcached）更快。但也许不是。

幸运的是，它既便宜又易于测试。

【讨论】：

【解决方案8】：

绝对测试。根据经验，XML 有利于应用程序之间的通信，但是一旦您在应用程序中获取了数据，所有内容都应该放入数据库表中。这可能不适用于所有情况，但 95% 的时间都适用于我。每当我尝试以任何其他方式存储数据（例如内容管理系统中的 XML）时，我最终都希望我能使用好的旧 sprocs 和 sql server。

【讨论】：

【解决方案9】：

听起来您实际上想要缓存结果，并且想知道它是否值得。但如果是这样，我不会使用数据库（我假设您正在考虑关系数据库）：RDBMS 不适合缓存；即使许多人使用它们。你不需要持久性也不需要酸。如果要在 Oracle/MySQL 和外部 Web 服务之间进行选择，我会从使用服务开始。

相反，考虑真正的缓存系统；本地与否（memcache、简单的内存缓存等）。或者如果你必须使用数据库，使用键/值存储，BDB 效果很好。以序列化形式（XML）存储响应消息，尝试从缓存中获取，如果没有，则从服务中解析。或者，如果有一个方便且更紧凑的序列化，存储和获取它。

【讨论】：