數(shù)據(jù)庫高并發(fā)升級方案

XXXXXXXXXXXX平臺數(shù)據(jù)庫升級方案XXXXXXXXXXXXXXX有限公司2016年11月28日

修訂記錄版本說明作者批準(zhǔn)批準(zhǔn)日期V1.0對升級方案進行編制XXXX2016年12月1日1TOC\o"1-5"\h\z\o"CurrentDocument"概述 4\o"CurrentDocument"概述 4\o"CurrentDocument"背景 4\o"CurrentDocument"目標(biāo)與目的 .4\o"CurrentDocument"可行性分析 4\o"CurrentDocument"參考依據(jù) 5\o"CurrentDocument"數(shù)據(jù)庫高并發(fā)方案 5\o"CurrentDocument"數(shù)據(jù)庫均衡負(fù)載(RAC) 5\o"CurrentDocument"數(shù)據(jù)庫主從部署 8\o"CurrentDocument"數(shù)據(jù)庫垂直分割 9\o"CurrentDocument"數(shù)據(jù)庫水平分割 10\o"CurrentDocument"數(shù)據(jù)庫優(yōu)化設(shè)計 11\o"CurrentDocument"數(shù)據(jù)庫集群 11\o"CurrentDocument"重點業(yè)務(wù)表分區(qū) 11\o"CurrentDocument"任務(wù)表歷史數(shù)據(jù)分割 12\o"CurrentDocument"數(shù)據(jù)庫表結(jié)構(gòu)優(yōu)化 12\o"CurrentDocument"數(shù)據(jù)訪問優(yōu)化 12\o"CurrentDocument"實施方案 13\o"CurrentDocument"工作量及預(yù)算評估 14工作量及預(yù)算評估 14其他費用 151.概述背景隨著XXXXXX平臺及其他子系統(tǒng)業(yè)務(wù)量增多，且用戶已面向各地州市，用戶數(shù)量增大，現(xiàn)有的二代辦公平臺及其他子系統(tǒng)在單一環(huán)境下的架構(gòu)體系和數(shù)據(jù)庫架構(gòu)體系也無法高效的知足如此的場景。當(dāng)前XXXXXX平臺及其子系統(tǒng)通過搭建多臺WEB服務(wù)器和雙機熱備份的方式進行部署運行。雖已提高了整體效率，但對于部份的業(yè)務(wù)處置仍是未解決。部份業(yè)務(wù)量并發(fā)處置多，業(yè)務(wù)關(guān)聯(lián)多等因素，致使對數(shù)據(jù)庫并發(fā)處置的業(yè)務(wù)量大，讀寫量大等也無法用雙機熱備份進行解決。因此，在此背景下提高數(shù)據(jù)庫訪問效率，增大訪問吞吐量等將成為二代辦公平臺及其子系統(tǒng)運行順暢的關(guān)鍵因素。目標(biāo)與目的目標(biāo)：依托現(xiàn)有系統(tǒng)服務(wù)和設(shè)備環(huán)境，成立可擴容、高并發(fā)、高吞吐量的數(shù)據(jù)庫架構(gòu)體系。目的：為減緩當(dāng)前XXXXXX平臺機械及其他子系統(tǒng)對數(shù)據(jù)庫訪問過大，造成的訪問效率低下的問題，提升數(shù)據(jù)庫訪問效率和并發(fā)效率。對部份業(yè)務(wù)繁雜的表和訪問進行優(yōu)化設(shè)計，減緩因此造成的利用效率低下問題?？尚行苑治鰯?shù)據(jù)庫性能分析：按照當(dāng)前的數(shù)據(jù)庫性能分析，當(dāng)前硬件設(shè)備的提高也無法知足數(shù)據(jù)庫性能的提升，因此應(yīng)考慮數(shù)據(jù)庫訪問控制和數(shù)據(jù)訪問方面進行優(yōu)化。現(xiàn)有的數(shù)據(jù)庫雖也實現(xiàn)雙機熱備份，但訪問的效率未較大改善，因此應(yīng)考慮各健全的數(shù)據(jù)庫高并發(fā)訪問方案。數(shù)據(jù)庫優(yōu)化分析：當(dāng)前的數(shù)據(jù)庫采用的ORACLE數(shù)據(jù)庫，同時，現(xiàn)有的均衡負(fù)載、讀寫分離、數(shù)據(jù)分割技術(shù)較為成熟，在對系統(tǒng)進行適當(dāng)調(diào)整和優(yōu)化的情形下，能保證系統(tǒng)的正常運行。參考依據(jù)《OracleRAC核心技術(shù)詳解》數(shù)據(jù)庫高并發(fā)方案數(shù)據(jù)庫均衡負(fù)載(RAC)RAC，全稱realapplicationclusters，譯為“實時應(yīng)用集群”，是Oracle新版數(shù)據(jù)庫中采用的一項新技術(shù)，是高可用性的一種，也是支持環(huán)境的核心技術(shù)。OracleRAC主要支持Oracle9i、10g、11g版本，能夠支持24x7有效的，在低本錢上構(gòu)建高可用性，而且自由部署應(yīng)用，無需修改代碼。在OracleRAC環(huán)境下，Oracle集成提供了軟件和存儲管理軟件，為用戶降低了應(yīng)用本錢。當(dāng)應(yīng)用規(guī)模需要擴充時，用戶能夠按需擴展系統(tǒng)，以保證系統(tǒng)的性能。RAC是一種并行模式，并非是傳統(tǒng)的主備模式。也就是說，RAC集群的所有成員都能夠同時接收客戶端的請求。RAC具有以下特點：雙機并行：RAC是一種充分利用服務(wù)器資源的高可用性實現(xiàn)方案，RAC的并行模式實現(xiàn)方式與傳統(tǒng)的雙機熱備實現(xiàn)方式截然不同，圖1-1是二者的比較。如圖1-1所示，兩個節(jié)點在傳統(tǒng)的雙機熱備環(huán)境中，始終有一臺機械作為備用機，只有當(dāng)主節(jié)點出現(xiàn)問題的時候才會切換到備用機上;若是主機一直沒有出現(xiàn)問題，那么備用機始終處于空閑狀態(tài)，這在資源的利用上和本錢方面都是龐大的浪費。但RAC是一種并行模式的架構(gòu)，也就是說，兩個節(jié)點的集群節(jié)點間是一種并行運行的關(guān)系，當(dāng)一臺機械出現(xiàn)問題，請求會自動轉(zhuǎn)發(fā)到另一臺機械，沒有任何一臺機械作為備用機一直不被利用，如此就充分利用了服務(wù)器資源。同時，傳統(tǒng)的雙機熱備構(gòu)架在出現(xiàn)問題時，常常需要數(shù)分鐘的切換時刻，而RAC在出現(xiàn)問題時，針對存在的會話只需要數(shù)十秒的時刻就可以夠完成失敗切換進程，對新會話的創(chuàng)建不會產(chǎn)生影響，在切換時刻上也有比較大的優(yōu)勢。

哭敗切換▲圖1-1雙機熱備與哭敗切換▲圖1-1雙機熱備與RAC并行模式對比共享存儲雙機熱備共享存儲RAC高可用性：RAC是Oracle數(shù)據(jù)庫高可用性解決方案。高可用性包括兩部份的內(nèi)容：第一是在這種解決方案下要確保數(shù)據(jù)不丟失，這是最基礎(chǔ)的也是必需要保證的;第二是確保不斷機，使Oracle數(shù)據(jù)庫一直維持在正常的運行狀態(tài)，避免停機給客戶帶來的損失，這是討論最多的內(nèi)容。停機一般分為兩類，計劃停機和非計劃停機。所謂計劃停機是有計劃地安排節(jié)點或系統(tǒng)的停機，一般在Oracle升級、系統(tǒng)保護或硬件保護的情形下會出現(xiàn)。非計劃停機就是在非人為計劃的情形下突然停機，這種情形一般是在Oraclebug、系統(tǒng)故障、硬件故障或人為操作失敗的時候出現(xiàn)。在沒有較高花費的情形下，想實現(xiàn)系統(tǒng)100%的不斷機幾乎是不可能的。表1-1列出了特定百分比高可用性比率運行停機的時刻，詳細(xì)記錄了每種高可用性比率每一年、每一個月、每周能夠出現(xiàn)最大的停機時刻。囊1-1悻京百分比岬r用性比率運物機劄時間莽年停瑚何母周承間必天1皿天Mr卜阡Wd期實熟7翌天LJ時刮1M則乳球7.楠小時1燦湖引泓L-E供5網(wǎng)小射50.4^#n牯孔垮神30k盼香外W($啊3一網(wǎng)倒10L*|>分■棘Z如凡個?}既4玷仲L(H分牌網(wǎng)一鱷必(54^}睇麗5秒&&凝如55?個9}4”秒2.!^通常情形下，以每一個月停機時刻來計算對應(yīng)的可用性比率。按照系統(tǒng)的重要性情形，應(yīng)該為系統(tǒng)設(shè)定合理的可用性比率。集群最大的優(yōu)勢在于它的高可用性，通過利用RAC能夠在必然程度上避免因為硬件或軟件故障引發(fā)的數(shù)據(jù)丟失和非計劃停機，并在必然程度上減少或排除計劃停機時刻。這是很多客戶選擇RAC的最直接原因。RAC中包括了超級多的高可用特性，主要包括如下幾點：?實現(xiàn)節(jié)點間的負(fù)載均衡。?實現(xiàn)失敗切換的功能。?通過Service組件來控制客戶端的訪問路徑。?集群軟件能夠自動化管理各個資源，而且有按時的節(jié)點狀態(tài)檢測機制，能自動對一些失敗的進程和心跳檢測失敗的節(jié)點進行重啟，使其從頭恢復(fù)到正常的運行狀態(tài)。在Oracle11gR2版本中，Clusterware取得了改善，提供了更高的可用性。例如，大量新的基于代理的監(jiān)控系統(tǒng)用于監(jiān)控所有的資源。這些代理利用更少的資源執(zhí)行更頻繁的檢查，即更快速的失敗掃描和更短的恢復(fù)時刻。在Oracle監(jiān)聽的例子中，平均失敗掃描時刻從5分鐘減少到30秒，同時，檢查距離從每10分鐘減少到1分鐘。另外，Clusterware的“Out-of-PlaceUpgrade"等特性也減少了軟件保護需要的停機時刻。易伸縮性：RAC為需要從頭計劃的應(yīng)用提供了易擴展性。為了在系統(tǒng)初始階段維持較低的本錢，避免造成沒必要要的浪費，集群能夠依照標(biāo)準(zhǔn)硬件配置，選擇適當(dāng)?shù)姆?wù)器資源、存儲資源來搭建數(shù)據(jù)庫環(huán)境。當(dāng)系統(tǒng)需要更多的處置能力或需要增加存儲時，通過添加另一臺服務(wù)器或存儲設(shè)備到集群中，能夠在不斷機的情形下取得水平的擴展。在一個集群中，Clusterware和RAC支持多達100個集群節(jié)點。當(dāng)某個集群的處置能力多余，另一個集群的處置能力不夠時，能夠從處置能力多余的集群移動一個節(jié)點處處置能力不夠的集群中。如此能夠充分利用服務(wù)器資源，節(jié)約本錢。11gR2版本中推出了網(wǎng)格即插即用(GridPlugandPlay，GPnP)，能夠?qū)崿F(xiàn)節(jié)點的快速添加。低本錢：通過量臺普通的PC服務(wù)器組成一個集群，能夠提高集群的處置能力，如此要比采用一臺高性能的服務(wù)器的本錢低很多。若是想提高系統(tǒng)的處置能力，給集群添加節(jié)點比為高性能服務(wù)器添加硬件要容易患多。另外，利用集群還能動態(tài)地移除節(jié)點，加倍充分地利用管理者掌握的所有服務(wù)器資源，從服務(wù)器整體利用上降低了服務(wù)器的采購本錢。愈來愈多的企業(yè)愿意將集群解決方案應(yīng)用到他們的系統(tǒng)中，以降低本錢，提高系統(tǒng)的可用性。高吞吐量：RAC是由多臺服務(wù)器組成的邏輯主體，比單臺數(shù)據(jù)庫服務(wù)器能接收更多的客戶端請求。這在要求高吞吐量的系統(tǒng)中，能夠取得超級明顯的表現(xiàn)。在RAC的架構(gòu)中，多個實例散布在多個服務(wù)器上，能同時打開同一個數(shù)據(jù)庫，而每一個實例能夠接收相等數(shù)量的客戶端請求，如此，隨著服務(wù)器的增加，吞吐量也在不斷地增加。數(shù)據(jù)庫主從部署主從復(fù)制：幾乎所有的主流數(shù)據(jù)庫都支持復(fù)制，這是進行數(shù)據(jù)庫簡單擴展的大體手腕。Oracle的主從復(fù)制可采用DataGuarc技術(shù)DataGuard是Oracle數(shù)據(jù)庫自帶的數(shù)據(jù)同步功能，大體原理是將日記文件從原數(shù)據(jù)庫傳輸?shù)侥繕?biāo)數(shù)據(jù)庫，然后在目標(biāo)數(shù)據(jù)庫上應(yīng)用(Apply)這些日記文件，從而使目標(biāo)數(shù)據(jù)庫與源數(shù)據(jù)庫維持同步。DataGuard提供了三種日記傳輸(RedoTransport)方式，別離是ARCH傳輸、LGWR同步傳輸和LGWR異步傳輸。在上述三種日記傳輸方式的基礎(chǔ)上，提供了三種數(shù)據(jù)保護模式，即最大性能(MaximumPerformanceMode)、最大保護(MaximumProtectionMode)和最大可用(MaximumAvailabilityMode)，

其中最大保護模式和最大可用模式要求日記傳輸必需用LGWR同步傳輸方式，最大性能模式下可用任何一種日記傳輸方式。讀寫分離：讀寫分離是架構(gòu)散布式系統(tǒng)的一個重要思想。很多系統(tǒng)整體處置能力并非能同業(yè)務(wù)的增加維持同步，因此必將會帶來瓶頸，單純的升級硬件并非能一勞永逸。針對業(yè)務(wù)類型特點，需要從架構(gòu)模式上進行一系列的調(diào)整，比如業(yè)務(wù)模塊的分割，數(shù)據(jù)庫的拆分等等。/格讀* 分寓后，可以把查珂援ft■色缺于詼著環(huán)/格讀* 分寓后，可以把查珂援ft■色缺于詼著環(huán)itORACLZIIMj韋生產(chǎn)坪境IBM蟲知HL.?」牌數(shù)據(jù)庫垂直分割主從部署數(shù)據(jù)庫中，當(dāng)寫操作占了主數(shù)據(jù)庫的CPU消耗的50%以上的時候，咱們再增加從服務(wù)器的意義就不是專門大了，因為所有的從服務(wù)器的寫操作也將占到CPU消耗的50%以上，一臺從服務(wù)器提供出來查詢的資源超級有限。數(shù)據(jù)庫就需要從頭架構(gòu)了，咱們需要采用數(shù)據(jù)庫垂直分區(qū)技術(shù)啦。最簡單的垂直分區(qū)方式是將原來的數(shù)據(jù)庫中獨立的業(yè)務(wù)進行分拆（被分拆出來的部份與其它部份不需要進行Join連接查詢操作），比如WEB站點的BLOG和論壇，是相對獨立的，與其它的數(shù)據(jù)的關(guān)聯(lián)性不是很強，這時能夠?qū)⒃瓉淼臄?shù)據(jù)庫拆分為一個BLog庫，一個論壇庫，和剩余的表所組成的庫。這三個庫再各行其是主從數(shù)據(jù)庫方式部署，如此整個數(shù)據(jù)庫的壓力就分擔(dān)啦。另外查詢擴展性也是采用數(shù)據(jù)庫分區(qū)最主要的原因之一。將一個大的數(shù)據(jù)庫分成多個小的數(shù)據(jù)庫能夠提高查詢的性能，因為每一個數(shù)據(jù)庫分區(qū)擁有自己的一小部份數(shù)據(jù)。假設(shè)您想掃描1億條記錄，對一個單一分區(qū)的數(shù)據(jù)庫來講，該掃描操作需要數(shù)據(jù)庫管理器獨立掃描一億條記錄，若是您將數(shù)據(jù)庫系統(tǒng)做成50個分區(qū)，并將這1億條記錄平均分派到這50個分區(qū)上，那么每一個數(shù)據(jù)庫分區(qū)的數(shù)據(jù)庫管理器將只掃描200萬記錄。數(shù)據(jù)庫水平分割在數(shù)據(jù)庫的垂直分區(qū)以后，假設(shè)咱們的BLOG庫又再次無法承擔(dān)寫操作的時候，咱們又該怎么辦呢？數(shù)據(jù)庫垂直分區(qū)這種擴展方式又無能為力了，咱們需要的是水平分區(qū)。水平分區(qū)意味著咱們能夠?qū)⑼粋€數(shù)據(jù)庫表中的記錄通過特定的算法進行分離，別離保留在不同的數(shù)據(jù)庫表中，從而能夠部署在不同的數(shù)據(jù)庫服務(wù)器上。很多的大規(guī)模的站點大體上都是主從復(fù)制+垂直分區(qū)+水平分區(qū)如此的架構(gòu)。水平分區(qū)并非依賴什么特定的技術(shù)，完盡是邏輯層面的計劃，需要的是經(jīng)驗和業(yè)務(wù)的細(xì)分。如何分區(qū)呢？對于大型的WEB站點來講，必需分區(qū)，而且對于分區(qū)咱們沒有選擇的余地，對于那些頻繁訪問致使站點接近崩潰的熱點數(shù)據(jù)，咱們必需分區(qū)。在對數(shù)據(jù)分區(qū)的時候，咱們必需要存在一個分區(qū)索引字段，比如USER_ID，它必需和所有的記錄都存在關(guān)系，是分區(qū)數(shù)據(jù)庫中的核心表的主鍵，在其它表中作為外鍵，而且在利用主鍵的時候，該主鍵不能是自增加的，必需是業(yè)務(wù)主鍵才能夠。余數(shù)分區(qū)：咱們能夠?qū)ser_ID%10后的值為依據(jù)存入到不同的分區(qū)數(shù)據(jù)庫中，該算法簡單高效，可是在分區(qū)數(shù)據(jù)庫個數(shù)有變更的時候，整個系統(tǒng)的數(shù)據(jù)需要從頭散布。范圍分區(qū)：咱們能夠?qū)ser_ID的范圍進行分區(qū)，比如1-100000范圍為一個分區(qū)數(shù)據(jù)庫，100001-200000范圍為一個分區(qū)數(shù)據(jù)庫，該算法在分區(qū)數(shù)據(jù)庫個數(shù)有變更的時候，系統(tǒng)超級有利于擴展，可是容易致使不同分區(qū)之間的壓力不同，比如老用戶所在的分區(qū)數(shù)據(jù)庫的壓力專門大，可是新用戶的分區(qū)數(shù)據(jù)庫的壓力偏小。映射關(guān)系分區(qū)：將對分區(qū)索引字段的每一個可能的結(jié)果創(chuàng)建一個分區(qū)映射關(guān)系，那個映射關(guān)系超級龐大，需要將它們寫入數(shù)據(jù)庫中。比如當(dāng)應(yīng)用程序需要明白User_id為10的用戶的BLOG內(nèi)容在那個分區(qū)時，它必需查詢數(shù)據(jù)庫獲取答案，固然，咱們能夠利用緩存來提高性能。這種方式詳細(xì)保留了每一個記錄的分區(qū)對應(yīng)關(guān)系，所以各個分區(qū)有超級強的可伸縮性，能夠靈活的控制，而且將數(shù)據(jù)庫從一個分區(qū)遷移到另一個分區(qū)也很簡單，也能夠使各個分區(qū)通過靈活的動態(tài)調(diào)節(jié)來維持壓力的散布平衡。數(shù)據(jù)庫優(yōu)化設(shè)計數(shù)據(jù)庫集群數(shù)據(jù)庫集群高可用的方案主要有三種：RAC、DataGuard、MAA。其中：RAC在多個Oracle服務(wù)器組成一個共享的Cache，而這些Oracle服務(wù)器共享一個基于網(wǎng)絡(luò)的存儲。那個系統(tǒng)能夠容忍單機/或是多機失敗。不過系統(tǒng)內(nèi)部的多個節(jié)點需要高速網(wǎng)絡(luò)互連，大體上也就是要全數(shù)東西放在在一個機房內(nèi)，或說一個數(shù)據(jù)中心內(nèi)。DataGuard那個方案就適合多機房的。某機房一個production的數(shù)據(jù)庫，另外其他機房部署standby的數(shù)據(jù)庫。Standby數(shù)據(jù)庫分物理的和邏輯的。物理的standby數(shù)據(jù)庫主要用于production失敗后做切換。而邏輯的standby數(shù)據(jù)庫則在平時能夠分擔(dān)production數(shù)據(jù)庫的讀負(fù)載。MAA(MaximumAvailabilityArchitecture)其實不是獨立的第三種，而是前面兩種的結(jié)合，來提供最高的可用性。重點業(yè)務(wù)表分區(qū)當(dāng)表中的數(shù)據(jù)量不斷增大，查詢數(shù)據(jù)的速度就會變慢，應(yīng)用程序的性能就會下降，這時就應(yīng)該考慮對表進行分區(qū)。表進行分區(qū)后，邏輯上表仍然是一張完整的表，只是將表中的數(shù)據(jù)在物理上寄存到多個表空間(物理文件上)，如此查詢數(shù)據(jù)時，不至于每次都掃描整張表。表分區(qū)的類型及操作方式主要包括范圍分區(qū)、列表分區(qū)、散列分區(qū)等，其中:范圍分區(qū)將數(shù)據(jù)基于范圍映射到每一個分區(qū)，那個范圍是你在創(chuàng)建分區(qū)時指定的分區(qū)鍵決定的。這種分區(qū)方式是最為常常利用的，而且分區(qū)鍵常常采用日期。列表分區(qū)的特點是某列的值只有幾個，基于如此的特點咱們能夠采用列表分區(qū)，比如地域。散列分區(qū)是在列值上利用散列算法，以肯定將行放入哪個分區(qū)中。當(dāng)列的值沒有適合的條件時，建議利用散列分區(qū)。散列分區(qū)為通過指定分區(qū)編號來均勻散布數(shù)據(jù)的一種分區(qū)類型，因為通過在I/O設(shè)備上進行散列分區(qū)，使得這些分區(qū)大小一致。任務(wù)表歷史數(shù)據(jù)分割現(xiàn)有的任務(wù)表SA_TASK任務(wù)繁重，數(shù)據(jù)冗余，大體上的流程操作都在該表，二代辦公開發(fā)平臺（x5）以對此也進行了升級優(yōu)化，就是將任務(wù)表已完結(jié)的歷史數(shù)據(jù)單獨寄存，縮小任務(wù)表的數(shù)據(jù)量，提高查詢的效率。正在辦理的任務(wù)數(shù)據(jù)寄存與SA_TASK表中，辦理辦結(jié)后則清除并寄存于SA_TASK_HISTORY（歷史表）中。如此SA_TASK中只有正在辦理的數(shù)據(jù)，將大大降低數(shù)據(jù)冗余的情形，同時提高SA_TASK表的讀寫能力。而查詢經(jīng)辦文件時可查詢SA_TASK_HISTORY（歷史表），與頻繁操作的SA_TASK區(qū)分開更易讀取。數(shù)據(jù)庫表結(jié)構(gòu)優(yōu)化隨著省廳的業(yè)務(wù)量增大，最初的結(jié)構(gòu)設(shè)計和調(diào)整使數(shù)據(jù)庫表結(jié)構(gòu)變得冗余，存在部份非表主要的屬性，同時業(yè)務(wù)表結(jié)構(gòu)過大，單條數(shù)據(jù)的字節(jié)數(shù)已超過1萬多字節(jié)，因此在查詢進程中也會