需求分析
随着W3C(1)制定的XML标准从上世纪90年代开始逐步推广，XML文档的应用越来越广泛。首先XML(2)文档被很多领域应用作为数据标准化的方式，也就是用来定义行业标准数据格式。这里http://en.wikipedia.org/wiki/List_of_XML_markup_languages 是一系列基于XML定义的标准数据格式，在国内的医疗，出版等很多行业也使用了XML定义的数据标准。这类应用都是使用XML文档作为符合某种标准的数据交换的载体和媒介，并且这类XML文档遵循的规范或者标准是使用Xml Schema(3)（或者DTD(4)）定义的。
同时XML文档被用作表达叙述性文档（比如电子书，用户手册等）本身的内容和外观的格式规范，比如微软Office软件的.docx,.xlsx,.pptx文档格式以及OpenOffice系统的文档格式都是基于XML来存储文档数据和格式的；还有使用标准的XML来表达网页内容的xhtml。此外很多文档处理工具也使用XML来作为其统一的数据源，比如docbook和doxygen等工具使用符合其内部定义的XML文档标准（由XML Schema 定义）的XML文档作为统一的数据源来产生和输出各种表示方法下的文档，比如使用同一个xml文档数据源产生和输出html，pdf，chm等多种最终文档格式。如上所述，XML文档标准的描述方式是XML Schema或者DTD。
还有一大类XML文档是简单随意的XML文档，它们并不遵循任何文档标准，仅仅是符合XML语言标准的，也就是仅仅是Well Formed(5)。它们存储的可以是以面向阅读的文字内容为主的文档内容，也可能是以数值类型为主的数据。
总之，XML文档被用作存储数据或者存储文档内容，它们可以遵循XML Schema/DTD定义的标准规范，也可能不遵循任何模式和标准的任意的Well Formed XML文档。并且这些文档都可能需要被更新。当然，相比于查询的访问量，更新数据这种访问所占的比重较小，文档还是以只读访问为主的，甚至有些用户愿意使用只读的数据源，如果这样可以得到更高的性能的话。在当前现实应用中，用户需要管理的XML文档数量巨大，并且大量用户会有频繁地并发读写的需求；另外有的XML文档非常巨大，单个文档可以达到若干个GB字节。这就需要XML数据库管理系统（XMLDBMS）来存储和检索以及更新XML文档，实现XML数据的高效的，高并发的，并且遵循事务ACID语义的读写访问，并且提供高可用性和高可扩展性。
用户访问文档的方式多种多样，比如通过网页来显示文档内容，通过编程的方式访问文档数据等。编程语言包括是主流的编程语言：C/C++,Java,C#,Python等，以及通过本XMLDBMS的
超大数据量存储和访问
XMLDBMS需要存储，查询或者更新超大数据量的XML文档数据。超大数据量包括三个方面：
1.文档数量巨大，比如几千万个XML文档
2.单个文档可能非常巨大（比如几百MB甚至若干个GB的级别）
3.单个文档的结构可能非常复杂。
文档结构复杂意味着以下一些奇异情况：
lXDM(6)节点树深度很大，或者非常不平衡；
l某些元素节点含有很大的文本节点；
l各种节点名字或者值可能很长；
lXML文档的任意子树符合某个XML Schema等特殊情况。
这样一个XMLDBMS实例需要存储TB级别的数据。由于存储的数据量巨大，不可以简单地整体存储一个XML文档并且在查询的时候解析这个XML文档，这样会导致大量重复的文档解析操作，导致查询和更新都非常缓慢，并且导致更新粒度过大（文档级别）。可行的办法是按照节点方式存储，当一个XML文档被存储到XMLDBMS中时，它被解析一次，解析的结果是一系列的XDM节点，这些节点以某种方式组织成数据行被存储到XMLDBMS的存储引擎子系统的数据表中。除了存储文档的节点数据，还要存储节点之间的关系，以便重新构造出原来的文档而不丢失文档的结构信息。
在逻辑数据视图层面，由于XML文档数量巨大，应该让用户按照业务需求将文档和其他数据归类/分组存放，所以像RDBMS一样需要“数据库”这个概念，一个“数据库”是用户应用中的一组数据的集合，其中包括XML文档，XML Schema,XQuery Module，用户，角色，权限等等，一个数据库是用户数据的边界，两个数据库不共享任何用户数据。在一个数据库内部，让用户进一步根据文档的结构或者用途的不同，或者按照其他针对用户应用的分类规则，进一步将文档分为若干组来存储和访问，每组叫做一个文档容器。一个文档容器存储着若干个XML文档的所有节点数据，它基于存储子系统的数据表来存储这些节点数据以及附带的元数据信息，文档结构信息，节点间关系还有节点值索引等等。这些信息被分类存储在多个数据表中；同时为了灵活地完成访问控制和用户对文档的访问规则，需要一种机制让用户可以灵活地把大量文档归类和分组，这种分组与存储层面的物理分组（即文档容器）不同。
在存储层面，由于数据量很大，所以需要多个IO设备连接到同一个服务器上面，这样可以让这些IO设备并发工作，增大XMLDBMS的数据吞吐量。因此类似RDBMS，我们使用表空间的概念，每个表空间使用文件系统路径来对应于一个IO设备；XML文档容器可以被创建在XMLDBMS系统所拥有的任何一个表空间中，这样就达到了并发IO的目的。
在实现层面，巨大的数据量意味着进行节点数据的排序，连接或者检索都不可以进行纯内存操作，因为系统可用内存甚至可能无法容纳得下一个文档。而是应该使用临时表，外部排序等手段确保可伸缩性。复杂的文档结构意味着节点数据要尽可能简单而灵活地存储，避免存储重复数据，避免奇异的大数据节点影响系统性能。
高并发的读写访问
对XML文档数据的读取方式是由XQuery(7)/XPath(8)/XQueryFulltext(9)等语言标准定义的，主要包括路径导航，FLOWR，全文检索等方式；写操作是由XQuery Update(10)定义的，主要包括插入子节点，删除子节点等，替代子节点，重命名，节点变换等.这里的子节点可以是一个子树。节点存储方案需要允许高效地不限次数的任意更新XML文档的任意部分，并且更新尽可能小地损害查询性能和并发度；由于文档可能会很大，所以并发控制的粒度要达到节点级别，以便多个事务可以对同一个XML文档的不同节点并发的做节点数据的增删改查操作。
高并发带来的另一个挑战是针对服务器架构的。在早年的RDBMS中，比如Postgresql，服务器为每一个用户连接启动一个后台进程，该进程持续服务该用户直到用户断开连接。如果同时有1000个用户连接着服务器，那么就要启动1000个后台进程，这对于服务器硬件资源是非常大的挑战。在这种情况下系统响应速度和吞吐量都将显著降低，甚至到后来会由于操作系统资源限制而禁止用户连接。这样做造成了巨大的资源浪费，每一个后台进程都没有满负荷工作，因为它只服务于一个用户。并且过多的进程导致进程频繁切换，操作系统做大量的进程切换导致的开销非常巨大。
在C/S架构年代，这样的服务器架构可扩展性很低，到了近10年发展起来的B/S架构中，这个问题得到了缓解，因为连接DBMS的是应用服务器，而后者通常使用一个连接池，保持若干个（比如10个）连接，复用这些连接即可。
在我们的XMLDBMS中，为了彻底解决这个问题，需要更先进的服务器架构，通过使用线程池和任务队列的架构，后台线程并不会被绑定给任何用户连接，而是随机处理某个连接发送过来的请求（该请求是事务中的一个DDL/DML命令），这样每个后台线程可以最大程度的得到重用，服务器可以同时接受和处理的连接数量将大大提升。
事务语义
与RDBMS一样，XMLDBMS也需要事务ACID语义。并且事务要尽可能地并发执行，尽可能避免并发执行的瓶颈，这对于大数据量大访问量的XMLDBSM来说是非常重要的。同时由于XMLDBMS更加倾向于是一个文档数据库，其访问大多以只读访问为主，所以实现事务语义的时候需要考虑为这种访问模式做优化，同时还要支持XQuery Update定义的XML数据更新方式。
本系统是一个具有良好的模块化的XMLDBMS，对事务语义的支持与XML/XQuery/XPath本身没有任何关系，因为事务在存储引擎子系统中实现，而存储引擎并不知道上层查询引擎子系统数据模型。事实上本系统可以通过增加一个关系数据库查询引擎模块来扩展支持关系数据模型和sql查询，以及sql与XQuery的混合查询。
数据安全
数据安全的目的是确保用户数据不被损坏，丢失，未授权访问，非法窃取，人为故意违规损坏等，具体来说主要涉及以下一些方面：
1.确保用户数据不会因为存储介质被破坏，或者应用程序执行错误，或者断电和计算机硬件故障等因素而损坏；这就是数据的备份和恢复功能。备份的方式是定期（比如每一个月）做一次完全备份，然后持续地（比如每天）做增量备份。在恢复的时候，使用完全备份和增量备份数据完成数据恢复，恢复到上一次做增量备份的时间点。
2.确保用户数据不会通过本系统公开接口被未授权者非法地读取或者更新/删除；这就是访问控制功能。每个用户只能访问授权给他访问的数据，执行授权的操作；不能访问未授权给他访问的数据或者执行未授权的操作。根据应用需求，DBA可以为一个数据库创建多个用户帐号，然后让不同的终端用户使用不同的帐号来登录XMLDBMS，系统根据DBA配置的访问控制规则检查每一次访问是否授权，并拒绝未授权访问。
3.确保数据不会在传输给用户的途中被窃取。为了达到最大程度的可用性和可移植性，本系统使用TCP/IP协议在客户端和服务器之间传输数据和结果。而TCP/IP协议的用户数据包是不加密的。因此需要支持SSL，让用户可选地使用ssl来连接XMLDBMS，并且XMLDBMS可以同时接受来自SSL和普通TCP/IP的连接。虽然对于大多数用户来说这并不是必须的，因为大多数情况下用户的XMLDBMS服务器通常和应用服务器都位于同一个机房中，甚至对于小规模应用来说就是同一台服务器硬件，但是有了SSL选项后，少数特殊用户也有了安全选择，比如用户的数据库服务器位于公司内部，而应用服务器托管在第三方。
4.对于关键数据和关键应用场景（比如国防，军事等涉密单位），确保每次用户对数据的读写访问都记录在案，这就需要审计功能。它记录每一个用户帐号在何时对哪个数据单位（精确到节点级别，即数据库->容器->文档->节点）做了哪种访问（查询，更新，删除，插入）。该功能可以根据用户需要来配置启用或者禁用，因为它对性能有一定影响并且很多用户并不需要这么高的安全级别；
5.对于关键数据和关键应用场景（同上），确保本XMLDBMS的底层数据文件被非法获得后，用户数据不会被非法地获取到，这就需要数据加密功能。用户为容器设置密码，然后所有放入这个容器的文档节点数据都被使用改密码加密，返回给用户时数据会被解密。该功能可以根据用户需要来配置启用或者禁用，因为它对性能有一定影响并且很多用户并不需要这么高的安全级别；
上述几个方面在RDBMS的需求中也同样存在并且在存储引擎层面是无区别的，可以统一处理。
高可用性和高可扩展性
容错与健壮性
作为一个DBMS，它必须能够长期稳定运行，确保用户应用可以持续在线运行。因此在软件设计和实现中，要确保能够处理各种意外情况，主要包括下面几类异常和错误情形：
2.用户输入的数据错误或者异常，比如用户数据（XML文档）格式错误或者不在有效范围内；错误的查询语句，引用不存在的对象或者数据等。
3.各种数据超长等，比如各种名称（容器名，文档名，节点名，变量名，函数名，用户名，角色名等等）超长，以及各种数据单元超长，比如文档或者文档中的文本/属性节点数据超长；对于各种名称超长，我们可以定义一个允许的最长名称字节数，超过该长度后认为非法，系统拒绝接受和处理；而对于数据超长，却并不是用户的错误，我们的系统需要支持任意的长度，直到超越了理论值（比如单个文本节点最长可以达到2^32，再长就无法支持了，这些理论值也应该告知用户）
4.超长事务，超时的事务或者连接；
超长的事务是合法的事务，必须允许用户能够完成该事务。这样，就需要确保它不会过多地占用资源（比如事务锁，内存等）导致其他事务不能进行下去，而降低了系统整体的事务吞吐量。对于超时的连接和事务，需要识别出这种情形，并且在确认后释放它们占用的资源，以及做其他相应处理（比如回滚事务等）。
5.内存或其他资源用尽
这是服务器系统长期运行面临的最大挑战之一。除了内存外，一个进程需要的其他资源也都是有限制的，比如打开的文件数目，打开的各种内核对象数目等。这需要保持高内存使用效率，杜绝内存/其他资源泄漏。对于大数据量的排序，连接等消耗大量内存的操作，需要使用外部排序，临时表等措施，不可以假设所有操作可以在内存内完成。
复制与高可用性
高可用性是指系统能够克服局部断电或者网络以及计算机硬件故障，持续在线运行的技术指标。实现方法就是使用多个机器节点组成一个集群（cluster），这个集群中所有节点存储着相同的数据，每一个节点都可以响应数据读取请求，但是通常只有一个节点可以处理数据更新（否则会出现数据版本冲突问题），这个节点是master节点，其他节点是replica节点。数据在master节点更新后，事务日志被传输到replca上面，每个replica各自replay事务日志，仿佛系统因为故障重启做的recovery一样，即可将数据更新在本节点上面重现。当任何一个replica节点下线后，系统仍然可以处理读写请求；当master节点下线后，replica节点根据选举机制选出新的master节点。选举的原则首先是具有最新的更新的节点胜出，若有多个胜出者那么选择优先级最高者，这个优先级通常是DBA根据硬件性能设置的。复制结合master选举是高可用性的常见实现方法。
在机房硬件部署中，一个复制组的所有节点最好处于不同的机架（rack），因为每个机架有一套电源线路和网络线路，一个机架掉电或者网络掉线只会导致一个节点down，最大程度地保证了可用性。一个机架的多个机位可以放置处于多个复制组的节点。
使用replication可以带来只读访问的较高的可扩展性，通过增加replica节点，就可以提供更大的只读数据处理能力。但是对于数据更新仍然无能为力，只有一个master节点可以处理更新。解决方案就是使用数据分片（partitioning），这在下节讲述。
高可扩展性
通过数据分片（partitioning），可以将一个关系表中的数据行（对于RDBMS）或者一个文档容器中的XML文档（对于XMLDBMS）分散存放到多个复制组中，以便分散数据更新/插入/删除压力。分散的规则通常包括按照主键/其他唯一索引键值进行散列，或者轮转的（round robin）或者复制的（即每行数据/每个文档都存放在每个复制组中，对高频访问的表/容器可以这样做）或者用户自定义的映射方法进行。这样相当于把数据更新压力分散到了多个节点上面，是replication的有效的补充。不过数据分散后需要处理的难题是如何执行查询，因为一个表的数据行分散存储在多组节点中，每个节点上有一部分，当查询条件涉及的列不是分散用的列时，需要从每个节点上取出符合查询条件的行。而对于多表连接，需要考虑这些符合条件的行数量非常巨大，但是连接涉及的多个表的符合条件的数据量可能相近也可能相差很大，那么后续的连接操作如何执行，在哪里执行，都是查询优化需要考虑解决的问题。这些技术就是分布式数据库的基本技术。有了分布式数据库架构后，系统就可以达到更大的可扩展性，可以存储和检索PB级别的数据量，达到大型数据库的处理能力。
开放的平台和标准
首先完全遵循W3C的相关标准，包括XML,XQuery/XPath,XQuery Fulltext,XQuery Update,XML Schema,DTD等，不做私有扩展，以便用户软件的可移植性；为了达到最大的用户群，考虑到目前应用软件开发和运行的平台和方式，我们需要支持主流的Unix/Linux平台和Windows平台，服务器版本不支持嵌入式平台；客户端API需要支持C/C++/Java/C#等多种编程语言，以及python/perl/PHP等主要的脚本编程语言，达到最大程度的可访问性。
尽可能使用开放标准和协议，比如网络传输使用TCP/IP或者SSL，接受主要的文字编码格式（比如GB2312/GBK，多种主要欧亚国家字符集，UTF8，UTF16等）并且转换为统一的UTF8编码的文本字符串在内部存储和处理等；在开发技术层面，使用C++语言开发，并且尽可能使用成熟可靠的开源技术和工具达到复用软件降低开发成本的效果。
国际化与本地化
在XMLDBMS系统软件设计和实现中，需要支持方便的国际化，以便系统可以输出任意语言的提示信息和界面。
Xquery/xpath和XML都是支持任意国际字符的，所以在内核中要支持unicode字符集的XML文档和xquery查询，并且使用unicode字符集存储数据。
除了字符以为，对于国际化的其他要素，比如日期，时间，货币等等也需要很好地支持，以便方便地做本地化。
用户友好性
需要提供详尽而准确的文档，丰富而实用的示例程序代码，完整准确的帮助信息和运行时提示信息等。并且提供方便易用的周边工具，比如备份，升级，转换工具等。
总结
从上面的需求分析中可以看出，XMLDBMS在需求层面以及实现技术层面有很大一部分与传统的RDBMS重合，不同之处主要是查询引擎子系统。XMLDBMS的查询引擎子系统需要基于xquery数据模型（XDM）来存储XML文档数据并且实现xquery系列DML，包括xquery， xquery fulltext,xquery update；并且根据系统在其他方面的需求，合理地设计查询引擎的节点数据存储方案和相应的查询实现方案。
另外W3C没有标准化XQuery的DDL，因此我们需要根据实现方式定义自己的DDL，以便完成对各类内部元数据的管理。从可移植性角度考虑，没有标准的DDL会损害用户程序代码的可移植性，但是这种缺失却也增加了XQuery实现的灵活性，从而扩大了xquery的使用范围，比如有些xquery实现甚至没有任何XMLDBMS中的元数据对象的概念，仅仅实现XML数据查询。
附注
1.W3C 官方网站：http://www.w3.org/
2.XML标准：http://www.w3.org/TR/xml11/
3.XML Schema:http://www.w3.org/TR/xmlschema-0/
4.DTD: http://www.w3school.com.cn/dtd/index.asp
5.Well Formed：http://www.w3.org/TR/xml11/#sec-well-formed
6.XDM：XQuery DataModel www.w3.org/TR/xpath-datamodel/
7.XQuery：http://www.w3.org/TR/xquery/
8.XPath:http://www.w3.org/TR/xpath20/
9.XQuery Fulltext: http://www.w3.org/TR/xpath-full-text-10/
10.XQuery Update :http://www.w3.org/TR/xquery-update-10/
