數據擴展

自適應調製(AM)技術是充分利用信道容量的有效技術之一,其主要目的是通過自適應地調整調製星座、編碼、發送功率等發射機參數來使系統的吞吐量或者平均頻譜效率(ASE)達到最大.OFDM是20世紀70年代後逐漸發展起來的一種高效的調製技術,可以獲得很高的頻譜效率,實現高速數據傳輸.在能夠正確估計信道動態特性的情況下,OFDM發射機通過採用自適應比特分配算法能夠根據信道條件來調整發射信號,以逼近頻率選擇性信道的理想容量.已有許多OFDM系統中的自適應子載波比特分配算法,這些算法根據信道狀態信息自適應地調整每個子載波的發射功率和調製階數等參數,但需要反饋大量的調製參數信息,致使傳輸性能下降.為了減少傳輸信息,同時降低算法複雜度,提出了採用數據擴展技術的OFDM自適應調製模型,給出了在調製階數相同的前提下系統的最大容量.然而這種自適應調製方式不是以用户需要為目標來優化系統的,因而靈活性較差,且不能保證用户或網絡上層對傳輸質量和傳輸速率的要求.文中以該模型為基礎,分析了採用數據擴展技術的自適應調製OFDM系統的特徵,並在此基礎上提出了以用户需求為目標的最小化總功率的自適應調製算法,不僅降低了算法複雜度,還大大減少了有關調製參數信息的傳輸.

為了使OFDM系統能夠更好地支持不斷變化、不斷豐富的業務類型,儘可能滿足這些無線業務對傳輸鏈路提出的不同服務質量(QoS)需求,特別是目標誤比特率和目標傳輸速率的要求,文中以數據擴展技術為基礎,提出了一種基於用户需求的採用最小化發射功率(MTP)準則的自適應調製技術.假設用户的目標傳輸速率為每個OFDM符號Btgt , BERtgt, d目標誤比特率為比特原始數據符號k的功率Pk=P,調製階數Ck=C,則功率最小化問題M、 P、即為如何設置原始數據符號的數目功率調製階數C才能使得系統的總功率Ptot=MP最小轉換成一個無約束的最優化問題,使Ptot值最小的P即為所求的數據符號的最佳功率,最佳的調製階數和數據符號數目分別由C=log2(1+JP)和M=Btgt/C獲得.值得注意的是,該優化結果中C和M均為實數,要使得結果具有實際意義,還需要將其離散化.離散化的核心思想是總的傳輸速率按照剛好滿足要求來設置,儘可能減少功率消耗;另外由於所有數據符號的性能一致,可將比特在數據符號之間按順序分配.離散化的步驟如下:

(1)如果「Btgt/C≤N,則離散化後M=「Btgt/C,否則M=Btgt/C」;離散化後的調製階數Ck=C=log2(1+JP)」,k=1,2,…,M.

(2)置初值k=0,經步驟(1)離散化之後,未分配完的比特數bits-remain=Btgt-MC.

(3)如果bits-remain≤0,執行步驟(4);否則,因為各個原始數據符號的性能一致,可以按順序將剩餘比特進行分配,k=k+1,Ck=Ck+1,bits-remain=bits-remain-1,返回步驟(3).

(4)計算每個原始數據符號的功率Pk=(2-1)ln(5BERtgt)_{,如果k≠0,則記錄M=k,表}示採用高一級調製階數的原始數據符號的數目.

由此可以看出,調製階數Ck(k=1,2,…,M)只有兩種取值,且二者固定相差一個比特,因此功率Pk也只有兩種取值.這樣不僅實現起來簡單,而且需要傳輸的有關調製參數的信息僅為M、M1、調製階數C1以及兩種功率取值.

對文中所提的算法進行仿真,並與傳統OFDM系統中採用注水定理的理論最小功率、貪婪比特加載算法的功率、僅採用自適應功率控制的最小功率進行了比較.仿真條件如下:N=256,符號速率為2MB/s,信道採用IEEEStd802.16SUI-5信道模型,多徑時延分別為0、4、10μs,相應功率強度分別為0、-5、-10dB,等效頻域的歸一化復加性高斯白噪聲平均功率為1.BERtgt=10,Btgt取不同值時所消耗的功率(用子載波的平均信噪比表示)。傳統OFDM系統中的注水定理和貪婪比特加載算法的性能優於文中算法,這是因為這兩種算法中每個子載波的功率和調製階數均單獨調整,但是它們複雜度高,且需要傳輸大量的調製參數信息.文中算法的性能明顯優於採用功率控制等調製階數的傳統OFDM系統,而二者的複雜度相當.將文中算法和功率控制算法比較發現,在相同情況下,文中算法可將發射功率減少近2dB.因此,文中算法既簡單,又大大減少了調製參數信息的傳輸,具有實際應用價值.

文中分析了採用數據擴展技術的自適應調製OFDM系統在全自由度條件下的特徵,指出了平均分配就是最優分配,並且以用户需求為目標提出了最小化總功率的自適應調製算法,降低了算法複雜度,減少了有關調製參數信息的傳輸.但是文中是以理想信道估計作為討論前提的,沒有討論算法對抗信道估計誤差的性能.而對於實際的傳輸系統而言,信道估計誤差是不可避免的,因此要想使算法具有實用性,還應進一步研究對抗信道估計誤差的方法,提高算法的魯棒性. ^[1] 

設論域U表示數據庫中所有數據,即對象.A表示數據的屬性集合,OU稱為對象集,R與是O和A之間的二元關係,即RO×A,稱三元組(O,A,R)是一個形式背景(formalcontext),oRa表示o∈O與a∈A之間存在關係R.設PO,QA,定義運算P*={a∈AoRa,o∈P},Q*={o∈OoRa,a∈Q},此處,P表示P對象具有的所有屬性的集合,Q表示具有屬性Q的O中所有對象的集合.於是有以下定義:

定義1二元組(P,Q)(PO,QA)稱為形式背景(O,A,R)中的形式概念(formalconcept)(簡稱概念).其中P=Q,Q=P.P和Q分別稱為概念的外延和內涵.對於形式背景(O,A,R)中任意兩個概念(P1,Q1)和(P2,Q2)定義以下偏序關係:(P1,Q1)≤(P2,Q2)P1≤P2(或等價的Q2≤Q1),則形式背景(O,A,R)中的所有概念連同其上定義的偏序關係稱為概念格,記為L(O,A,R).且有上下確界:(P1,Q1)∨(P2,Q2)=((P1∪Q2),P1∩Q2),(P1,Q1)∧(P2,Q2)=((P1∩P2),(Q1∪Q2)).易見L(O,A,R)是一個完備格.總存在(x′,y′)∈L(O2,A,R2),使得y=y′,則稱L(O2,A,R2)覆蓋L(O1,A,R1),記作L(O2,A,R2)≥L(O1,A,R1).若L(O2,A,R2)≥L(O1,A,R1)且L(O1,A,R1)≥L(O2,A,R2),則稱兩個概念格同構,記作L(O1,A,R1)L(O2,A,R2).

例1給定形式背景(O,A,R),其中O={1,2,3,4,5,6,7,8},A={a,b,c,d,e,f,g,h},其二元關係見表1:

表1二元關係表

該形式背景有6 概念:(23 cdh),(123 ach),(4578 bef ),(45678 beg),(O ),( A.設數據基本集G1 {4 },則形式背景(G1 G1 的相容集有 {4 5},{4 },{4 5 },其中{4,5,7,8}是(G1,A,RG1)的一個數據擴展.關於數據擴展,有如下結論:

定理：設形式背景(O R), G O 則對於任何形式背景(G RG , 展必定存在若對於u∈O-G,都有L(G+{u},A,RG+{u})≠L(G,A,RG),則G本身就是擴展,若存在u∈O-G,使得L(G+{u},A,RG+{u})L(G,A,RG),則考慮G1=G+{u},若對於u1∈O-G1,都有L(G1+{u1},A,RG1+{u1})≠L(G1,A,RG1),則G1是擴展,否則,考慮G2=G1+{u1},重複上述過程,由於O-G是有限集,這樣總可以找到一個擴展.給出相容集的判定定理. ^[2] 

隨着Internet技術的迅猛發展，將軟件作為一種新的服務形式提供給客户的需求量逐年增加，而SAAS(SoftwareasaService，軟件即服務)作為一種新型軟件服務形式的出現正是順應了這個需求。它是一種顛覆傳統的軟件服務形式，將使軟件供應商與客户之間的關係發生徹底轉變，從簡單的售賣關係轉變為服務關係。SAAS服務面向互聯網上的所有租户，每個租户根據自身的實際情況，所要求的數據結構各不相同，SAAS軟件開發商們在搭建基於共享模型的SAAS架構 時就不得不考慮各租户之間數據結構的差異性問題。針對各租户所要求的數據結構的不同，在進行系統數據庫設計時就要對各租户不同的數據結構實施相應的數據擴展策略。

在設計基於SAAS模式 的系統數據模型出於降低開發成本和接受服務的客户量等考慮，在數據的隔離、共享之間取得一定的平衡是一個必須考慮的重要因素。就一般而言，SAAS系統的數據模型有如下三種形式:

(1)獨立數據庫。

將每個客户的數據單獨存放在一個獨立數據庫中，使各客户間的數據完全隔離，最大限度地保證了客户數據的安全。

(2)共享數據庫、單獨模式。所有客户共享數據庫，但各自有一套獨有的數據表來存放各個客户的數據。這在各客户數據的隔離和共享之間取得了一定的平衡。

(3)共享數據庫、共享模式。所有客户共享一個數據庫和同一套數據表。該模式下的一個數據表裏可以包含多個客户的數據，由客户ID來區分數據歸屬於哪個客户。該模型具有投入成本低等特點，而且每台數據庫服務器可以支持最大的客户量;但是由於所有客户的數據存放在同一個數據表中，因此可能需要花費更多額外的成本來保證客户之間的數據安全 。

在這種模式下，所有的客户共享數據庫、共享表結構，所有客户的數據存放在同一個數據表中，通過客户ID來區分不同客户的數據。該模式的數據庫服務器硬件和數據備份成本最低，它允許每個數據庫服務器所支持的客户量達到最多。但是由於所有客户共同使用一個表，在可擴展性、可配置性上產生了瓶頸。為了解決這個問題，通常有以下三種辦法。2．1定製列即使用固定擴展集指在表中除了各租户共有的一些字段外，還包括各租户各自獨有的一些字段。如:可設計Table(TenantID，FixedCol1，ExtendColu1，ExtendColu2…ExtendColun)，其中Tenan-tID，FixedCol1是固定字段;ExtendColu1，ExtendColu2…ExtendColun是擴展字段。這種方法不需要處理複雜的數據擴展跟蹤，但隨着租户的增加，每個租户要求添加的列就很多，但特定租户擴展的數據列對於其他租户是沒有任何意義的，嚴重地破壞了表的結構，並且提供的擴展有限，有時擴展字段中的字段可能為空，給表空間帶來了巨大浪費。

預分配字段

該方法在表格中提供一定預設數量的預設字段，當客户需要擴展數據時，從表中選取適量的預設字段來擴展數據，但每個客户選取的預設字段的含義可能不同。如表1中F1、F2、F3就是預分配的字段。TenantID字段將每條記錄與租户相關聯。除了一組標準字段外，還提供一些預設字段，預設字段的使用由租户決定，預設字段的數據類型可以不同，一般採用字符串數據類型，並使用元數據來跟蹤其真實數據類型，如表2所示。

該方案雖然滿足客户數據的可擴展、可配置性，但在給定的數據表中，預設字段的數量具有不確定性，有的客户需求多，有的客户需求少。如果預設字段的數量設得過大，就會浪費空間;設得過小，又不滿足所有客户的需求。

名稱值對

名稱值對將所有用户異構的數據(擴展的數據)放在一個擴展表中，並在主數據表中有一個字段與擴展表相關聯，並且用元數據表中的元數據來跟蹤相應擴展字段的標記和數據類型。該方法使客户自己能夠對數據模型進行延伸。元數據表存儲各個客户定製字段的信息，包括字段名稱和數據類型。該方法能最大限度地滿足所有客户的無限擴展需求，客户能夠自行決定數據的可擴展、可配置性，又保持了在該數據模型下的成本優勢。雖然這種結構可以方便地擴展無數個字段，但增加諸如索引、查詢以及更新記錄等數據庫功能的複雜程度。

展方案在共享模型的SAAS系統中，所有客户共享表結構，但租户間的數據結構是不同的，將異構的數據存入到固定的表，需要對異構的部分數據進行處理。而XML數據中數據結構是不盡相同的、是異構的但可以通過XML技術靈活地管理XML數據中的節點。因此，可利用XML數據的特性並採用相應的技術來處理各租户間異構的數據。

該方案是指在表中採用一種基於XML的數據模型字段來處理各客户間異構的數據。主流大型關係數據庫系統都支持對XML數據的存儲和管理。Or-acle從9．2開始就支持一種新的數據類型(XML-Type)，用於存儲和管理XML數據，並提供了很多的函數，用來直接讀取XML文檔和管理節點。

下面以Oracle數據庫系統為例。表結構如:Ta-bleName(TenantID，Colu1，Colu2，Colu3，XMLDat-aField)，其中TenantID，Colu1，Colu2，Colu3字段是所有客户共用的字段;XMLDataField字段存儲各客户獨有的數據，其格式遵循XML的格式要求。設計XML-DataField字段格式為:

value1

value2

……

valueN

在上面XMLData字段格式中，每個節點代表一個擴展列，該擴展列可以有多種屬性，如:colName、data-Type等，以及該擴展列的值。通過這種方法可以實現靈活的數據查詢、更新等操作，滿足客户數據的無限擴展需求。

1)利用關係數據系統(ORACLE)支持對XML數據的存儲和管理，實現對XML類型數據的增加、刪除、查找、修改功能。建立一個含XMLType類型字段(XMLData)的數據表User，下面詳細介紹對該字段及字段裏面的節點數據進行增加、刪除、查找、修改操作。

(1)向XMLData字段插入數據。

InsertintoUser(XMLData)value(sys．xmlType．createXML

(‘

20

true

UserExtendCol>

UserExtendColS>’));

注:用createXML函數往XMLData字段裏插入XMLType類型數據。

(2)向XMLData字段裏面的數據節點裏加入節點。

UpdateUsersetXMLData=insertChildXML(XMLData，‘/UserExtendColS/UserExtendCol’，XMLType(‘2001－01－05UserEx-tendCol>’));

注:XMLType提供了insertChildXML函數在XML數據節點最後追加一個節點，還提供了insertChildXM-LBefore，appendChildXML兩個函數分別表示在某個節點前追加節點以及在節點末尾追加多個節點。

(3)查詢XMLData字段裏面的內容。

Selectu．XMLData．Extract(‘/UserExtendColS/UserExtendCol[@colName=“age”]/text()')．getStringVal()asagefromUseru;注:Extract函數返回一個XML文檔的一個節點樹，或者某一節點下所有符合條件的節點。

(4)更新XMLData字段裏面的數據。

UpdateUsersetXMLData=updateXML(XMLData，‘/UserExtendColS/UserExtendCol[@colName=“age”]/text()’，“20”)

WhereexistsNode(XMLData，“/UserExtendColS/UserExtendCol[@colName=”age“]”)=1;

注:使用updateXML函數來更新XMLData字段裏面某個節點的數據;existsNode()函數來判斷是否存在擴展列名為age的列，該函數的返回值只有1(存在)和0(不存在)。

(5)刪除XMLData字段裏面的數據節點。

UpdateUsersetXMLData=deleteXML(XMLData，’/UserExtendColS/UserExtendCol[@colName=“age”]/’)Whereexists-Node(XMLData，’/UserExtendColS/UserExtendCol[@colName=“age”]’)=1;

注:使用deleteXML函數來刪除XMLData字段裏面某個節點。

2)性能分析。

在基於XML的共享模型的多租户數據擴展方案中，利用XML來處理多租户各用户之間異構的數據，對整個SAAS應用的體系架構和性能將產生很大的影響。

(1)在基於共享數據模型的SAAS模式下，其必須具備處理多租户異構數據的能力，滿足多租户數據無限擴展的要求。在此模式下，用户量非常高，業務數據為海量級併發壓力也非常高。因此在如此海量數據和高併發壓力的情況下，性能將會是做數據檢索、統計計算的瓶頸。在上面提到的各種共享模型擴展方法中，定製列、預分配字段不滿足多租户無限擴展的需求，而名稱值對雖然能滿足多租户無限擴展的要求，但是在進行數據檢索時，至少進行三表(數據表、擴展表、元數據表)的連接操作，在海量級的數據檢索時，性能的低下很難滿足用户的需求。而基於XML共享模型的多租户數據擴展方案，在數據檢索時不必進行連接多表操作，其數據檢索跟普通的WEB應用的數據檢索差不多，只是必須對檢索得到的數據進行相應的處理後呈現給用户;並且該方案可以滿足多租户無限擴展的要求，以最大限度地利用表空間。

基於XML的共享模型的多租户數據擴展方案與定製列、預分配字段、名稱值對從可擴展性、性能、靈活性等方面進行對比分析，如表3所示。

(2)在軟件設計模式中，MVC模式(Model－View－Controller)作為經典的設計模式，將模型、視圖、控制器相互獨立分開，模型層主要負責業務邏輯的處理和完成與數據庫的交互;視圖層主要負責與用户的交互;控制器的作用是從客户端接受請求，並選擇執行相應的業務邏輯，把響應結果送回到客户端，它與模型層和視圖層整合在一起完成用户的請求。

對於普通的WEB應用，MVC模式完全可以作為搭建其系統的設計模式，不必考慮軟件使用者之間的衝突，只需關心自身的功能邏輯。而SAAS系統，是由不同用户共享一個軟件系統，就必須需要考慮軟件不同使用者之間的衝突，系統就必須需要完成對不同用户異構數據的處理。

基於XML的共享模型的多租户數據擴展方案，只需在MVC模式中加入一個對XML數據的處理層，完成對XML數據的拆、封處理。其作用是在模型層完成對業務邏輯的處理後，將相應的異構數據轉換成XML數據以便完成與數據庫的交互;在模型層完成與數據庫的交互後，將數據庫中XML數據轉換成相應的業務數據以便進行相應的業務邏輯處理。引入XML數據處理層後的四層模型。(3)大型關係數據庫系統基本都具有XML文檔的導入、導出功能。用基於XML共享模型的多租

户數據擴展方案，可以將異構的數據(XML數據)導出到本地磁盤，也可以將本地磁盤的XML文檔導入到相應數據庫表的XML數據列，增強了系統數據維護人員對異構數據的維護。 ^[3]