數據擴展相關算法
概述
自適應調製(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)示採用高一級調製階數的原始數據符號的數目.
由此可以看出,調製階數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取不同值時所消耗的功率(用子載波的平均信噪比表示).從圖2中可以看出,傳統OFDM系統中的注水定理和貪婪比特載入算法的性能優於文中算法,這是因為這兩種算法中每個子載波的功率和調製階數均單獨調整,但是它們複雜度高,且需要傳輸大量的調製參數信息.文中算法的性能明顯優於採用功率控制等調製階數的傳統OFDM系統,而二者的複雜度相當.將文中算法和功率控制算法比較發現,在相同情況下,文中算法可將發射功率減少近2dB.因此,文中算法既簡單,又大大減少了調製參數信息的傳輸,具有實際套用價值.
結語
文中分析了採用數據擴展技術的自適應調製OFDM系統在全自由度條件下的特徵,指出了平均分配就是最優分配,並且以用戶需求為目標提出了最小化總功率的自適應調製算法,降低了算法複雜度,減少了有關調製參數信息的傳輸.但是文中是以理想信道估計作為討論前提的,沒有討論算法對抗信道估計誤差的性能.而對於實際的傳輸系統而言,信道估計誤差是不可避免的,因此要想使算法具有實用性,還應進一步研究對抗信道估計誤差的方法,提高算法的魯棒性.
數據擴展相容性問題
概述
設論域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二元關係表
| a | b | c | d | e | f | g | h | |
| 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 |
| 2 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 |
| 3 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 |
| 4 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
| 5 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
| 6 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 |
| 7 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
| 8 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
該形式背景有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是有限集,這樣總可以找到一個擴展.現在給出相容集的判定定理.
數據擴展技術
概述
隨著Internet技術的迅猛發展，將軟體作為一種新的服務形式提供給客戶的需求量逐年增加，而SAAS(SoftwareasaService，軟體即服務)作為一種新型軟體服務形式的出現正是順應了這個需求。它是一種顛覆傳統的軟體服務形式，將使軟體供應商與客戶之間的關係發生徹底轉變，從簡單的售賣關係轉變為服務關係。SAAS服務面向網際網路上的所有租戶，每個租戶根據自身的實際情況，所要求的數據結構各不相同，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所示。
| 表1 預分配欄位 | ||||||
| TenantID | Name | BirthDate | F1 | F2 | F3 | |
| 784 | 李四 | 1980－05－15 | 123 | Null | null | |
| 表2 元數據跟蹤表 | |||||||
| TableID | F1_Label | F1_DataType | |||||
| 001 | “金額” | Int | |||||
該方案雖然滿足客戶數據的可擴展、可配置性，但在給定的數據表中，預設欄位的數量具有不確定性，有的客戶需求多，有的客戶需求少。如果預設欄位的數量設得過大，就會浪費空間;設得過小，又不滿足所有客戶的需求。
名稱值對
名稱值對將所有用戶異構的數據(擴展的數據)放在一個擴展表中，並在主數據表中有一個欄位與擴展表相關聯，並且用元數據表中的元數據來跟蹤相應擴展欄位的標記和數據類型。該方法使客戶自己能夠對數據模型進行延伸。元數據表存儲各個客戶定製欄位的信息，包括欄位名稱和數據類型。該方法能最大限度地滿足所有客戶的無限擴展需求，客戶能夠自行決定數據的可擴展、可配置性，又保持了在該數據模型下的成本優勢。雖然這種結構可以方便地擴展無數個欄位，但增加諸如索引、查詢以及更新記錄等資料庫功能的複雜程度。
基於XML的共享模型的多租戶數據擴
展方案在共享模型的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所示。
| 表3 各方案比較表 | ||||
| 比較項 | 定製列 | 預分配欄位 | 名稱值對 | XML存/取 |
| 可擴展性 | 低 | 中 | 高 | 高 |
| 性能 | 高 | 中 | 低 | 高 |
| 靈活性 | 低 | 中 | 高 | 高 |
| 實現複雜度 | 低 | 中 | 高 | 低 |
| 空間利用率 | 低 | 中 | 高 | 高 |
(2)在軟體設計模式中，MVC模式(Model－View－Controller)作為經典的設計模式，將模型、視圖、控制器相互獨立分開，模型層主要負責業務邏輯的處理和完成與資料庫的互動;視圖層主要負責與用戶的互動;控制器的作用是從客戶端接受請求，並選擇執行相應的業務邏輯，把回響結果送回到客戶端，它與模型層和視圖層整合在一起完成用戶的請求。
對於普通的WEB套用，MVC模式完全可以作為搭建其系統的設計模式，不必考慮軟體使用者之間的衝突，只需關心自身的功能邏輯。而SAAS系統，是由不同用戶共享一個軟體系統，就必須需要考慮軟體不同使用者之間的衝突，系統就必須需要完成對不同用戶異構數據的處理。
基於XML的共享模型的多租戶數據擴展方案，只需在MVC模式中加入一個對XML數據的處理層，完成對XML數據的拆、封處理。其作用是在模型層完成對業務邏輯的處理後，將相應的異構數據轉換成XML數據以便完成與資料庫的互動;在模型層完成與資料庫的互動後，將資料庫中XML數據轉換成相應的業務數據以便進行相應的業務邏輯處理。引入XML數據處理層後的四層模型如圖2所示。(3)現在大型關係資料庫系統基本都具有XML文檔的導入、導出功能。用基於XML共享模型的多租
戶數據擴展方案，可以將異構的數據(XML數據)導出到本地磁碟，也可以將本地磁碟的XML文檔導入到相應資料庫表的XML數據列，增強了系統數據維護人員對異構數據的維護。
