rrd演算法

A. 資料庫物理模型

資料庫物理模型設計的目標是根據選定的Oracle資料庫系統特點和航空物探數據管理與服務的業務處理需求,確定航空物探資料庫最優的物理環境、存取方法和存儲結構。即通過資料庫物理設計,以便達到物理資料庫結構的優化,使得在資料庫上運行的各種事務響應時間少、存儲空間利用率高、事務吞吐率大。

一、資料庫布局

航空物探信息系統的維護數據(部門、崗位、人員、人員許可權、數據入庫檢查規則及數據字典等)相對比較穩定。入庫前數據需經過各種檢查校對,確認數據正確後才能歸檔,存入航空物探資料資料庫,所以存入資料庫前的數據可能經常需要修改和刪除,相對變化較大;而存入資料資料庫中的數據一般不允許修改和刪除,以免誤操作破壞資料庫數據造成損失。

圖2-12 航空物探資料庫邏輯模型

圖2-13 航空物探資料庫布局與數據採集流程圖

據此,我們採用圖2-13所示的資料庫數據採集流程,並將航空物探資料庫分為資料採集資料庫、資料資料庫、系統維護資料庫分別進行存儲和管理,實現數據的統一管理和統一使用,便於數據入庫和易於維護等。

航空物探資料資料庫是航空物探所有數據最終存儲的場所。資料採集資料庫是數據歸檔存入資料資料庫前的臨時「集散地」,在此接收各項檢查,在確認數據無誤後歸檔到資料資料庫,然後刪除資料採集資料庫中已歸檔的數據。此外,資料採集資料庫中還保存數據入庫、維護、檢查日誌及歸檔記錄。

系統維護資料庫,存儲系統維護信息(如系統功能、資料庫表清單等)、安全信息(如信息系統用戶的角色、許可權、授權的系統功能等),數據字典、入庫數據檢查規則等。將其與航空物探數據分開,有利於系統維護和管理。

二、資料庫空間設置

資料庫空間設置包括磁碟空間設置、應用系統表空間設置、撤銷表空間、臨時表空間、日誌空間和索引空間設置。

(一)磁碟空間設置

磁碟空間設置的目標:磁碟性能不能阻礙實現資料庫性能,資料庫磁碟必須專用於資料庫文件,否則非資料庫將會影響到資料庫性能,且磁碟空間必須滿足恢復和性能的要求。

航空物探資料庫伺服器為IBMP620小型機,8塊硬碟,每塊硬碟36GB空間,每塊物理磁碟建立一個文件系統。為了提高磁碟的反應時間和尋道時間,提高I/O的存取效率,除了一塊硬碟用於UNIX操作系統外,其餘7塊磁碟分別存放資料採集資料庫、系統維護資料庫-日誌文件,資料資料庫及資料資料庫的大欄位數據、索引、回滾段和數據日誌文件。

(二)應用系統表空間設置

信息系統數據採集過程對數據的事務操作比較頻繁,經常進行數據插入(新數據入庫)、修改(入庫數據有誤)和刪除操作(數據重新導入或歸檔入庫),因此航空物探資料採集資料庫所在的表空間會很活躍。為了不影響其他I/O的競爭,同時也可以提高數據入庫的操作效率(50多年的歷史數據需要集中入庫),分配一個磁碟空間(36GB)為採集庫的表空間。由於採集數據歸檔入資料庫後被刪除,同時進行數據入庫的項目也不是很多,雖仍保留所有的採集日誌數據,一個磁碟空間也足夠使用。

航空物探資料資料庫的二維表和Oracle大欄位(BLOB)分別存放在不同的物理磁碟(每個磁碟36GB)上,對同時存在有表格數據和大欄位數據的資料庫表(如航跡線數據)時,可以提高磁碟I/O效率。隨著數據入庫的項目越來越多,需要增加相應的物理磁碟或磁碟陣列。

系統維護資料庫相對穩定,佔用磁碟空間約500M左右。由於系統磁碟有限,把日誌文件存放該磁碟中。

(三)撤銷表和臨時表空間的設置

在Oracle資料庫中,撤銷的目的是確保事務的回退和恢復。撤銷參數有UNDO_MANAGEMENT、UNDO_TABLESPACE和UNDO_RETENTION。

UNDO_MANAGEMENT參數用於資料庫中管理撤銷數據的方式,航空物探資料庫設置為自動模式(auto)。

UNDO_TABLESPACE參數用於指定資料庫中保存撤銷數據的撤銷表空間名稱,航空物探資料庫撤銷表空間名稱為UNDO_ARGS_TBSPACE,空間大小設置為20GB,以確保在保留時間內進行恢復。

UNDO_RETENTION參數用於指定已經提交事務的撤銷數據在能夠覆蓋之前應該保留多長時間,本資料庫系統設置為60min。

臨時表空間是用以存儲大量的排序,與撤銷表空間存放在一個物理磁碟上,本資料庫系統臨時表空間設置為500M。

(四)日誌空間設置

日誌的主要功能是記錄對資料庫已做過的全部操作。在系統出現故障時,如果不能將修改數據永久地寫入數據文件,則可利用日誌得到該修改,所以不會丟失已有操作結果。

日誌文件主要是保護資料庫以防止故障。為了防止日誌文件本身的故障,航空物探資料庫系統分別在一個獨立磁碟和系統維護庫磁碟中存放日誌文件。若系統出現故障,在下次打開資料庫時Oracle資料庫系統自動用日誌文件中的信息來恢復資料庫文件。

根據航空物探資料庫信息系統同時登錄的用戶數及使用的功能,將日誌文件大小設置為10GB。

(五)索引表空間設置

為了提高航空物探信息系統的查詢和統計速度,把所有索引空間與應用表空間完全分開,從而提高I/O存取效率。航空物探索引表空間大小設置為10GB。

聚集是表的一種存儲方法,一般每個基本表是單獨組織的,但對邏輯上經常在一起查詢的表,在物理上也鄰近存放,這樣可減少數據的搜索時間,提高性能。

當幾個關系(表)以聚集方式組織時,是通過公共屬性的值為表聚集的依據。航空物探資料庫系統是以項目標識(PROJ_ID)建立聚集的,所有涉及項目標識的資料庫表直接引用項目標識聚集。航空物探聚集表空間與索引表空間相同。

三、資料庫參數設置

在資料庫創建前需要對如下資料庫參數進行設置,航空物探參數文件名為Inito-raargs.ora,各種參數設置如下:

DB_block_size=16384

DB_name=oraagrs

DB_domain=oraargs.com

Compatible=9.1.0

Nls_characterset=ZHS16GBK

Open_Cursors=100

DB_files=100

DB_file_mutliblock_read_count=16

Log_checkpoint_interval=256000

Processes=200

四、內存設置

航空物探資料庫伺服器物理內存為4GB,除部分用於系統開銷外,其餘全部用於資料庫。

Oracle使用共享系統全局區(System Globla Area,SGA)內存來管理內存和文件結構,包含DB_block_Bufers、DB_cache_size、Shared_pool_size、Log_Buffer參數。航空物探資料庫系統的全局區內存參數設置如下。

DB_block_Buffers參數為SGA中存儲區高速緩存的緩沖區數目,每個緩沖區的大小等於參數DB_block_size的大小,DB_block_Buffers=19200(約300MB)。

Shared_pool_size參數為分配給共享sql區的位元組數,是SGA大小的主要影響者,Shared_pool_size=1228800000(1.2GB)。

DB_cache_size參數是SGA大小和資料庫性能的最重要的決定因素。該值較高,可以提高系統的命中率,減少I/O,DB_cache_size=1024000000(1GB)。

Log_Bufer參數為重做日誌高速緩存大小,主要進行插入、刪除和修改回退操作,Log_buffer=5120000(5MB)。

五、優化設置

由於航空物探信息系統的採集軟體和應用軟體是採用MS.NETC#進行開發的,應用程序與資料庫之間的連接有傳統的ODBC和OLEDB兩種方式。為了支持ODBC在OLEDB技術上建立了相應的OLEDB到ODBC的調用轉換,而使用直接的OLEDB方式則不需轉換,從而提高處理速度。

在建立資料庫表時,參數Pctfree和Pctused設置不正確可能會導致數據出現行鏈接和行遷移現象,即同一行的數據被保存在不同的數據塊中。在進行數據查詢時,為了讀出這些數據,磁頭必須重新定位,這樣勢必會大大降低資料庫的執行速度。因此,在創建表時應充分估計到將來可能出現的數據變化,正確地設置這兩個參數,盡量減少資料庫中出現的行鏈接和行遷移現象。

航空物探資料採集資料庫表的插入、修改和刪除的頻率較高,Pctfree設置為20,Pctused設置為40;系統維護資料庫表相對穩定,Pctfree設置為10,Pctused設置為15;資料資料庫表除了增加數據外基本不進行修改和刪除操作,Pctfree設置為10,Pctused設置為5。

六、擴展性設置

多CPU和並行查詢PQO(Parallel Query Option)方式的利用:CPU的快速發展使得Oracle越來越重視對多CPU的並行技術的應用,一個資料庫的訪問工作可以用多個CPU相互配合來完成。對於多CPU系統盡量採用並行查詢選項方式進行資料庫操作。航空物探資料庫伺服器為2個CPU,在程序查詢中採用了並行查詢的方式。

在航空物探工作量統計、飛行小時統計、測量面積統計和岩石物性統計中,為了加快統計效率,在相應的查詢語句中增加了並行查詢語句。

隨著航空物探高精度測量程度的不斷提高,測量數據將越來越大。為了滿足航空物探查詢效率及發展,將航磁測量數據與校正後航磁測量數據按比例尺分1:20萬以下、20萬~50萬、1:50萬以上分別存放3張不同的資料庫表。

七、創建資料庫

在完成資料庫布局、空間設置、內存設置、資料庫參數設置、擴展性設置和優化設置後,進行航空物探資料庫物理模型設計,即航空物探資料庫實體創建。由於航空物探空間資料庫邏輯模型是採用ESRI提供的ArcGIS UML構建的Geodatabase模型,因此,使用ESRI公司提供的CaseTools將航空物探數據UML模型圖轉成空間資料庫(Geodatabase)實體(圖2-14)。

航空物探屬性資料庫表(二維表)是採用Power Designer資料庫設計平台直接把資料庫關系模型生成資料庫腳本來創建的。

經過資料庫的概念設計、邏輯設計和物理設計,最終生成航空物探資料庫。

圖2-14 航空物探資料庫物理模型實現

八、空間數據的索引機制

對於海量的空間資料庫而言,資料庫的操作效率是關繫到資料庫成敗的關鍵問題。為了提高數據的訪問、檢索和顯示速度,數據在載入到資料庫時,要素類數據建立了空間索引,柵格數據構建了金字塔結構,對象類數據採用與資料庫直接聯接的訪問機制。

(一)空間索引

為了提高要素類數據的查詢性能,在建立航空物探空間資料庫時,創建了空間索引機制。常用的空間索引有格網索引、R樹索引、四叉樹索引等。Geodatabase採用格網索引方式。所謂格網索引是將空間區域劃分成適合大小的正方形格網,記錄每一個格網內所包含的空間實體(對象)以及每一個實體的封裝邊界范圍,即包圍空間實體的左下角和右上角坐標。當用戶進行空間查詢時,首先計算出用戶查詢對象所在格網,然後通過格網編號,就可以快速檢索到所需的空間實體。

確定適合的格網級數、單元大小是建立空間格網索引的關鍵。格網太大,在一個格網內有多個空間實體,查詢檢索的准確度降低。格網太小,則索引數據量成倍增長和冗餘,檢索的速度和效率較低。資料庫的每一數據層採用不同大小、不同級數的空間索引格網單元,但每層最多級數不能超過三級。格網單元的大小不是一個確定性的值,需要根據對象的大小確定。空間索引格網的大小與檢索准確度之間的關系如圖2-15所示。

選擇格網單元的大小遵循下列基本原則:

1)對於簡單要素的數據層,盡可能選擇單級索引格網。減少RDBMS搜索格網單元索引的級數,縮短空間索引搜索的過程,例如航跡線要素類。

圖2-15 索引格網大小與檢索准確度的關系

2)如果數據層中的要素封裝邊界大小變化比較大,應選擇2或3級索引格網。Geodata-base最多提供三級格網單元。每一要素封裝邊界在適合的級內,減少了每一封裝邊界有多個格網的可能性。在空間索引搜索過程中,RDBMS則必須搜索所有3個格網單元級,這將消耗大量的時間。

3)若用戶經常對圖層執行相同的查詢,最佳格網的大小應是平均查尋空間范圍的1.5倍。

4)格網的大小不能小於要素封裝邊界的平均大小,為了減少每個格網單元有多個要素封裝邊界的可能性,格網單元的大小應取平均格網單元的3倍。最佳格網單元的大小可能受圖層平均查詢的影響。

空間域是按照要素數據集定義的,空間索引格網是按照要素類設置的。它們都是在創建Geodatabase資料庫時設置,並一經設置,中間不許改變;所以一定要在充分分析數據的情況下確定它們的值。航空物探數據主要是簡單要素類,空間跨度為70°。根據上述原則,航空物探數據選擇單級索引格網,格網大小為20°。

(二)金字塔結構

金字塔結構的核心是將柵格數據逐級進行抽稀,形成多級解析度的重采樣數據,並將其分割成塊,按一定的文件格式(金字塔文件格式)存儲成磁碟文件;在以後進行圖像顯示處理時,只需將要顯示的部分所覆蓋的塊從磁碟文件直接讀進內存緩沖區顯示即可。從金字塔的所有層中尋找與所要求顯示的比例相近或匹配的一層,並將該層的從某一點起的一定范圍的圖像所覆蓋的所有塊載入到內存緩沖區,提取所需部分並形成圖像。

金字塔演算法(圖2-16)是通過獲取顯示時所需要的一定解析度的數據來提高顯示速度。使用金字塔數據格式後,在顯示全圖時僅需要顯示一個較低解析度的數據,這樣既能加快顯示速度,又不會影響顯示效果。放大圖像,盡管顯示圖像解析度提高,由於顯示區域減小,所以顯示速度不會下降。如果沒有為柵格數據建立金字塔數據,則每次顯示都會讀取整個數據,然後進行重采樣得到顯示所需要的解析度,明顯地降低了顯示速度。

圖2-16 金字塔壓縮示意圖

金字塔數據重采樣方式有:最近鄰法、雙線性內插和立方卷積。其中最近鄰法適用於離散數據,而雙線性內插法和立方卷積法適合於連續數據。

在ArcGISEngine中提供了IRasterPyramid和IRasterPyramid2介面來實現金字塔數據的建立,而建立的數據保存在*.rrd格式的文件中。

(三)空間域定義

空間域是指數據的有效空間范圍,即Geodatabase資料庫的最大等效坐標的值域范圍,其定義主要是指比例系數和MinX、MinY的計算。

因為使用整數比浮點數有更高的壓縮率,並且對整數進行二進制搜索比較快,所以多用戶Geodatabase以4位元組正整數存儲坐標,其最大值為32位正整數所能表示的范圍是21.4億(2147483647),整數的范圍稱為空間域。在創建Geodatabase資料庫時需要定義合適的比例系數。大的整數值將消耗大量的計算機物理內存,所以選定的比例系數最好不要大於必須的比例系數。空間域隨坐標系的單位變化而變化。

比例系數和空間域之間成反比例關系,比例系數越大(存儲單位越小),表達的空間域也越小。為了使目標數據都存儲在系統中,需要謹慎地設置比例系數。將目標數據的寬度和高度較適中的數值乘以比例系數,如果結果小於21.4億,則比例系數是合適的。

航空物探數據模型是為我國的航空物探行業數據建庫設計的,它支持的空間數據的坐標范圍為我國領土覆蓋的海陸空間,最低緯度為赤道。根據概念設計的分析,航空物探數據模型採用的是地理坐標系,坐標系單位是度,基準是Beijing_1954,要求存儲的坐標數據精度達到0.01m。在赤道處,赤道圓周長為40075694.6m,則每度弧長=40075694.6×100/360cm=11132137.389cm,即1cm對應8.983000883E-8°。所以,航空物探數據模型的比例系數取為8.98E-8,即存儲單位為8.98E-8°,可滿足1cm精度要求。

將空間域移動到目標數據范圍之前,首先找到空間域在存儲單位的中心位置,目的是在必要時向各個方向擴展。4位元組正整數可表示的坐標范圍:2147483647×8.98E-8=192.84。我國的領土范圍是東經70°~140°,北緯0°~60°。所以,選取的比例系數是合適的。把空間域坐標系中心定為90°,然後,計算空間域的MinX、MinY。

MinX=((70+140)÷2)-90=15

MinY=((0+60)÷2)-90=-60

所以坐標的存儲數據是:

X_Storage=(X-MinX)/8.98E-8

Y_Storage=(Y-MinY)/8.98E-8

B. C語言問題

當進行64位與32位的混合運算時，32位整數會被隱式轉換成64位整數。但是，VC的輸入輸出與__int64的兼容就不是很好了，如果你寫下這樣一段代碼：
1 __int64 a;
2 cin >> a;
3 cout << a;

那麼，在第2行會收到「error C2679: binary '>>' : no operator defined which takes a right-hand operand of type '__int64' (or there is no acceptable conversion)」的錯誤；在第3行會收到「error C2593: 'operator <<' is ambiguous」的錯誤。那是不是就不能進行輸入輸出呢？當然不是，你可以使用C的寫法：
scanf("%I64d",&a);
printf("%I64d",a);
就可以正確輸入輸出了。當使用unsigned __int64時，把"I64d"改為"I64u"就可以了。
OJ通常使用g++編譯器。其64位擴展方式與VC有所不同，它們分別叫做long long 與 unsigned long long。處理規模與除輸入輸出外的使用方法同上。對於輸入輸出，它的擴展比VC好。既可以使用
1 long long a;
2 cin>>a;
3 cout<<a;
也可以使用
scanf("%lld",&a);
printf("%lld",a);

使用無符號數時，將"%lld"改成"%llu"即可。
最後我補充一點：作為一個特例，如果你使用的是Dev-C++的g++編譯器，它使用的是"%I64d"而非"%lld"。

上面轉載別人的文章~~

我在VS平台上，較常使用long long~~
__int64在VS上可以使用，而且可以直接cin，cout；

C. iPhone x的最大亮點是什麼

Face ID 是否安全？

眾多實時證明，這些年，蘋果沒有打過無把握的仗，Face ID 作為 Touch ID 的替代方案，已經可以用於 Apple Pay ，由此可見蘋果對它有足夠的自信。加上 Face ID 是 3D 識別，紅外識別，等等感測器，只有有一個感測器的信息無法匹配，就無法進行解鎖或者支付，這可不是一張照片就能夠欺騙過去的。

試問，你記得支付寶要求你面部識別的操作嗎？是不是要你對著臉，然後眨眼。我猜，它應該是快速拍攝兩張照片，或者一個短片，將其中的每一幀（或者照片）進行比對，以辨別是不是活人。

另外，你應該要相信蘋果的軟硬結合的實力，當用戶開始使用的時候，蘋果也會不斷去迭代 Face ID 的演算法。

關於雙胞胎識別的問題，我回頭會讓安妮和安娜去試試，以後告訴大家結果。

Qi 無線充電

Qi 是無線電力聯盟所推出的無線充電標准。這一次蘋果沒有自己去定義這個標准，而是採用了現成的方案（關於 Qi 細節，大家可自行去查詢）。市面上有很多的設備支持 Qi 標准，如果有興趣，你可以自行查詢。

Qi 無線充電採用的是電磁感應原理。而影響電磁感應強弱的關鍵因素是磁通量，你可以將它理解為充電底座和手機之間那一個看不見的電流通道。（初中物理就有學過好像）

磁通量計算公式是：Φ=BS ，磁感應強 B 與垂直磁場方向的面積 S 的乘積。

舉一個例子（地磁強度與水平面垂直且一定），我們將自己的雙手比作手機和充電底座，這時候我們將雙手水平重疊放置，這時候兩者之前的重合面積是最大的，當我開始轉動一個手掌的時候，正對面積會慢慢變小，隨之帶來的變化是磁通量會變小，充電的功率也會受到影響。

顯示情況中更加復雜，充電底座與手機的正對面積、兩者之間的高度、以及電流電壓的強度，手機溫度和環境溫度都會相應無線充電的效率。

雖然它能夠解放你桌面上的數據線（嗯，充電底座你需要單獨購買，並且應該不會很便宜），但是基於以上的這些說明，我覺得，無線充電是一個說不上雞肋，但又有點尷尬的功能。當然，這是我從理論出發進行的分析，實際上的體驗如何，有待驗證。

對了，上一代 iPhone 7 系列不能支持無線充電的原因是機身是金屬機身，本身就會有屏蔽效應，是絕對不可能搭載無線充電的。所以，這一代更換玻璃機身就更加說得過去了。

新交互

iPhone X 採用了全面屏，所以，Home 鍵這一個存在了十年的標志被蘋果爸爸拋棄了，取而代之的是蘋果在 iOS 系統中採用了一個叫做 Home Indicator 的虛擬「按鍵」（雖然是一條會隱藏的細線，姑且叫虛擬按鍵吧）。

如圖：可以看到，iPhone X 可以顯示的寬度和 4.7 寸的 iPhone 7 一樣寬，但是，屏幕上下多出來的顯示面積，就會讓這兩者之間的交互出現一些變化。

（ Apple HIG ）

下面我們通過一張 GIF 來看看 iPhone X 的新交互吧。

圖中，我們能夠依次看到的交互是：

返回主屏幕：從底部向上劃動；

多任務：從底部向上滑動並停頓；

呼出控制中心：從屏幕右上角向下劃動；

Siri：長按側邊按鈕；

Apple Pay：連按兩次側邊按鈕。

還有更多的交互，留待我拿到真機以後再慢慢進行體會。屆時再與大家分享。

原文鏈接：https://mp.weixin.qq.com/s?__biz=MzIyNDg5NjI2Mg==&tempkey=xrSEJwRE5kcGdQUGd%2Bfg%3D%3D&chksm=2fa130#rd

D. 淘寶為什麼使用HBase及如何優化的

1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡 迎。對於淘寶而言，隨著市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大 的單一hadoop集群(雲梯)，因此對hadoop系列的產品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。

2 原因
為什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。

但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：

a) 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分布式文件系統，能對TB級甚至PB級別的數據提供在線服務
b) 數據量的增長很快且不一定能准確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統的並發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
d) 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
e) 希望能夠快速讀取批量數據
f ) schema靈活多變，可能經常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java介面

以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數據由hdfs天然地做了數據冗餘，雲梯三年的穩定運行，數據100%可靠 己經證明了hdfs集群的安全性，以及服務於海量數據的能力。其次hbase本身的數據讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長， 達到幾十上百台的規模。LSM-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數據量的增長而 下降。

region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。由於hbase上的數據模型是按rowkey排序存儲的，而讀 取時會一次讀取連續的整塊數據做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數據。最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。

當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單台機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。

3 應用情況
我們從2011年3月開始研究hbase如何用於在線服務。盡管之前在一淘搜索中己經有了幾十節點的離線服務。這是因為hbase早期版本的目標就 是一個海量數據中的離線服務。2009年9月發布的0.20.0版本是一個里程碑，online應用正式成為了hbase的目標，為此hbase引入了 zookeeper來做為backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個里程碑，基本上我們今天 看到的各大網站，如facebook/ebay/yahoo內所使用於生產的hbase都是基於這一個版本(fb所採用的0.89版本結構與0.90.x 相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升。基於此，淘寶也選用了0.90.x分支作為線上版本的基礎。

第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因為數據量持續增大以及需求的變化，因此我們用hbase重構了它 的存儲層。准確的說prom更適合0.92版本的hbase，因為它不僅需要高速的在線讀寫，更需要count/group by等復雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花 半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有 明顯下降，以及數據的准確性，因此得以順利上線。

第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平台，廣泛應用於實時日誌收集、數據實 時監控、廣告效果實時反饋、資料庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance /split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約為此的1.5倍，我們為此准備了20台 regionserver的集群，當然底層的hdfs是公用的，數量更為龐大（下文會提到）。每天TT會為不同的業務在hbase上建不同的表，然後往該 表上寫入數據，即使我們將region的大小上限設為1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鍾都會有數次 split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新 的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來 說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會 單獨強調。TT在預發過程中我們分別因為Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類 似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因 此我們也著手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。

CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸 納為四類原因：網路原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制 力。

和Facebook類似，我們也使用了hbase做為實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系 統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散布到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式 做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是 基於twitter開源的storm進行開發，後台通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將 rowkey設計為url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。

最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關繫到 己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在 服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序 讀。目前該集群存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率為0。

隨著業務的發展，目前我們定製的hbase集群己經應用到了線上超過二十個應用，數百台伺服器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。

4 部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數 個集群，每個集群100台伺服器，擁有一台namenode以及分為5個機架，每個機架上一台zookeeper。可以說對於大數據量的服務這是一種優良 的架構。對於淘寶來說，由於數據量遠沒有那麼大，應用也沒有那麼核心，因此我們採用公用hdfs以及zookeeper集群的架構。每個hdfs集群盡量 不超過100台規模（這是為了盡量限制namenode單點問題）。在其上架設數個hbase集群，每個集群一個master以及一個 backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬碟的成本，因為總有集群對磁碟空間要求高，也總有集群對 磁碟空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個hbase集群在zk上分屬不同的根節點。通過zk的許可權機制來保 證hbase集群的相互獨立。zk的公用原因則僅僅是為了運維方便。

由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。

我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的 展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階 段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過 socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫 程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點匯總和顯示出來，並 且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入資料庫，實現波動報警等自定義的報警。經過以上措 施，保證了我們總是能先於用戶發現集群的問題並及時修復。我們利用redis高效的排序演算法實時地將每個region的讀寫次數進行排序，能夠在高負載的 情況下找到具體請求次數排名較高的那些region，並把它們移到空閑的regionserver上去。在高峰期我們能對上百台機器的數十萬個 region進行實時排序。

為了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。maprece的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。

此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數，盡量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。

我們會每天根蹤所有線上伺服器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。盡管並不是每一次error都會引發問題，甚至大部分error都只是分布式系統中的正常現 象，但明白它們問題的原因是非常重要的。

5 測試與發布
因為是未知的系統，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到准確的結果。因此我們寫了一套自動化 系統，從web上選擇不同的場景，後台會自動將測試參數傳到各台伺服器上去執行。由於是測試分布式系統，因此client也必須是分布式的。

我們判斷測試是否准確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被准確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。

功能測試上則主要是介面測試和異常測試。介面測試一般作用不是很明顯，因為hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受 到了重視和commit。分布式系統設計的難點和復雜度都在異常處理上，我們必須認為系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查 看代碼大體定位到問題以後，在代碼層面強行拋出異常來復現它。事實證明這非常有用。

為了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每台伺服器上抓取相應的日誌並按一定規律匯總。這非常重要，避免浪費大量的時間到登錄不同的伺服器以尋找一個bug的線索。

由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發布模式。它既要避免頻繁的發布引起的不穩定，又要 避免長期不發布導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，並且在release後在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發布，發布時採用最新release的版本， 並且將現有的集群按重要性分級發布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發布機制後，由發布帶來的不穩定因素大大下降 了，並且線上版本也能保持不落後太多。

6 改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們並不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：

https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899

還有其它一些，我們主要將patch提交到0.92版本，社區會有commitor幫助我們backport回0.90版本。所以社區從 0.90.2一直到0.90.6一共發布了5個bugfix版本後，0.90.6版本其實己經比較穩定了。建議生產環境可以考慮這個版本。

split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多台rs上，讀取的時候也會分別讀取，導致數 據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。

前面說到慢響應的問題歸納為網路原因、gc問題、命中率以及client的反序列化問題。網路原因一般是網路不穩定引起的，不過也有可能是tcp參 數設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpmp等一系列工具專門定位過，證明tcp參數 對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數設為1以增加緩存的容量，良好的balance也能幫助充分應用好每台機器的命中率。我們為此設計了表級別的balance。

由於hbase服務是單點的，即宕機一台，則該台機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優 化。首先是將zk的宕機發現時間盡量縮短到1分鍾，其次改進了master恢復日誌為並行恢復，大大提高了master恢復日誌的速度，然後我們修改了 openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鍾甚至半小時無法重啟的問題己經被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。

hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由於hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。

7 將來計劃
我們目前維護著淘寶內基於社區0.90.x而定製的hbase版本。接下來除繼續fix它的bug外，會維護基於0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性並不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一 些特性。

0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現有的HFile在文件大到一定程度時，index會佔用大量的內存，並且載入文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優化，比如改進了balance演算法、改進了compact演算法、改進了scan演算法、compact變為CF級別、動態做ddl等等特性。

除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。

我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化 讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的 hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試 表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集群上的伺服器挪到負載較高的集群中，而整個過程對用戶完全透明。

總的來說，我們的策略是盡量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。

E. 以圓環作為微分元，求球的表面積。

你的第二種貌似不行

書上的是第一種，我喜歡橫切片，其實是一樣的，作圖說明吧

你把橫切片（紅圈和籃圈之間的球面部分）展開鋪平之後就近似於一個長方形，

長為2πr (紅色圓的周長), 高為dl=Rdφ

當然因為dl很小，或者說dφ很小，所以近似把藍色的圓的半徑也看成r，這樣展開的就是一個長方形

不明白可追問

F. 資料庫物理模型

資料庫物理模型設計的目標是根據選定的Oracle資料庫系統特點和航空物探數據管理與服務的業務處理需求，確定航空物探資料庫最優的物理環境、存取方法和存儲結構。即通過資料庫物理設計，以便達到物理資料庫結構的優化，使得在資料庫上運行的各種事務響應時間少、存儲空間利用率高、事務吞吐率大。

一、資料庫布局

航空物探信息系統的維護數據（部門、崗位、人員、人員許可權、數據入庫檢查規則及數據字典等）相對比較穩定。入庫前數據需經過各種檢查校對，確認數據正確後才能歸檔，存入航空物探資料資料庫，所以存入資料庫前的數據可能經常需要修改和刪除，相對變化較大；而存入資料資料庫中的數據一般不允許修改和刪除，以免誤操作破壞資料庫數據造成損失。

圖2-12 航空物探資料庫邏輯模型

圖2-13 航空物探資料庫布局與數據採集流程圖

據此，我們採用圖2-13所示的資料庫數據採集流程，並將航空物探資料庫分為資料採集資料庫、資料資料庫、系統維護資料庫分別進行存儲和管理，實現數據的統一管理和統一使用，便於數據入庫和易於維護等。

航空物探資料資料庫是航空物探所有數據最終存儲的場所。資料採集資料庫是數據歸檔存入資料資料庫前的臨時「集散地」，在此接收各項檢查，在確認數據無誤後歸檔到資料資料庫，然後刪除資料採集資料庫中已歸檔的數據。此外，資料採集資料庫中還保存數據入庫、維護、檢查日誌及歸檔記錄。

系統維護資料庫，存儲系統維護信息（如系統功能、資料庫表清單等）、安全信息（如信息系統用戶的角色、許可權、授權的系統功能等），數據字典、入庫數據檢查規則等。將其與航空物探數據分開，有利於系統維護和管理。

二、資料庫空間設置

資料庫空間設置包括磁碟空間設置、應用系統表空間設置、撤銷表空間、臨時表空間、日誌空間和索引空間設置。

（一）磁碟空間設置

磁碟空間設置的目標：磁碟性能不能阻礙實現資料庫性能，資料庫磁碟必須專用於資料庫文件，否則非資料庫將會影響到資料庫性能，且磁碟空間必須滿足恢復和性能的要求。

航空物探資料庫伺服器為IBM P620小型機，8塊硬碟，每塊硬碟36GB空間，每塊物理磁碟建立一個文件系統。為了提高磁碟的反應時間和尋道時間，提高I/O的存取效率，除了一塊硬碟用於UNIX操作系統外，其餘7塊磁碟分別存放資料採集資料庫、系統維護資料庫-日誌文件，資料資料庫及資料資料庫的大欄位數據、索引、回滾段和數據日誌文件。

（二）應用系統表空間設置

信息系統數據採集過程對數據的事務操作比較頻繁，經常進行數據插入（新數據入庫）、修改（入庫數據有誤）和刪除操作（數據重新導入或歸檔入庫），因此航空物探資料採集資料庫所在的表空間會很活躍。為了不影響其他I/O的競爭，同時也可以提高數據入庫的操作效率（50多年的歷史數據需要集中入庫），分配一個磁碟空間（36GB）為採集庫的表空間。由於採集數據歸檔入資料庫後被刪除，同時進行數據入庫的項目也不是很多，雖仍保留所有的採集日誌數據，一個磁碟空間也足夠使用。

航空物探資料資料庫的二維表和Oracle大欄位（BLOB）分別存放在不同的物理磁碟（每個磁碟36GB）上，對同時存在有表格數據和大欄位數據的資料庫表（如航跡線數據）時，可以提高磁碟I/O效率。隨著數據入庫的項目越來越多，需要增加相應的物理磁碟或磁碟陣列。

系統維護資料庫相對穩定，佔用磁碟空間約500 M左右。由於系統磁碟有限，把日誌文件存放該磁碟中。

（三）撤銷表和臨時表空間的設置

在Oracle資料庫中，撤銷的目的是確保事務的回退和恢復。撤銷參數有UNDO_MANAGEMENT、UNDO_TABLESPACE和UNDO_RETENTION。

UNDO_MANAGEMENT參數用於資料庫中管理撤銷數據的方式，航空物探資料庫設置為自動模式（auto）。

UNDO_TABLESPACE參數用於指定資料庫中保存撤銷數據的撤銷表空間名稱，航空物探資料庫撤銷表空間名稱為UNDO_ARGS_TBSPACE，空間大小設置為20GB，以確保在保留時間內進行恢復。

UNDO_RETENTION參數用於指定已經提交事務的撤銷數據在能夠覆蓋之前應該保留多長時間，本資料庫系統設置為60 min。

臨時表空間是用以存儲大量的排序，與撤銷表空間存放在一個物理磁碟上，本資料庫系統臨時表空間設置為500 M。

（四）日誌空間設置

日誌的主要功能是記錄對資料庫已做過的全部操作。在系統出現故障時，如果不能將修改數據永久地寫入數據文件，則可利用日誌得到該修改，所以不會丟失已有操作結果。

日誌文件主要是保護資料庫以防止故障。為了防止日誌文件本身的故障，航空物探資料庫系統分別在一個獨立磁碟和系統維護庫磁碟中存放日誌文件。若系統出現故障，在下次打開資料庫時Oracle資料庫系統自動用日誌文件中的信息來恢復資料庫文件。

根據航空物探資料庫信息系統同時登錄的用戶數及使用的功能，將日誌文件大小設置為10GB。

（五）索引表空間設置

為了提高航空物探信息系統的查詢和統計速度，把所有索引空間與應用表空間完全分開，從而提高I/O存取效率。航空物探索引表空間大小設置為10GB。

聚集是表的一種存儲方法，一般每個基本表是單獨組織的，但對邏輯上經常在一起查詢的表，在物理上也鄰近存放，這樣可減少數據的搜索時間，提高性能。

當幾個關系（表）以聚集方式組織時，是通過公共屬性的值為表聚集的依據。航空物探資料庫系統是以項目標識（PROJ_ID）建立聚集的，所有涉及項目標識的資料庫表直接引用項目標識聚集。航空物探聚集表空間與索引表空間相同。

三、資料庫參數設置

在資料庫創建前需要對如下資料庫參數進行設置，航空物探參數文件名為Initoraargs.ora，各種參數設置如下：

航空物探信息系統建設

四、內存設置

航空物探資料庫伺服器物理內存為4GB，除部分用於系統開銷外，其餘全部用於資料庫。

Oracle使用共享系統全局區（System Global Area，SGA）內存來管理內存和文件結構，包含DB_block_Buffers、DB_cache_size、Shared_pool_size、Log_Buffer參數。航空物探資料庫系統的全局區內存參數設置如下。

DB_block_Buffers參數為SGA中存儲區高速緩存的緩沖區數目，每個緩沖區的大小等於參數DB_block_size的大小，DB_block_Buffers=19200（約300 MB）。

Shared_pool_size參數為分配給共享SQL區的位元組數，是SGA大小的主要影響者，Shared_pool_size=1228800000（1.2GB）。

DB_cache_size參數是SGA大小和資料庫性能的最重要的決定因素。該值較高，可以提高系統的命中率，減少I/O，DB_cache_size=1024000000（1GB）。

Log_Buffer參數為重做日誌高速緩存大小，主要進行插入、刪除和修改回退操作，Log_buffer=5120000（5MB）。

五、優化設置

由於航空物探信息系統的採集軟體和應用軟體是採用MS.NET C＃進行開發的，應用程序與資料庫之間的連接有傳統的ODBC和OLE DB兩種方式。為了支持ODBC在OLE DB技術上建立了相應的OLE DB到ODBC的調用轉換，而使用直接的OLE DB方式則不需轉換，從而提高處理速度。

在建立資料庫表時，參數Pctfree和Pctused設置不正確可能會導致數據出現行鏈接和行遷移現象，即同一行的數據被保存在不同的數據塊中。在進行數據查詢時，為了讀出這些數據，磁頭必須重新定位，這樣勢必會大大降低資料庫的執行速度。因此，在創建表時應充分估計到將來可能出現的數據變化，正確地設置這兩個參數，盡量減少資料庫中出現的行鏈接和行遷移現象。

航空物探資料採集資料庫表的插入、修改和刪除的頻率較高，Pctfree設置為20，Pctused設置為40；系統維護資料庫表相對穩定，Pctfree設置為10，Pctused設置為15；資料資料庫表除了增加數據外基本不進行修改和刪除操作，Pctfree設置為10，Pctused設置為5。

六、擴展性設置

多CPU和並行查詢PQO（Parallel Query Option）方式的利用：CPU的快速發展使得Oracle越來越重視對多CPU的並行技術的應用，一個資料庫的訪問工作可以用多個CPU相互配合來完成。對於多CPU系統盡量採用並行查詢選項方式進行資料庫操作。航空物探資料庫伺服器為2個CPU，在程序查詢中採用了並行查詢的方式。

在航空物探工作量統計、飛行小時統計、測量面積統計和岩石物性統計中，為了加快統計效率，在相應的查詢語句中增加了並行查詢語句。

隨著航空物探高精度測量程度的不斷提高，測量數據將越來越大。為了滿足航空物探查詢效率及發展，將航磁測量數據與校正後航磁測量數據按比例尺分1∶20 萬以下、20萬～50萬、1∶50萬以上分別存放3張不同的資料庫表。

七、創建資料庫

在完成資料庫布局、空間設置、內存設置、資料庫參數設置、擴展性設置和優化設置後，進行航空物探資料庫物理模型設計，即航空物探資料庫實體創建。由於航空物探空間資料庫邏輯模型是採用ESRI提供的ArcGIS UML構建的Geodatabase模型，因此，使用ESRI公司提供的CaseTools將航空物探數據UML模型圖轉成空間資料庫（Geodatabase）實體（圖2-14）。

航空物探屬性資料庫表（二維表）是採用Power Designer資料庫設計平台直接把資料庫關系模型生成資料庫腳本來創建的。

經過資料庫的概念設計、邏輯設計和物理設計，最終生成航空物探資料庫。

圖2-14 航空物探資料庫物理模型實現

八、空間數據的索引機制

對於海量的空間資料庫而言，資料庫的操作效率是關繫到資料庫成敗的關鍵問題。為了提高數據的訪問、檢索和顯示速度，數據在載入到資料庫時，要素類數據建立了空間索引，柵格數據構建了金字塔結構，對象類數據採用與資料庫直接聯接的訪問機制。

（一）空間索引

為了提高要素類數據的查詢性能，在建立航空物探空間資料庫時，創建了空間索引機制。常用的空間索引有格網索引、R樹索引、四叉樹索引等。Geodatabase採用格網索引方式。所謂格網索引是將空間區域劃分成適合大小的正方形格網，記錄每一個格網內所包含的空間實體（對象）以及每一個實體的封裝邊界范圍，即包圍空間實體的左下角和右上角坐標。當用戶進行空間查詢時，首先計算出用戶查詢對象所在格網，然後通過格網編號，就可以快速檢索到所需的空間實體。

確定適合的格網級數、單元大小是建立空間格網索引的關鍵。格網太大，在一個格網內有多個空間實體，查詢檢索的准確度降低。格網太小，則索引數據量成倍增長和冗餘，檢索的速度和效率較低。資料庫的每一數據層採用不同大小、不同級數的空間索引格網單元，但每層最多級數不能超過三級。格網單元的大小不是一個確定性的值，需要根據對象的大小確定。空間索引格網的大小與檢索准確度之間的關系如圖2-15所示。

選擇格網單元的大小遵循下列基本原則：

1）對於簡單要素的數據層，盡可能選擇單級索引格網。減少RDBMS搜索格網單元索引的級數，縮短空間索引搜索的過程，例如航跡線要素類。

圖2-15 索引格網大小與檢索准確度的關系

2）如果數據層中的要素封裝邊界大小變化比較大，應選擇2或3級索引格網。Geodatabase最多提供三級格網單元。每一要素封裝邊界在適合的級內，減少了每一封裝邊界有多個格網的可能性。在空間索引搜索過程中，RDBMS則必須搜索所有3個格網單元級，這將消耗大量的時間。

3）若用戶經常對圖層執行相同的查詢，最佳格網的大小應是平均查尋空間范圍的1.5倍。

4）格網的大小不能小於要素封裝邊界的平均大小，為了減少每個格網單元有多個要素封裝邊界的可能性，格網單元的大小應取平均格網單元的3倍。最佳格網單元的大小可能受圖層平均查詢的影響。

空間域是按照要素數據集定義的，空間索引格網是按照要素類設置的。它們都是在創建Geodatabase資料庫時設置，並一經設置，中間不許改變；所以一定要在充分分析數據的情況下確定它們的值。航空物探數據主要是簡單要素類，空間跨度為70°。根據上述原則，航空物探數據選擇單級索引格網，格網大小為20°。

（二）金字塔結構

金字塔結構的核心是將柵格數據逐級進行抽稀，形成多級解析度的重采樣數據，並將其分割成塊，按一定的文件格式（金字塔文件格式）存儲成磁碟文件；在以後進行圖像顯示處理時，只需將要顯示的部分所覆蓋的塊從磁碟文件直接讀進內存緩沖區顯示即可。從金字塔的所有層中尋找與所要求顯示的比例相近或匹配的一層，並將該層的從某一點起的一定范圍的圖像所覆蓋的所有塊載入到內存緩沖區，提取所需部分並形成圖像。

金字塔演算法（圖2-16）是通過獲取顯示時所需要的一定解析度的數據來提高顯示速度。使用金字塔數據格式後，在顯示全圖時僅需要顯示一個較低解析度的數據，這樣既能加快顯示速度，又不會影響顯示效果。放大圖像，盡管顯示圖像解析度提高，由於顯示區域減小，所以顯示速度不會下降。如果沒有為柵格數據建立金字塔數據，則每次顯示都會讀取整個數據，然後進行重采樣得到顯示所需要的解析度，明顯地降低了顯示速度。

圖2-16 金字塔壓縮示意圖

金字塔數據重采樣方式有：最近鄰法、雙線性內插和立方卷積。其中最近鄰法適用於離散數據，而雙線性內插法和立方卷積法適合於連續數據。

在ArcGIS Engine中提供了IRasterPyramid和IRasterPyramid2介面來實現金字塔數據的建立，而建立的數據保存在*.rrd格式的文件中。

（三）空間域定義

空間域是指數據的有效空間范圍，即Geodatabase資料庫的最大等效坐標的值域范圍，其定義主要是指比例系數和Min X、Min Y的計算。

因為使用整數比浮點數有更高的壓縮率，並且對整數進行二進制搜索比較快，所以多用戶Geodatabase以4位元組正整數存儲坐標，其最大值為32位正整數所能表示的范圍是21.4億（2147483647），整數的范圍稱為空間域。在創建Geodatabase資料庫時需要定義合適的比例系數。大的整數值將消耗大量的計算機物理內存，所以選定的比例系數最好不要大於必須的比例系數。空間域隨坐標系的單位變化而變化。

比例系數和空間域之間成反比例關系，比例系數越大（存儲單位越小），表達的空間域也越小。為了使目標數據都存儲在系統中，需要謹慎地設置比例系數。將目標數據的寬度和高度較適中的數值乘以比例系數，如果結果小於21.4億，則比例系數是合適的。

航空物探數據模型是為我國的航空物探行業數據建庫設計的，它支持的空間數據的坐標范圍為我國領土覆蓋的海陸空間，最低緯度為赤道。根據概念設計的分析，航空物探數據模型採用的是地理坐標系，坐標系單位是度，基準是Beijing_1954，要求存儲的坐標數據精度達到0.01 m。在赤道處，赤道圓周長為40075694.6 m，則每度弧長=40075694.6×100/360 cm=11132137.389 cm，即1 cm對應8.983000883E-8°。所以，航空物探數據模型的比例系數取為8.98E-8，即存儲單位為8.98E-8°，可滿足1 cm精度要求。

將空間域移動到目標數據范圍之前，首先找到空間域在存儲單位的中心位置，目的是在必要時向各個方向擴展。4位元組正整數可表示的坐標范圍：2147483647×8.98E-8=192.84°。我國的領土范圍是東經70°～140°，北緯0°～60°。所以，選取的比例系數是合適的。把空間域坐標系中心定為90°，然後，計算空間域的Min X、Min Y。

航空物探信息系統建設

航空物探信息系統建設

所以坐標的存儲數據是：

航空物探信息系統建設

航空物探信息系統建設

G. 求用C語言編寫的五子棋，要有棋盤，實現人人，人機，機人對戰，C語言在vc中可以運行的，求高手

/* 純用 字元 和數組編的五子棋，棋盤也是用字元畫的。
編了1上午了，主要是演算法跟按鍵比較煩，發現有bug-- 按鍵速度過快會產生延時顯示，可能是演算法不好。
操作：玩家1： a,s,w,d（方向） 空格（落子）
玩家2： 上、下、左、右 回車 （落子）
ESC： 退出
編譯測試環境：TC3.0
*/
#include <stdio.h>
#include <stdlib.h>
#include <bios.h>
#include <conio.h>

#define CRRU 0xbf /*右上角點 197*/
#define CRLU 0xda /*左上角點 218*/
#define CRLD 0xc0 /*左下角點 192*/
#define CRRD 0xd9 /*右下角點 217*/
#define CRL 0xc3 /*左邊 195*/
#define CRR 0xb4 /*右邊 190*/
#define CRU 0xc2 /*上邊 194*/
#define CRD 0xc1 /*下邊 193*/
#define CR 0xc5 /*十字交叉點 197*/

#define size 19

char a[size][size];
int i,j; //跟蹤游標在數組中對應的位置
int x=10;
int y=3; //游標所在位的坐標
int side=1; //持子方 1為玩家1，2為玩家2；
int CB=1; int CW=2; // 棋子圖形

void inita() ;
void inits();
void pressco(int );
void pressct(int );
int judge(int);

int main(){
inita();
inits();
getch();
while(1){
int press=bioskey(0);
if(press==283)break;
if(side==1){
pressco(press);
if(side==2)if(judge(1)==1) {
gotoxy(1,1);
printf("the play1 win");break;}
}
if(side==2){
pressct(press);
if(side==1)if(judge(2)==1){
gotoxy(1,1);
printf("the play2 win");break;}
}
}
getch();
return 0;
}

void inita() //數組初始化；
{
a[0][0]=CRLU;
a[0][size-1]=CRRU;
a[size-1][0]=CRLD;
a[size-1][size-1]=CRRD;
for(int i=1;i<size-1;i++)
{
a[0][i]=CRU;
a[size-1][i]=CRD;
a[i][0]=CRL;
a[i][size-1]=CRR;
for(int j=1;j<size-1;j++)a[i][j]=CR;
}
return ;
}

void inits() //界面初始化
{
for(int i=0;i<size;i++){
gotoxy(x,y+i);
for(int j=0;j<size;j++)putch(a[i][j]);
}
gotoxy(x,y);
i=0;j=0;
return ;
}

void pressco(int m){
switch(m){
case 7777: //A
if(i>0) {i--;x--;gotoxy(x,y);} break;
case 8051: //S
if(j<size-1){j++;y++;gotoxy(x,y);} break;
case 4471: //w
if(j>0) {j--;y--;gotoxy(x,y);} break;
case 8292: //D
if(i<size-1){i++;x++;gotoxy(x,y);} break;
case 14624: //空格
if(a[i][j]!=CB&&a[i][j]!=CW){a[i][j]=CB;putch(CB);gotoxy(x,y);side=2;}break;
default: break;
}
return ;
}

void pressct(int m){
switch(m){
case 19200: //左
if(i>0) {i--;x--;gotoxy(x,y);} break;
case 20480: //下
if(j<size-1){j++;y++;gotoxy(x,y);} break;
case 18432: //上
if(j>0) {j--;y--;gotoxy(x,y);} break;
case 19712: //右
if(i<size-1){i++;x++;gotoxy(x,y);} break;
case 7181: //回車
if(a[i][j]!=CB&&a[i][j]!=CW){a[i][j]=CW;putch(CW);gotoxy(x,y);side=1;}break;
default: break;
}

return ;
}

int judge(int pa) //判斷是否勝利，勝利則返回 1，否則返回0；
// 其中i,j為當前的落子位；
{
int m;
int sum=1;
for(m=1;m<=i&&m<=j;m++) {if(a[i-m][j-m]!=pa) break;sum++;}
for(m=1;m<(size-i)&&m<(size-j);m++) {if(a[i+m][j+m]!=pa) break;sum++;}
if(sum>=5) return 1;
else sum=1;
for(m=1;m<=i;m++) {if(a[i-m][j]!=pa) break;sum++;}
for(m=1;m<(size-j);m++) {if(a[i+m][j]!=pa) break;sum++;}
if(sum>=5) return 1;
else sum=1;
for(m=1;m<=j;m++) {if(a[i][j-m]!=pa) break;sum++;}
for(m=1;m<(size-j);m++) {if(a[i][j+m]!=pa) break;sum++;}
if(sum>=5) return 1;
else sum=1;
for(m=1;m<=i&&m<(size-j);m++) {if(a[i-m][j+m]!=pa) break;sum++;}
for(m=1;m<(size-i)&&m<=j;m++) {if(a[i+m][j-m]!=pa) break;sum++;}
if(sum>=5) return 1;
else return 0;
}

H. 那位朋友能告訴我一個免費下載《演算法分析與設計》課件的網址

地址一：
http://g1a129.mail.163.com/a/s/%E7%AE%97%E6%B3%95%E5%88%86%E6%9E%90%E4%B8%8E%E8%AE%BE%E8%AE%A1%E8%AF%BE%E4%BB%B6.rar?func=mbox:getMessageData&sid=&mid=1tbishRA60NvOH8zOwAAsu&part=3&mode=download

地址二：
http://g1a115.mail.163.com/a/s/綆楁硶鍒嗘瀽涓庤�璁¤�浠訛紞1.rar?func=mbox:getMessageData&sid=&mid=1tbiyRtfGEQz6y5PFAAAs8&part=3&mode=download

http://g1a115.mail.163.com/a/s/綆楁硶鍒嗘瀽涓庤�璁¤�浠訛紞2.rar?func=mbox:getMessageData&sid=&mid=1tbiyRtfGEQz6y5PFAAAs8&part=4&mode=download

如果有其他問題的可以發送郵件給我：[email protected]

I. 什麼是踏面斜率

踏面斜率的概念來自輪對的蛇形運動,它反映了輪對幾何蛇形運動的波長.等效斜率通常根據左、右車輪滾動半徑差隨輪對橫移量變化的函數(RRD函數)計算得到.介紹了幾種根據RRD函數計算踏面等效斜率的原理和公式,包括UIC 519積分法、簡諧線性法、以及概率法等.通過算例比較了等效斜率各種演算法之間的差異,並與時域模擬的結果進行了對比.

J. 如何實現Java udp超時重傳機制（類似tcp那樣）

對一個連接而言，若能夠了解端點間的傳輸往返時間（RTT，Round Trip Time），則可根據RTT來設置一合適的RTO。顯然，在任何時刻連接的RTT都是隨機的，無法事先預知。TCP通過測量來獲得連接當前RTT的一個估計值，並以該RTT估計值為基準來設置當前的RTO。自適應重傳演算法的關鍵就在於對當前RTT的准確估計，以便適時調整RTO。

為了搜集足夠的數據來精確地估算當前的RTT，TCP對每個報文都記錄下發送出的時間和收到的確認時間。每一個（發送時間，確認時間）對就可以計算出一個RTT測量值的樣本（Sample RTT）。TCP為每一個活動的連接都維護一個當前的RTT估計值。該值是對已經過去的一個時間段內該連接的RTT了兩只的加權平均，並作為TCP對連接當前實際的RTT值的一種估計。RTT估計值將在發送報文段時被用於確定報文段的RTO。為了保證它能夠比較准確地反應當前的網路狀態，每當TCP通過測量獲得了個新的RTT樣本時，都將對RTT的估計值進行更新。不同的更新演算法或參數可能獲得不同的特性。

最早的TCP曾經用了一個非常簡單的公式來估計當前網路的狀況，如下
R<-aR+(1-a)MRTP=Rb其中a是一個經驗系數為0.1，b通常為2。注意，這是經驗，沒有推導過程，這個數值是可以被修改的。這個公式是說用舊的RTT(R)和新的RTT (M)綜合到一起來考慮新的RTT(R)的大小。但又可以看到，這種估計在網路變化很大的情況下完全不能做出「靈敏的反應」，於是就有下面的修正公式：

Err=M-AA<-A+gErrD<-D+h(|Err|-D)RTO=A+4D，這個遞推公式甚至把方差這種統計概念也使用了進來，使得偏差更加的小。而且，必須要指出的是，這兩組公式更新，都是在 數據成功傳輸的情況下才進行，在發生數據重新傳輸的情況下，並不使用上面的公式進行網路估計，理由很簡單，因為程序已經不在正常狀態下了，估計出來的數據 也是沒有意義的。