级别： 初级 Cameron Laird (Cameron@Lairds.com), 副总裁, Phaseit，Inc.
2002 年 7 月 01 日 XML 存储器这个主题太庞杂了，以至于难以给出简单的答案。不存在最快的 XML 数据库，也不存在最快的 XML 处理语言。尽管如此，理解 XML 持久性的基本概念还是很有帮助的，这样您就可以将其应用于特定情况。本文是关于高性能 XML 的
developerWorks新系列文章的第一篇，它解释了 XML 持久性（即超出单一进程生命周期的数据存储器）方面的一些常见业界实践。
您负责大型的、关键任务 XML 程序。
您有数十个、或者可能是数千个并发用户。
您的 XML 试验程序运行得很好，并且您已经部署了越来越多的特性。您的系统在连续使用，但响应时间开始迟缓。您开始考虑：“如何最大限度地提高 XML 性能呢？”
答案是：您并不希望最大限度地提高 XML 性能。
您需要满足工程需求。您可能需要管理可伸缩性，或需要极大地提高特定应用程序的响应度。
请不要寻找最快的 XML 存储器。那样做困难重重，而且有可能适得其反。相反，要学会应用 XML 的基本概念，这样您就可以设计自己的情况所需要的持久性。
XML 是通用的
XML 最关键的特点就是，它是一项通用的技术。XML 弥补了许多技术之间的缝隙。它可能出现在从手提电话到大型机的各种硬件上。因此，不存在单一最快的 XML 数据库。性能度量取决于多种因素，包括：
- 您是在进行查询还是进行检索和更新的混合
- 您的数据在本质上适合 XML 面向树的模型还是适合更表格式的模型
- 典型事务的大小
- 物理海量存储器的特性（它是 RAID 吗？寻道时间和吞吐率相比怎么样？）
- 多字节编码的密度
设计 XML 持久性的首要原则是任何解决方案都必须能使
组织轻松适应。如果您的公司需要使用 Java 技术，而某种特殊的 XML 数据库的 Java 绑定很差，那么就不要选择该数据库。无论其标准基准性能有多高，您的同事都很可能无法很好地利用它。
他们将为使用不熟悉的技术而感到困扰，并且不大可能取得满意的效果。另一方面，假如您的工作环境对某种数据库（如 DB2）提供了大量支持。那么，无论您的 XML 内容对 DB2 持久性模型的适应是好还是差，您都应该认真地考虑 DB2 存储器。正如本文要向您展示的，充满热情、良好训练和具有原动力的专门技能，很可能克服技术级别上一定程度的不匹配。
XML 持久性的主要类别集中在这些技术上：
- 本机文件系统
- 关系数据库管理系统（RDBMS）
- 专用 XML 数据库管理器
- 其它数据管理器
最容易的 XML 存储器是
本机的：将 XML 文档实例保持为文件系统中的命名文件。这是最透明和灵活的持久性方法，并应该成为新设计的缺省起点。
当文档实例不超过中等大小且复杂性也属一般时，本机 XML 存储器工作得最好。金融事务（如发票和收据）可能被编码成数 KB 到数百 KB 的 XML 文档。对于处理此类 XML 事务的应用程序而言，很难胜过本机文件系统存储器。实际上，有很多组织由于迁移到明显更复杂的数据管理器而
恶化了其性能和存储器容量的例子。功能齐全的数据库管理器不可避免地包含索引、编码以及其它通用缩放技术的开销。任何单一应用程序对通用缩放模型的适应都可能很差，以至于看起来只有数据管理成本而得不到任何益处。
请记住，您使用 XML 最强烈的动机之一可能就是风险管理。当您将 XML 建立为标准时，就增强了您的数据对消费者群体、供应商产品、政府法规的更改和其它危险的应变能力。但是，如果将 XML 数据隐藏在专用数据管理器或其它以狭窄技术为基础的持久性方法中，那么您会大幅度地牺牲 XML 所能够提供的风险管理，或降低针对环境变化的保护能力。
高速缓存策略
但是，没有理由感到失望。假定您有一种类似于文件系统存储器的持久性技术，它满足了您的功能性需求，但不符合性能标准。有大量的技术弥补手段适用于这种情况：更快的海量存储器、更多主内存以及其它硬件升级通常是最快捷和最廉价的解决方案。如果您已经用尽了这些简单的补救方法，那么，将持久性和性能两方面分离开来进行分析。我发现高速缓存是一种对各种数据管理模型有用的策略。
我保持持久性后端体系结构不变，对健壮性和通用性进行优化。以此为基础，我可以对特定于应用程序的代理或高速缓存进行分层，以便尽可能快地提供数据。
这个方法对 XML 数据如此有效的原因之一是 XML 内容可能是高度冗余的。特定应用程序通常仅需要任一 XML 文档数据中的一些位。根据 XML 传道士提出的所有自记载的理由，最好以 XML 格式保存数据。同时，不必阻塞后端存储器和带有所有冗余的应用程序进程之间的数据管道。简单的代理可以在 XML 和更精简、快捷的数据格式之间进行转换。
供应商通常有除本机存储器以外的持久性方法的投资。他们的私利不应该影响您的选择。首先注意用于您的 XML 存储器的文件系统。不要轻易地放弃其简单性和熟悉性，并且也不要不加辨别地轻信您的文件系统伸缩不够的流言。这个关于高性能 XML 系列中的后续文章将详细讲述关于文件系统持久性和 XML 高速缓存的创新方法。
用于 XML 的 RDBMS
许多由 RDBMS 支持的 XML 项目也取得了成功。这最能证明辛勤工作的成效。RDBMS 中数据存储器的表格式模型与 XML 的树状体系结构匹配得不好；两者不能自然地适应。这个夏天，Microsoft 的前任首席技术官 Nathan Myhrvold 曾经通过贬低 RDBMS，说它不适合于当前他们的许多应用程序吸引了公众的注意力。
从狭义的技术角度讲，他是对的。但是，业界对 RDBMS 的经验已经积累到很深的程度。在许多情况下，技术上的不匹配不足以和围绕 RDBMS 的基础结构的成熟性相提并论。信息技术（IT）组织知道如何进行 RDBMS 的安全性、备份、容量估计以及其它方面的工作。居于领导地位的供应商，包括 Oracle、IBM 和 Microsoft，都做出了其数据库产品将支持 XML 的承诺。
将 RDBMS 用于 XML 持久性最令人失望的方面是这个主题简直还没有编制良好的文档。有几种充分利用这种结合的聪明想法，但我还需要看到它们良好公布的消息。请关注最近几个月的
developerWorksXML 专区以获取更多关于该主题的信息（请参阅
参考资料）。
即使 RDBMS 数据建模和 XML 之间存在着明显的模式不兼容也不完全是坏事。现在正在转化成 XML 格式的大量数据
并不是树状结构的，将它们强制转化成 XML 并不是因为数据模型匹配良好，只是为了标准化。
在此类情况下，RDBMS 后端会工作得非常好。
XML 数据库
原则上，有一个显而易见的 XML 持久性解决方案：专用 XML 数据库。关于树状结构数据的学术文献数量众多，而供应商早在二十多年之前就涉足这个领域了。在定义 XML 之前，人们已经在 SGML 和更早的层次型或网络数据模型方面进行了有效的工作。
无数示例证明了惊人的性能增长 ― 转移到 XML 数据库中数据的访问速度提高了两个或更多个数量级。
但是，这幅美好的景象是有问题的。到 XML 数据库的迁移是昂贵的。
这方面的产品许可费用是相当高的，重新编码和重新培训的成本甚至更高。更糟的是，任何 XML 数据库供应商都无法给人象居于领导地位的 RDBMS 供应商那样财政可靠的印象。在一个其创造者可能会在几年之内破产的专用产品中维护您所有的数据，是否值得去冒这个风险呢？
在许多案例中 XML 数据库肯定是合适的解决方案，但这些通常是大型项目，并且涉及仔细分析。如果您负责 300,000 个项目文档，那么，您不会（也不应该）在阅读一份象本文这样的调查文章之后就决定持久性方法。您需要花钱进行专业咨询以确保您决定的正确性。
更简化的操作通常不能证实 XML 数据库的工程风险和费用。
即使是看起来可以很好地适应于该技术的案例也会因为辅助工具的不成熟而出现问题。例如，考虑大量文档实例的集合，每个都因为太大而不适合主内存。假定您必须集中在相对较小的数据子树上进行快速查询，或以各种方式转换该文档实例以用于 Web 显示示或更一般的 Web 服务。
表面上，这听起来象是 XML 数据库的理想情况。只需一次性将数据解析到数据库中，然后立即就可以通过数据库提供的查询方法进行访问。
但是，对于大型项目开发，许多部门已经合理地选择了 XSLT 或其它在主内存中使用 DOM 的 Java 编码引擎。因此，编码器再次面临了内存枯竭的问题。解决方案要依靠新一代的更“瘦”的编程工具，而不是数据管理方面任何单独改进。
请阅读
参考资料中关于 XML 数据库的优秀的调查资料。但是，除非您已经是 SGML 或 XML 专家，才有可能找到一种对您而言更安全而又具有充分性能的持久性方法。
另一种方法：e4Graph
所有其它 XML 持久性技术都归入一个十分模糊的
其它类别。在这些技术中，
嵌入式数据库通常是真正的“速度魔鬼”― 进程内的数据管理器不仅优化，而且避免了网络和海量存储器访问。这些通常也称为
内存中的数据库。它们通常依赖将整个进程包括其所有数据装入内存。
尽管这听起来象是一个极端的约束，但最近几年来机器所安装内存的激增使内存中的数据管理具有了惊人的实用性。
用于此类方式的一种特别有趣的平台是 Jacob Levy 的开放源码 e4Graph 套件。（尽管 Sun Microsystems 雇佣他做了软件工程师，但 e4Graph 属于 Levy 而不是 Sun。）
该软件名称中的“graph”是数学家的图 ― 也就是说，是一些节点或顶点的集合，以及连接它们的边。e4Graph 的成就在于提供了对图数据的常规持久性方法的高效和功能强大的访问。
树构成所有图的领域中一个重要的子集。Levy 认识到了这一点，他在自己的 e4Graph 网站上用了几页篇幅来讲述使用 e4Graph 以作为树的实例来管理 XML 数据。在他自己的实验中，他已经“成功地存储了来自 www.scripting.com 的 MathML、XUL、ChemML、RDF 和 RSS 供给，并且作为强度测试，我存储了 XML 格式的 King James Bible，然后检索了它。这一切都很轻松。”
尽管解决一般图问题的
概念力量激发了 Levy，但 e4Graph 对 XML 工作的适用性是惊人的。正如他写道：“存储器开销很低，而检索／更新很快，大约比由磁盘支持的内存空间中的存储器读写操作慢 2 至 3 倍”。此时，e4Graph 所处理的是实现用简单语法管理任意数量的数据存储的高度可靠的事务型模型。它还免费提供额外的好处 ― 将任意数据序列化成格式良好的 XML 的能力。
e4Graph 使创建在其它体系结构不可能创建的应用程序变得简单。例如，您可以部署嵌入大型 XML 数据集的程序副本。个人用户可以通过本地操作定制数据（完全事务型的），这样，无论进程是否存活以及在经过了任意紧急关闭的情况下，XML文档实例总是有效。
在诸如本地状态监控之类的情况下，这是无价的。
e4Graph 以拥有很多技术特性自豪 ― 便利函数、数据和代码可移植性，附加库以及更多特性 ― 这已经超出本调查文章的范围。e4Graph 更大的价值在于它是轻量级的、面向标准的嵌入式数据库，这些特点使实验它的费用低廉、可管理部署，并且操作复杂的持久 XML 应用程序明显加快。您可以用比 RDBMS 或 XML 数据库少得多的投资来编程许多中小型 XML 数据集。
结束语
没有一种 XML 持久性方法适合于所有规模的问题。从使用您熟悉的满足存储 XML 数据需求的技术着手。对于处理事务和存储格式化成 XML 这样的数据的策略需求，以及数据安全性和性能的特定于应用程序的设计需求，要分清两者的差异。选择与您的组织所使用的技术兼容的持久性方法。
特此感谢 Rolf Ade 和 Steve Ball 关于 XSLT 和其它 XML 编程技术的讨论。
参考资料
关于作者
对本文的评价
| 
