需求分析
隨着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應該支持如下一些功能需求：
超大數據量存儲和訪問
XMLDBMS需要存儲，查詢或者更新超大數據量的XML文檔數據。超大數據量包括三個方面：
1.文檔數量巨大，比如幾千萬個XML文檔
2.單個文檔可能非常巨大（比如幾百MB甚至若干個GB的級別）
3.單個文檔的結構可能非常複雜。
文檔結構複雜意味着以下一些奇異情況：
lXDM(6)節點樹深度很大，或者非常不平衡；
l某些元素節點含有數量巨大的屬性節點或者名字空間節點；
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，它必須能夠長期穩定運行，確保用戶應用可以持續在線運行。因此在軟件設計和實現中，要確保能夠處理各種意外情況，主要包括下面幾類異常和錯誤情形：
1.網絡錯誤或者不穩定，用戶以各種方式意外斷開連接；
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/