高性能實時數(shù)據(jù)分析平臺在航空公司收益提升中的應(yīng)用

【摘 要】航空公司在銷售和服務(wù)領(lǐng)域使用的旅客服務(wù)系統(tǒng)（PSS：Passenger Service System）是一個OLTP系統(tǒng)，不適合進行在線分析處理（OLAP）。在線分析處理功能的缺乏限制了航空公司的快速分析能力和響應(yīng)速度。通過解決這個問題，不僅可以提高航空公司的分析能力，還可以提高服務(wù)質(zhì)量和速度，提高航空公司的資源利用率，以及提高旅客服務(wù)滿意度，這將對航空公司的綜合收益產(chǎn)生重大影響，是目前各大航空公司的發(fā)展重點。本文探索以面向?qū)ο髷?shù)據(jù)模型以及NoSQL技術(shù)，解決實時的在線數(shù)據(jù)分析所面對的大容量、高性能、復(fù)雜業(yè)務(wù)/數(shù)據(jù)類型挑戰(zhàn)，介紹了目前已經(jīng)實現(xiàn)的高性能實時數(shù)據(jù)平臺原型，及其在航空公司的收益輔助領(lǐng)域中的應(yīng)用。最后，本文還探討了實時數(shù)據(jù)分析平臺的發(fā)展方向和在民航業(yè)其他領(lǐng)域中的可能應(yīng)用。

【關(guān)鍵詞】航空公司；收益輔助；實時數(shù)據(jù)分析；ODBMS，NoSQL

一、前言

航空公司在銷售和服務(wù)方面使用的IT系統(tǒng)被稱為“旅客服務(wù)系統(tǒng)”，Passenger Service System，簡稱PSS。PSS是一個實時交易處理系統(tǒng)，也就是OLTP系統(tǒng)。實時交易處理系統(tǒng)的核心是交易。從技術(shù)角度看，交易是數(shù)據(jù)處理的最小單位。交易只有成功和失敗兩種狀態(tài)，能夠保證數(shù)據(jù)的一致性。從行業(yè)角度看，交易是最小的業(yè)務(wù)單位，在民航業(yè)普遍存在于諸如座位可利用狀態(tài)查詢、預(yù)訂、支付、出票、值機等業(yè)務(wù)中。實時交易處理系統(tǒng)的優(yōu)勢在于高效、快速以及安全的數(shù)據(jù)操作，同時具有很高的穩(wěn)定性。旅客服務(wù)系統(tǒng)經(jīng)常需要為這種要求付出大量的出額外成本支出。

隨著民航市場競爭日益激烈、民航業(yè)務(wù)日趨復(fù)雜，航空公司旅客服務(wù)系統(tǒng)在提供高性能交易處理的同時，還需要對歷史數(shù)據(jù)進行分析和挖掘，為航空公司業(yè)務(wù)人員提供決策支持的能力，甚至通過業(yè)務(wù)規(guī)則引擎自動完成決策，實現(xiàn)商業(yè)智能化。這就要求旅客服務(wù)系統(tǒng)在提供OLTP功能的同時，還要支持

OLAP。但是在系統(tǒng)設(shè)計理念上兩者并不完全相同，前者偏重于交易處理、保證數(shù)據(jù)寫的高效和安全性、一致性；后者則偏重于強大的計算能力，需要高效的數(shù)據(jù)I/O能力和數(shù)據(jù)計算性能。通常鑒于系統(tǒng)效率、軟硬件成本考慮，不會將這兩類應(yīng)用放在同一個系統(tǒng)中。交易處理系統(tǒng)和決策支持系統(tǒng)是分離的（見圖1）；后者從交易系統(tǒng)批量下載數(shù)據(jù)快照，經(jīng)過挖掘、分析后形成業(yè)務(wù)規(guī)則，批量上傳到交易系統(tǒng)。

國內(nèi)航空市場是一個激烈競爭的市場，航空公司不僅需要線下的決策支持能力，還要求實時的決策支持能力。本文的目標(biāo)是給出一個滿足航空公司實時決策支持的在線數(shù)據(jù)分析平臺，幫助航空公司在瞬息萬變的市場上搶得先機。此時業(yè)務(wù)模型見圖2，實時數(shù)據(jù)平臺處于交易處理系統(tǒng)和數(shù)據(jù)倉庫之間，為航空公司業(yè)務(wù)人員提供只讀的實時數(shù)據(jù)分析和統(tǒng)計匯總能力。

二、實時數(shù)據(jù)平臺需要解決的主要問題

（1）實時數(shù)據(jù)同步：交易處理系統(tǒng)負責(zé)數(shù)據(jù)寫的安全性和一致性，高峰時間整個系統(tǒng)的處理量達到3000TPS（Transaction Per Second，每航空公司）。為實現(xiàn)實時數(shù)據(jù)分析，需要將這些數(shù)據(jù)從主系統(tǒng)中推送到實時數(shù)據(jù)平臺中。（2）高性能數(shù)據(jù)轉(zhuǎn)換：實時數(shù)據(jù)平臺不僅要處理高峰時間每秒3000次的入庫請求，每次入庫都需要將OLTP的數(shù)據(jù)模型轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)模型并入庫，同時要處理大規(guī)模、高并發(fā)的全庫查詢請求。（3）結(jié)構(gòu)化復(fù)雜數(shù)據(jù)支持：實時數(shù)據(jù)平臺需處理的數(shù)據(jù)經(jīng)過高度抽象后主要分為三類，即航班控制系統(tǒng)中的航班對象、訂座系統(tǒng)中的訂單對象以及支付后形成的電子票對象/結(jié)算對象。這三類數(shù)據(jù)對象每一類都非常復(fù)雜，一個簡化的訂單對象結(jié)構(gòu)見圖3，通常這三類對象層級都可以達到8～10級。在本文場景中，我們通過引入新的技術(shù)，已經(jīng)能夠比較好的解決該問題。通過OLTP系統(tǒng)的底層I/O模塊推送數(shù)據(jù)，數(shù)據(jù)接收者的延遲可以控制在20ms～200ms之間，基本滿足目標(biāo)需求。同時，通過利用下一代的對象數(shù)據(jù)庫，可以高效實現(xiàn)高性能的數(shù)據(jù)轉(zhuǎn)換以及復(fù)雜數(shù)據(jù)結(jié)構(gòu)的高性能數(shù)據(jù)處理。

三、旅客服務(wù)系統(tǒng)面臨困難的具體分析

數(shù)據(jù)規(guī)模、數(shù)據(jù)結(jié)構(gòu)在類似旅客服務(wù)系統(tǒng)這樣的信息服務(wù)系統(tǒng)中可能會非常龐大。我們以兩種主要數(shù)據(jù)樣本，描述整體的數(shù)據(jù)規(guī)模情況。

數(shù)據(jù)1，航班：國內(nèi)某大型航空集團每天航班量約3000個，可預(yù)售航班2年左右（710天），因而需要存儲的航班對象約213萬；依據(jù)航班容量不同，每個航班對象可能由數(shù)百或上千個航節(jié)、航段、艙位、座位、Bid Price對象構(gòu)成。因而僅航班類數(shù)據(jù)，就需要存儲21.3億個對象。數(shù)據(jù)2：訂單，對于訂單數(shù)據(jù)，如該航空集團每年承運7000～8000萬航段，以平均2個航段/訂單計算，系統(tǒng)中有約4000萬訂單對象，每個訂單對象由旅客身份、航段、附加服務(wù)、代理信息、價格、機票、座位等上百個對象構(gòu)成，需要存儲約20億個對象。此估算基于一年數(shù)據(jù)。整體考慮，實時數(shù)據(jù)平臺需要存儲的數(shù)據(jù)對象在60億～100億之間。

圖3 簡化的訂單對象

為了解決在復(fù)雜數(shù)據(jù)結(jié)構(gòu)和大容量的條件下，仍然要實現(xiàn)高性能的問題，我們試用了NoSQL的對象數(shù)據(jù)庫。通過多方評測我們知道，對象數(shù)據(jù)庫能夠同時在數(shù)據(jù)復(fù)雜性、數(shù)據(jù)容量和并發(fā)性三個緯度上取得平衡。在傳統(tǒng)系統(tǒng)中，數(shù)據(jù)持久化基本采用關(guān)系模型。在單表查詢時，關(guān)系數(shù)據(jù)庫可以獲得極好的性能。但當(dāng)數(shù)據(jù)結(jié)構(gòu)變復(fù)雜，關(guān)系模型必須引入關(guān)聯(lián)查詢，此時性能隨著關(guān)聯(lián)層級增加呈指數(shù)下降。我們需要處理的三類數(shù)據(jù)都有8～10級繼承，如果將它們關(guān)系化為二維表，勢必造成多層級關(guān)聯(lián)。如果采用單個二維表存儲并建大量索引優(yōu)化性能，會面臨兩個無法解決的問題，即每個表都有數(shù)千字段和大量數(shù)據(jù)冗余，都造成修改和維護困難，查詢效率底的問題。如果不對數(shù)據(jù)對象做結(jié)構(gòu)化，而是將整個數(shù)據(jù)對象作為Blob存儲，就無法對目標(biāo)數(shù)據(jù)進行靈活查詢；此時每增加一類查詢應(yīng)用，都需要從Blob中結(jié)構(gòu)化出相關(guān)字段（對象屬性），放入二維表。當(dāng)支持所有類型的查詢時，就需要從Blob中結(jié)構(gòu)化出所有字段（對象屬性）。實際上我們發(fā)現(xiàn)在具體實踐中也確實是這樣進行設(shè)計的。另一方面，現(xiàn)今絕大多數(shù)程序開發(fā)都采用面向?qū)ο竽Ｐ停绻４鏀?shù)據(jù)到關(guān)系型數(shù)據(jù)庫，就需要在運行時在對象模型和關(guān)系模型之間進行轉(zhuǎn)換，即OR Mapping。對象-關(guān)系轉(zhuǎn)換會消耗大量處理器時間，降低系統(tǒng)的整體性能。雖然目前Hibernate等框架可以提升OR Mapping的編程效率，但無法解決OR

Mapping帶來的性能降低問題，而且在有些時候會造成額外的成本。

四、旅客服務(wù)系統(tǒng)實時數(shù)據(jù)平臺實現(xiàn)高性能和高可靠性的探索

圖4 Versant數(shù)據(jù)庫的多層架構(gòu)

實時數(shù)據(jù)平臺采用與主系統(tǒng)相同的多層架構(gòu)，從下往上依次是數(shù)據(jù)庫服務(wù)器（Database Server），應(yīng)用服務(wù)器（Applica

tion/Web Service Server）以及Web服務(wù)器。其中，數(shù)據(jù)持久是目前的性能瓶頸所在。為解決這個問題，在數(shù)據(jù)庫層面，我們選擇了商業(yè)對象數(shù)據(jù)庫Versant，建立了高性能應(yīng)用服務(wù)器緩存架構(gòu)。圖4描述了基于高性能緩存的多層數(shù)據(jù)架構(gòu)。

由于實時數(shù)據(jù)平臺向外提供服務(wù)的方式大部分為Web

Service，因而多層架構(gòu)的核心是數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器緩存兩層。Versant提供的雙緩存技術(shù)在應(yīng)用服務(wù)器上并提供無縫內(nèi)存數(shù)據(jù)緩存能力，實現(xiàn)類似內(nèi)存數(shù)據(jù)庫的功能。利用這一特性，我們讓一些訪問頻度高、不常變化數(shù)據(jù)對象常駐內(nèi)存，例如圖5中的Airline對象、FlightNumber對象、FlightFrequency對象以及各類Index對象。由于應(yīng)用服務(wù)器有足夠的內(nèi)存空間（單機32G內(nèi)存），配置Inventory對象也常駐內(nèi)存。對于其他類型數(shù)據(jù)，如SuperPNR對象、ET對象和RAccounting對象，則采用動態(tài)緩存技術(shù)，查詢命中的數(shù)據(jù)緩存在內(nèi)存中，規(guī)定時間內(nèi)未使用同時又有新數(shù)據(jù)進入（例如5000ms）則purge老數(shù)據(jù)。

在部署上，采用4臺應(yīng)用服務(wù)器對2臺數(shù)據(jù)庫服務(wù)器的結(jié)構(gòu)，每臺應(yīng)用服務(wù)器同時連接到2臺數(shù)據(jù)庫服務(wù)器。2臺數(shù)據(jù)庫服務(wù)器互為熱備，每臺服務(wù)器都擁有全數(shù)據(jù)，采用V/FTS技術(shù)實現(xiàn)同步復(fù)制。數(shù)據(jù)同時寫入兩個服務(wù)器，數(shù)據(jù)讀取可以在任意服務(wù)器上執(zhí)行。V-Server（數(shù)據(jù)庫服務(wù)器）負責(zé)將數(shù)據(jù)對象讀出并發(fā)送到V-Client中；當(dāng)進行數(shù)據(jù)寫操作時，V-Server檢查所有V-Server和Client中的數(shù)據(jù)，對受影響的數(shù)據(jù)對象加寫鎖，當(dāng)寫操作完成后，將新的數(shù)據(jù)對象同步到其他V-Server和Client中。2臺數(shù)據(jù)庫服務(wù)器互為熱備的部署在單點失效時自動將應(yīng)用切換到另一節(jié)點上；等失效節(jié)點恢復(fù)后自動追，直到兩臺服務(wù)器同步后自動切回初始狀態(tài)。因而在失效過程中不會丟失事務(wù)，保證了數(shù)據(jù)的安全性和一致性，整個系統(tǒng)實現(xiàn)零失效時間、7×24小時不間斷服務(wù)。

基于上述技術(shù)，實時數(shù)據(jù)平臺原型實現(xiàn)了非常好的性能。壓力測試給出的結(jié)果，在單線程下對復(fù)雜對象（SuperPNR）的寫入和查詢都能獲得極高性能：

五、旅客服務(wù)系統(tǒng)實時數(shù)據(jù)平臺實現(xiàn)對結(jié)構(gòu)化的復(fù)雜數(shù)據(jù)的靈活支持的探索

實時數(shù)據(jù)平臺處理的數(shù)據(jù)種類較多，每類數(shù)據(jù)都有各不相同的復(fù)雜數(shù)據(jù)結(jié)構(gòu)。面向?qū)ο蟮姆椒ㄕ撨m用于處理復(fù)雜數(shù)據(jù)和業(yè)務(wù)邏輯。圖5是簡化的數(shù)據(jù)模型。其中藍色部分是代表航空公司和航班的對象，Airline對象是對航空公司的抽象，F(xiàn)light

Number對象和FlightFrequency對象在業(yè)務(wù)上是找到航班In

ventory對象的索引，為了提高查詢效率，又引入了FlightDateI

dx對象。SuperPNR對象是主訂單，為了高效訪問，引入了5類索引對象，即PAXNameIdx、PAXIdIdx、PNRLocator、IATANum

berIdx和TicketNumberIdx對象。電子票票面ETicket和支付結(jié)算RAccouting對象是同一數(shù)據(jù)的兩種視圖，提供了SuperPNR、TicketNumber和國際航協(xié)結(jié)算號IATANumber三種查詢?nèi)肟凇?/p>

圖5 實時數(shù)據(jù)平臺的簡化數(shù)據(jù)結(jié)構(gòu)

這種索引方式是根據(jù)業(yè)務(wù)需要，按照面向?qū)ο蟮脑O(shè)計方法自然形成的。因而在運行時并不需要為了提升性能設(shè)計專門的索引，如在關(guān)系數(shù)據(jù)庫中必須要做的。當(dāng)這種結(jié)構(gòu)化了的復(fù)雜數(shù)據(jù)對象直接進行持久化、存入對象數(shù)據(jù)庫，我們使用這種天然索引就可以快速找到這些對象，并用對象的方法（與數(shù)據(jù)庫無關(guān)，對象數(shù)據(jù)庫只保存對象屬性或稱為對象狀態(tài)，方法是面向?qū)ο蠓椒ㄌ峁┑牧硪粋€重要概念）進行高效的數(shù)據(jù)分析和統(tǒng)計。在編寫這些方法的時候，我們參考了OLTP系統(tǒng)中已有的代碼邏輯，這進一步縮短了開發(fā)和測試時間，提升了開發(fā)質(zhì)量。

引入對象數(shù)據(jù)庫的另一個好處是數(shù)據(jù)Scheme可以在運行時進行修改。由于對象數(shù)據(jù)庫的scheme就是類圖，當(dāng)類修改（對象屬性的增刪改）時數(shù)據(jù)scheme會跟著發(fā)生變化。Versant提供的一種機制可以讓不同版本的scheme同時存在，并在運行時修改scheme。當(dāng)Server上的scheme成為新版本，Client內(nèi)存中的數(shù)據(jù)仍然使用老版本。當(dāng)內(nèi)存中的數(shù)據(jù)超時purge之后，再次裝入的數(shù)據(jù)就已經(jīng)是新版本了。這個方案提供了兩個能力，首先修改數(shù)據(jù)結(jié)構(gòu)輕而易舉，當(dāng)業(yè)務(wù)要求增加或改變?nèi)魏巫侄螘r，只需要修改類，持久層是自適應(yīng)的；其次由于數(shù)據(jù)修改不需要停機，如同時采用Java語言開發(fā)（我們就是這么做的），就可以做到應(yīng)用程序更新、上線不停機，這樣能夠為客戶提供真正永不下線的服務(wù)。

上述技術(shù)不僅實現(xiàn)復(fù)雜數(shù)據(jù)結(jié)構(gòu)化的存儲，也使持久層得到了巨大的靈活性，這使得應(yīng)用系統(tǒng)也獲得了相當(dāng)?shù)撵`活性。

六、旅客服務(wù)系統(tǒng)實時數(shù)據(jù)平臺實現(xiàn)海量數(shù)據(jù)的高效存儲

作為OLAP系統(tǒng)，實時數(shù)據(jù)平臺不僅需要實時同步來自O(shè)LTP的數(shù)據(jù)，還必須保留已經(jīng)結(jié)束生命周期的數(shù)據(jù)。目前我們的實時數(shù)據(jù)平臺原型為國內(nèi)某大型航空集團保留的數(shù)據(jù)量大致估算為：

上表中估算的數(shù)據(jù)量都是基于最頂層的數(shù)據(jù)對象進行的，這三類對象每一種都由數(shù)百甚至上千子對象組合而成，實際的存儲量是驚人的。實時數(shù)據(jù)平臺基于Versant提供的分布式對象管理機制，實現(xiàn)將不同類型的數(shù)據(jù)對象存入不同的數(shù)據(jù)庫中，而對應(yīng)用服務(wù)器透明。這種能力就是通常在關(guān)系數(shù)據(jù)庫中的“分表分庫”操作。圖7是對該機制的簡單圖釋，數(shù)據(jù)對象A、

B、C、D在應(yīng)用中（Client）是相關(guān)的，它們之間的關(guān)系由“對象管理器”維護，而在后臺數(shù)據(jù)對象實際存儲在不同的數(shù)據(jù)庫中，同時可以在幾個數(shù)據(jù)庫之中遷移。需要說明的是，對象管理器中對象關(guān)系模型需要由應(yīng)用程序開發(fā)人員開發(fā)和維護。

圖6 分布式對象存儲

七、實時數(shù)據(jù)平臺在航空收益輔助中的作用方式和意義

技術(shù)上的創(chuàng)新可能會對業(yè)務(wù)系統(tǒng)的發(fā)展帶來革命性的影響，利用已經(jīng)實現(xiàn)的高性能實時數(shù)據(jù)平臺，原有的一些看起來不太可能實現(xiàn)的業(yè)務(wù)需求現(xiàn)在已經(jīng)成為可能。而新的業(yè)務(wù)必然會幫助航空公司提升服務(wù)質(zhì)量，并且在激烈競爭中獲得領(lǐng)先地位。本文就已經(jīng)相對比較成熟的場景進行了總結(jié)，也同時對實時數(shù)據(jù)平臺建設(shè)的意義進行再次確認。

應(yīng)用場景一：實時自動清票。自動出票時限是依據(jù)航空公司設(shè)定的業(yè)務(wù)規(guī)則，在訂單生成時自動加入的。OLTP系統(tǒng)在夜間定時掃描所有訂單，將第二天到期的訂單編號記錄在一個數(shù)據(jù)表中，然后定時掃描（通常是每小時）該數(shù)據(jù)表及訂單內(nèi)容，發(fā)現(xiàn)過期或已過期未支付出票的訂單，自動釋放被占用座位。這種解決方案的缺點顯而易見，一是因清票不及時會影響座位的再次銷售；二是集中消耗大量系統(tǒng)資源造成系統(tǒng)運行緩慢。最壞情況下過期一個多小時后才能清票，在旺季給航空公司造成大量收益損失。

在實時數(shù)據(jù)平臺環(huán)境中，當(dāng)接收到同步的SuperPNR對象后，調(diào)用HasTimeLimit（）方法，如果對象中有“出票時限”項，則根據(jù)時限將對象指針插入一個有序鏈表。同時后臺有定時器，每分鐘從頭遍歷鏈表，將上一分鐘的鏈表節(jié)點移出，依次對鏈表頭上時限為當(dāng)前這一分鐘的訂單對象進行處理。如果需要清票，則調(diào)用OLTP系統(tǒng)提供的座位釋放API，以訂單編號為參數(shù)完成清票操作。這樣使清票操作的實時性提升到分鐘級，最壞情況下延遲僅1分鐘，完全封堵了航空公司這方面的收益漏洞；同時OLTP系統(tǒng)不再需要掃描全數(shù)據(jù)庫，節(jié)省了昂貴的處理器資源；而整個開發(fā)投入非常少。目前該應(yīng)用已經(jīng)投入實際使用。

應(yīng)用場景二：航班銷售監(jiān)控和預(yù)警。OLTP系統(tǒng)雖然能夠處理銷售交易，但對于整個銷售過程中出現(xiàn)的異常狀況（指和收益管理系統(tǒng)的預(yù)測不符合的情況，如短時間內(nèi)大量預(yù)訂或取消）無能為力。我們基于實時數(shù)據(jù)平臺，開發(fā)了航班銷售和預(yù)警模塊。該模塊的輸入是來自收益管理系統(tǒng)的預(yù)測曲線，包括全市場和目標(biāo)航空公司的。當(dāng)實際銷售曲線和預(yù)測曲線出現(xiàn)超出預(yù)定值的偏差時，可通過幾種方式通知銷售管控人員，以便后者進行銷售規(guī)則的調(diào)整。通知的方式包括客戶端彈出對話框、手機短信息以及電子郵件。該應(yīng)用能夠有效幫助航空公司銷售實現(xiàn)管理精細化，快速對市場變化做出反映，是航空公司提升銷售的利器。

應(yīng)用場景三：假票號驗證。有時代理人為了規(guī)避航空公司設(shè)定的自動出票時限業(yè)務(wù)規(guī)則，會輸入假票號。在OLTP系統(tǒng)中，甄別假票號是一件比較困難、高成本的事情。我們基于實時數(shù)據(jù)平臺開發(fā)了訂單中假票號的驗證功能，利用電子票票面數(shù)據(jù)和結(jié)算數(shù)據(jù)，在訂單中加入票號的時候?qū)ζ溥M行校驗，并將假票號訂單報告出來，供航空公司業(yè)務(wù)人員進行手工或自動批量處理。目前國內(nèi)市場上已經(jīng)基本實現(xiàn)全電子票（ET），并大力推廣附加服務(wù)銷售的電子雜費單（EMD）應(yīng)用，因而假票號校驗功能應(yīng)用前景非常廣闊。

八、結(jié)論與展望

本文主要探討了實時數(shù)據(jù)應(yīng)用平臺實現(xiàn)方面遇到的各種問題，以及如何基于對象數(shù)據(jù)庫和面向?qū)ο蠓椒▉硪韵鄬艿偷某杀緦崿F(xiàn)系統(tǒng)的高性能、高穩(wěn)定性、復(fù)雜數(shù)據(jù)結(jié)構(gòu)化后存儲，同時還討論了海量數(shù)據(jù)存儲的高效解決方案。作為驗證，我們已經(jīng)實現(xiàn)了一個原型系統(tǒng)，為航空公司提供了幾個有效應(yīng)用，幫助航空公司提升收益，確實收到了良好的效果。

未來我們將基于該原型系統(tǒng)，一方面擴展數(shù)據(jù)種類，比如加入航班計劃（Schedule）數(shù)據(jù)；另一方面開發(fā)更多的服務(wù)接口，支持更多應(yīng)用。在應(yīng)用方面，我們可以支持航空公司CRM系統(tǒng)，為CRM系統(tǒng)提供旅客行程歷史，分析旅客價值等；支撐收益輔助（Revenue Integrity）系統(tǒng)，持續(xù)幫助提升航空公司收益。同時可以基于服務(wù)接口開發(fā)航空公司個性化應(yīng)用，因為整個系統(tǒng)具有非常好的可擴展性和靈活性。另外，原型系統(tǒng)中使用的仍然是商業(yè)數(shù)據(jù)庫軟件，我們計劃試驗整套解決方案中底層數(shù)據(jù)庫的可替代性，使用開源數(shù)據(jù)解決方案（memcacheredis）進行兩個方案下的性能、成本、穩(wěn)定性、靈活性對比，從而為進一步降低系統(tǒng)的成本進行探索。

參 考 文 獻

[1][美]AbrahamSilberschatz HenryF.Korth S.Sudarshan 楊冬青，唐世渭等譯.數(shù)據(jù)庫系統(tǒng)概念[M].北京：中國機械工業(yè)出版社，2000

[2]李磊.基于范式的查詢公式求值和優(yōu)化算法[J].計算機工程.2000

[3][美]D.Solomon R.Rankins 熊桂喜，高峰，馮學(xué)民譯.Microsoft SQL

Server開發(fā)指南[M].北京：清華大學(xué)出版社，1998

[4]張在建.數(shù)據(jù)庫查詢優(yōu)化技術(shù)[J].計算機學(xué)報.1999