閱讀699 返回首頁    go 阿裏雲 go 技術社區[雲棲]


驚喜與局限並存,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體係結構

  

20170306113005892.jpg

 

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腳本(這裏使用了圖形化界麵)

 

20170306113014901.jpg

 

直接點下一步(檢查操作係統是否符合安裝條件):

 

20170306113021878.jpg

 

點next下一步:

 

20170306113028818.jpg

 

點擊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

  上一篇:go  分布式實時數據處理實戰:從選型、應用到優化
  下一篇:go  AWS S3誤操作,官方故障回顧及專家深度思考