驚喜與局限並存,12c Sharding內測報告搶先看!
2017年3月,我們終於迎來了Oracle 12cR2,作為國內首批Beta測試用戶,我們在2016年1月應邀進行Oracle 12c Sharding 技術測試,並於去年10月完成了12cR2 Sharding 預研報告。由於受Oracle新技術發布限製,直至今日才發布與各位分享。
一、Oracle 12c Sharding簡介
在Oracle 12cR2之前的版本中, Oracle分區表的所有分區都是在一套數據庫中,而Sharding技術,則是使用新的分片技術可以將不同的分區部署到不同的數據庫(後麵稱之為分片節點),而這些數據庫都是相互獨立且沒有地理位置的限製。Oracle宣稱這種分片架構具有以下特性:
-
支持數據水平分片,支持數據海量擴展
-
支持按地理分布、內網部署、公有雲或混合雲部署方案
-
支持全麵故障隔離
-
每個分片節點具有獨立的硬件資源(CPU、內存、硬盤等)
-
支持彈性擴展和自動重分布(Auto Rebalancing)
-
自動部署(Auto deployment)
二、Oracle 12c Sharding體係結構
Oracle sharding技術下的sdb架構(shared database architecture),包括:shard Directors(分片路由器GSM)、shard catalog(分片目錄庫)、shardgroup(分片組)。
1. shard catalog目錄庫主要作用
-
存儲sdb的元數據
-
協調數據庫
-
分片表的元數據定義和複製表存儲
2. Shard director分片導向器主要作用
-
提供從應用層到分片連接請求的路由導向
-
跨數據庫服務故障切換和管理
-
連接時負載均衡
3. Oracle Routing(兩種模式)
-
session-based Routing
所有的事務都隻連接到一個單一的shard進行操作。
-
Cross-shard 模式
適用於報表類的查詢
事務需要跨多個shard執行操作
4. Sdb模式下oracle的連接請求方式分為兩種
-
ucp:帶shard key的連接請求,sdb數據庫是依據shard key來劃分shard的,當我們使用shard key進行操作的時候,連接池會將該鏈接請求發送到正確的shard庫中並建立鏈接。
-
如果沒有sharding key,sdb會將連接請求交給catalog庫,它會將目標sql解析並路由請求到正確的shard庫。
三、Oracle 12c Sharding測試環境搭建部署步驟
環境準備:測試環境使用三台虛擬機進行測試,分別為:shard0(GSM和shardcate),shard1(sh1),shard2(sh2)。
軟件要求:12.2.0.0.3及以上版本。
1. GSM軟件部署
第一步修改環境變量如下:
[oracle@shard0 ~]$ env |grep ORA ORACLE_BASE=/u01/app/oracle ORACLE_HOME=/u01/app/oracle/product/12.2.0/gsmhome_1 |
第二步解壓縮GSM.zip包並且執行runInstaller腳本(這裏使用了圖形化界麵)
直接點下一步(檢查操作係統是否符合安裝條件):
點next下一步:
點擊install,這樣GSM包就安裝完成了。
後續的數據庫軟件安裝就不展開介紹了,選擇NO-CDB選項即可。其他均與之前版本沒有任何區別。
2. shardcate庫上用戶及相關權限操作
ssh shard0 su – oracle sqlplus / as sysdba alter user gsmcatuser account unlock; --解鎖gsm用戶 alter user gsmcatuser identified by passwd_gsmcatuser; --修改gsm用戶密碼 create user mygdsadmin identified by passwd_mygdsadmin; --創建管理用戶mygdsadmin grant connect, create session to mygdsadmin;--賦權限給mygdsadmin grant gsmadmin_role to mygdsadmin;--把gsm管理員角色賦予mygdsadmin grant inherit privileges on user SYS to GSMADMIN_INTERNAL; |
3. shardcate上配置remote scheduler
ssh shard0 su - oralce sqlplus / as sysdba set echo on set termout on set time on spool /u01/stage/labs/config_remote_scheduler.lst --設置配置輸出的日誌 execute dbms_xdb.sethttpport(8080);--指定scheduler所使用的端口號 Commit; @?/rdbms/admin/prvtrsch.plb exec DBMS_SCHEDULER.SET_AGENT_REGISTRATION_PASS('welcome'); --設置遠程shard節點注冊到shardcate庫所需的密碼 spool off |
4. 分片庫信息注冊
ssh shard1 su – oracle schagent –stop --停止shard庫上的守護進程 schagent –start --停止shard庫上的守護進程 schagent –status –查看shard庫上的守護進程的狀態 echo welcome |schagent -registerdatabase shard0 8080 –注冊到遠程shardcate庫分別是密碼、主機名、端口號 cd /data/oracle mkdir oradata –創建shard庫的數據文件存放位置 mkdir fast_recovery_area --創建shard庫的快速恢複區的位置 |
ssh shard2 su – oracle schagent -stop schagent -start schagent -status echo welcome |schagent -registerdatabase shard0 8080 cd /data/oracle mkdir oradata mkdir fast_recovery_area |
5. 配置GSM
ssh shard0 su – oracle --oracle用戶 gdsctl --進入gsm交互界麵 create shardcatalog -database shard0:1521:orcl -chunks 12 -user mygdsadmin/passwd_mygdsadmin -sdb cust_sdb -region region1 --創建shardcatalog庫 –database ip(主機名):監聽端口號:實例名 –chunks chunk的數量 -user 用戶/密碼 –sdb sdb名 –region 主端,備端 add gsm -gsm sharddirector1 -listener 1571 -pwd passwd_gsmcatuser -catalog shard0:1521:orcl –region -trace_level 16 --添加gsm –gsm gsm名 –listener 監聽端口號 –pwd gsmcatuser用戶密碼 –catalog catalog庫基本信息 ip(主機名):監聽端口號:實例名 –region 指定是哪個region –trace_level 指定trace的級別位置LOG_DESTINATION參數控製 start gsm -gsm sharddirector1 –啟動gsm set _event 17 modify catalog -agent_password welcome –修改 catalog庫守護進程密碼為welcome add credential -credential oracle_cred -osaccount oracle -ospassword oracle -- specify the operating system user that the extproc agent impersonates when running a subprogram stored in the library ssh shard0 su – oracle gdsctl –進入gsm命令交互模式 set gsm -gsm sharddirector1 –設置當前分片目錄為sharddirector1 connect mygdsadmin/passwd_mygdsadmin –建立連接 add shardgroup -shardgroup shgrp1 -deploy_as primary -region region1 –添加主分片組 add invitednode shard1 create shard -shardgroup shgrp1 -destination shard1 -credential oracle_cred –-不同的shard庫添加到不同的分片組裏 add invitednode shard2 create shard -shardgroup shgrp2 -destination shard2 -credential oracle_cred –-不同的shard庫添加到不同的分片組裏 deploy 一鍵部署。 |
此時一套測試的sdb搭建成功,由於環境有限這裏沒有做容災,Oracle提供了OGG和ADG兩種方式對shard節點做容災並且也支持一鍵部署。
四、Sharding適用場景限製
根據Oracle官方對sharding的應用場景介紹描述,Oracle分片技術主要適用以下場景:
-
麵向 OLTP 應用場景
-
為了優化性能應用程序應該使用分片鍵
-
業務場景中 80% 的事務都基於單個分片操作
-
跨分片操作目前版本支持並不完善
對於已知的分片技術使用場景限製,結合浙江移動的業務特點,最後選擇客戶中心做為本次的測試模型,由於存儲資源有限我們選擇了數據量相對較小的湖州地市作為測試地市。
五、Sharding測試模型和測試結果
客戶中心業務簡介:
1. 客戶中心儲存的數據來源於原CRM係統中的三戶信息和用戶訂購信息,承載的是客戶管理業務;
2. 三戶信息的核心是用戶信息表,其中用戶信息表的業務入口是bbb_id,在獲取bbb_id和uuu_id的對應關係後,後續都是以uuu_id為主,查詢到相應的uuu_id對應的ccc_id/aaa_id的信息,再根據ccc_id和aaa_id的值去查詢對應的客戶和帳戶信息,而用戶的訂購信息都是根據uuu_id來查詢的;
3. 對所有前台或用戶發起的針對單用戶的業務中,基本能保證這些業務都是在同一個分片內操作;
4. 用戶信息會隨著係統承載的用戶量的增加有所增長,但這種增長的速度不是海量的擴展速度。
測試結果:所有的業務操作大致可以分為以下這三類:
-
單分片查詢
-
duplicate表查詢
-
跨分片查詢
針對基於單分片的分片表查詢,相比於傳統的數據庫查詢速度提升不明顯,因為uuu_id列本身加了索引查詢速度已經夠快了。但是當時數據庫的壓力提升以後,多個分片節點的sdb帶來的優勢預計會有一定的體現,因為所有的數據庫操作被均勻地負載到多台物理主機上麵,由於硬件限製我們沒有做性能測試,對於duplicate表的查詢本身設計就是從catalog庫上通過物化視圖到各個shard庫裏,所以對查詢的速度提升沒有實質的提升作用。
最後的跨分片查詢我們在測試過程中發現Oracle不支持where條件用in或者or,我們大部分的應用都會用到這種條件的查詢,所以跨分片的查詢目前版本支持並不完善。
六、Sharding測試過程中的問題解決
1. 環境部署
-
軟件的版本需要12.2.0.0.3及以上的版本
-
在配置GSM的時候報錯信息不會很直觀的展示出來,這對於安裝部署有很大阻礙。
2. 數據導入
-
Duplicate表的數據導入是從catalog庫導入,分片表的導入可以從各個shard庫導入進去(由於環境有限暫時12.2.0.0.3從catalog庫導入還未來得及測試)。
-
12.2.0.0.3版本以前分片表直接從catalog庫導入會報ora-600錯誤,而且這些錯誤也沒有相應的psu修複。
-
通過dblink用create table as select的方式創建會報不支持的操作類型的錯誤。
3. 業務測試
跨分片查詢在 12.2.0.0.3版本支持並不完善,例如用in或者or 的查詢Oracle會直接報錯。我們已將改進建議提給Oracle,可能會在正式發布版本中得到解決。
所有的連接都經過catalog庫,當連接請求並發上去後catalog將成為瓶頸,需創建多個catalog庫分擔壓力。
同一schema下的各個分片表必須要有主外鍵關係。
原文發布時間為:2017-03-06
本文來自雲棲社區合作夥伴DBAplus
最後更新:2017-05-16 10:31:30