現在開始講另外一個知識點吧,這個知識點也是怎么說呢,就是非常有用的知識點,剛才看了一下表空間

現在咱們說一下ORACLE里面的表類型,表類型其實有這么多種表1. 正常我們的heap table,堆表,你正常建的表2. 然后還有分區表3. 索引組織表4. 簇表5. 臨時表,臨時表就是用于查詢排序的6. 壓縮表7. 嵌套表,這些都沒用過ORACLE表類型也是很多的,咱們其實要考慮的就是兩個表就夠了,你要開發用兩個表就夠了,堆表和分區表,ORACLE最重要的是分區的概念,分區的概念,正常表是大于,>是大于號,建議你大于2個G才分區,如果要是小于兩個G的話,那你就不要分區這個事了,然后我剛才也說了,日常的開發中的分表分庫的問題,其實都是基于OLTP和OLAP的業務前提之下,才會進行分區,進行切割的,可能有水平,垂直切分,在ORACLE里面早就有這種概念了,就是使用分區,來做這個事情,首先我們來掃盲一下OLTP和OLAP的概念

首先OLTP和OLAP,互聯網時代,海量數據的存儲和訪問成為系統設計和使用的瓶頸問題,就是數據量特別大,然后業務還挺復雜,這種問題你怎么辦,對于海量數據的處理場景,主要分為兩種類型,一種是聯機事務的處理,還有一種是聯機分析處理,抓住關鍵字,一個是事務處理,還有一種是分析處理,那都是有多臺機器,多個節點,表進行聯機的,聯機什么概念,多個機器多個節點,就是這么去處理的,首先聯機事務處理,說白了就是分布式事務了,一般是面向交易類的系統,可以這么去說,其基本特征是原始數據可以立即傳送到計算中心進行處理,然后在很短的時間內給出處理結果,其實是支持分布式事務去做,聯機分析處理是指通過多個維度的,多個方式的進行統計分析,數據的查詢分析,可以做查詢報表啊,可以做數據挖掘啊,分析出來了,提供一個決策啊,這種能力,就好比你做一個離線分析,我這個就是固態硬盤,實時分析或者離線分析,都是這種大數據的處理,商品推薦,近期瀏覽過的商品,把同類的商品給你n推薦過來,分析處理的,分布式的海量數據處理,就這兩個概念,早期的ORACLE其實以為大數據時代,他自己能承載的住,但是很抱歉,它是承載不住的,因為人家那個PG級的,一千億往上的那種數據,海量數據,其實這種東西ORACLE也是無能為力的,只能利用咱們的hadoop,做離線分析,在線分析,實時的,spark像這種東西,只能是依賴于這種東西,一千億以下的數據,單表,單表一千億以下的數據,這個都不算海量數據,想這種東西你也可以考慮,這個ORACLE也是可以做處理的,理論上來說,其實剛才那個已經是很龐大的數據了

兩者的主要區別,就是TP和AP的主要區別,首先TP,比如說,日常的交易處理啊,面向實時的處理,處理的是當前最新的細節的,二維分立的,他要求讀寫的實時性比較高,事務的強一致性,分析要求就是很簡單,很easy,像這個海量數據的分析呢,可能就很復雜了,他實時性不一定要求很高,很低,事務性也可以很弱,你少分析一兩條數據無所謂,丟一點數據也無所謂,但是很復雜,咱們可能都知道訂單啊,訂單的系統,跟錢有關的業務,其實他這個業務都是很簡單很簡單的,不是很復雜的,可能就是這邊把訂單放在一個地方,他們兩個可能數據操作,業務都不是很復雜,這個事就結束了,那像OLAP這邊就做很復雜的分析了,即使這邊是多個節點的,但是他寫業務代碼的復雜度,一般不會很復雜,而且數據量也是很小的,可能很實時,可能是1秒鐘給我來100條數據,但是每條數據的量都是很小,然后這個分析的需求業務,處理數據的業務都是很簡單的,可能維度是二維的,一個時間,一個空間最多了,像AP這種就很復雜了,你要涉及到很多的東西,你要進行一個綜合的統計分析,這個東西可能就很復雜了,就做一個報表啊,類似這種東西,尤其是一些歷史性的數據,比如這個東西12年它是什么樣的結果,13年怎么樣,14年怎么樣,15年怎么樣,給我做一下同比,再給我做一下環比,同比和環比聽過嗎,應該都聽過吧,這是一個很經典的詞,不知道搜一搜,歷史數據嗎,14年13年,這個數據怎么比,2月份1月份,09年12月份,09年11月份,這種規律的這種數據的對比,這種分析很多

就是關系型數據庫和非關系型數據庫,首先呢特點,關系型數據庫的優點和缺點,NoSQL的特點,優點和缺點,這個東西怎么說啊,我建議你把這個東西仔細看一看,加上你自己的理解,這個說出來才有意義,要不然所有的人都和我這個說的一樣,那我覺得也沒有什么技術含量,那這個優點和缺點就不用我再說了,NoSQL就是高并發大數據下,讀寫能力是很強的,性能是很高的,而且是分布式的,而且是高可用的,咱們的關系型數據庫呢,主要是處理事務,可以進行復雜邏輯的查詢,非常的成熟,通用化,這就夠了,他們兩個的優點,一個是可以解決很復雜的任務,數據庫里一百多張表,NoSQL給我做一下,不現實,絕對夠嗆,100多張表給我映射到NoSQL里邊,你用我們的LIST,HASH,或者是ZSET,都不合適,就是他能處理很復雜的業務,能夠進行join查詢,技術很成熟,多少年了,NoSQL就針對于大并發了,然后他們的缺點,也都會有

對我們的數據要進行切分,為什么要進行切分,相當于讀這段話,瀏覽一下,就是你要通過特定的條件和規則,說白了就是你自己的業務,怎么樣去規定的,你這個業務是長成什么樣,你就得把放在同一個數據庫的數據,這個表放到A庫里了,然后就需要把A庫里的數據,數據量很大,你得切分到B庫,或者C庫,這種形式,然后咱們傳統上的切分就兩種,一種是垂直,一種是水平,那垂直切分是什么意思啊,它是按業務邏輯模塊走的,叫Sharding,就是這個垂直的切分,其實對于ORACLE就相當于不同的SCHEMA,就是按照不同的表,來區分不同的數據庫,這個叫做垂直縱向的切分,就好像我昨天講的那個似的,供應商里面一堆表,這個業務是一個業務,然后其他的比如訂單,購物車這是一個系統,一堆表,他們兩個正常來講,系統小的話,是不是可以用一個數據庫實例,但是后來覺得這樣不好用,不好擴展,所以我要按照不同的業務模塊,我這邊分一個庫,他們的業務是緊密相關的,然后跟其他的系統,這個系統可能是關聯不大,這個叫做垂直的切分,水平切分就是根據表中數據的邏輯關系,然后進行一個劃分,水平切分就是有一個特點,同一張表中的數據按照某一個條件,拆分到多個數據庫上,注意這句話,按照表中數據的某一個條件,說白了就是某一個記錄唄,按照這種規則切分到不同的數據庫上,這種方式叫做水平橫向的切分,你比如說,咱們那天也講了,咱們QQ的會員,里面都有一個字段,一個字段的條件,type這個條件,type就是等級level,一個是一級,一個是二級,一個是三級,然后是很多,比如說四級,五級,按照這個級別,所有數據一級的用戶都放在一個庫里面,存著,把二級的右放到一個數據庫里面存著,像這種按照某一個條件,或者是某兩個條件,這東西不是非得是一個條件,也可能是兩個三個條件,你可以是并行的關系,and關系,條件1加條件2,都滿足,所有滿足這兩個條件的數據,都給他放到一個數據庫里,這是可以的,就是按照一種類型條件,一個字段,或者兩個字段,他們兩個都有對應的特點,垂直切分的特點就是規則簡單,我已經把大方向業務劃分出來了,兩塊系統,一個是購物車,一個是訂單,基本上沒有太多的關系,有關系的我就合理的做一些冗余,或者做一個中間庫啊,做一個數據轉換,他們之間做數據交換也可以,都行,總之垂直拆分的特點就是規則特別簡單,按照不同的業務劃分成兩個數據庫,然后把這個數據庫的表中的業務創建出來就可以了,實施也比較方便,尤其是各個業務的解耦,就是耦合性非常低,兩個之間沒有任何的影響,系統之間的影響也非常小,系統的邏輯也非常的清晰,這邊就是處理訂單的,那邊就是處理供應商的,也可以按照角色去劃分,你比如這邊的系統就是用戶的系統,而那邊的系統就是操作人員的系統,或者是什么的系統,可以按照角色劃分,然后這里邊也說了,根據不同的表來進行拆分,對程序的影響更小,拆分規則也簡單,水平切分相對于垂直切分,他比較復雜,為什么啊,因為他是把一張表的不同數據,拆分到不同的數據庫上,所以這個就比較麻煩了,舉個簡單的例子,比如這表有1,2,3,4,四條記錄,比如我把1,2條記錄就拆到一個庫了,那這里就沒有了,這里放1,2,這里放3,4,那最后我要查count的時候,我至少要連兩個數據源,然后count(*),這邊再count(*),兩邊再加起來,一共是4,最起碼要做這個事了,那這個東西維護起來也比較麻煩一些

這邊就是畫一個,什么叫垂直拆分就在這兒呢,本身之前是一個庫,單個的database,用戶系統單獨劃分一個database了,訂單系統一個database,支付系統又有一個database,他們之間可能有一些數據的交換,這也是從網上隨便抓的一個圖,這個很簡單

什么是水平切分呢,就是按照某一種規則,來把一張表的數據庫,一張表的數據,分散到各個庫上,比如說,這個邏輯都是這么去分的,大方向肯定是按照垂直進行拆分,我把單個數據庫變成3個系統,一個是用戶,一個是訂單,還有一個是支付,然后我先我用戶的數據真的是很多很多,那怎么辦啊,用戶這張表啊,我指的是一個用戶系統,用戶系統里可能有10幾張表,就不一定是一張表,那我可能覺得user這張表可能太多了,比如說騰訊,那怎么辦啊,用戶我按照我自己的業務規則,按照用戶的ID啊,或者按照其他的type啊,時間啊,按照這種規則,一個也好,兩個也好,我把它拆分成3個數據庫,存放不同的數據,這三個才放一個表里的數據,有什么拆分的原則和規范嗎,其實拆分的原則很簡單,拆分的原則是什么啊,我就簡單的說兩個原則吧,兩個條件滿足吧,兩個條件一定是and的情況,并不是OR的情況,AND和OR是有區別的,1和2兩個是AND的時候,你才能采用分表,分表的這個理念,分表也叫分片,一般來講也可以這么去說,都一樣的,什么意思呢,第一個條件是什么啊,第一個條件一定是要訪問的非常的頻繁,這個才是最主要的,高并發下,訪問頻繁,非常的頻繁,可能1，秒鐘就訪問多少多少次,訪問的非常的頻繁,滿足這一個條件就OK了,第二個就是數據量太大了,就是數據量大,我記得我也說過了,就是你即使數據量大,數據量多大啊,數據量很大很大,那我也不一定非要這么分表啊,按照你自己的需求來,你數據量大,但是我可能就一天查詢一次,那我就后臺定時跑一個存儲過程,或者每天凌晨的兩天鐘跑一個存儲過程,第二天6點鐘才會看這個數據結果,你就沒必要做這個事情了,你把這個很大的一張表,你把它分成不同的數據庫,這樣給你的業務就增大難度了,本來做這個事就很簡單的,當然這個數據量大到什么程度上,我覺得就是10個G左右吧,或者是20個G,你要是上百G,我這個表,我是沒見過,反正我覺得50個G就是一個極限了,你表里的數據如果有50個G的話,ORACLE來講,就不管你這個表是不是頻繁訪問,你以后維護也麻煩啊,你就需要把這個東西做一個分庫,或者說你不分庫也行,但是你起碼也不是單表50個G,你可以把它分散成多個表,user表隨便起個名字,里面50個G,那我現在把它拆開,把它分成u1,u2,u3,u4,u5,......,每個表里放10個G,這樣多好啊,為什么我們不往同一個數據庫里去切分,為什么50個G不是這里放10個G,這里放10個G,這里也放10個G,這邊還有10個G,為什么不放在5張表,放到一個數據庫里呢,還是我剛剛說的第一個條件,并發大,并發大你這里是一個數據源,反正我這個service肯定要返回一個數據源,所以你這么拆不拆沒啥用,就是一定要知道,你必須得分成數據庫了,多個數據源,可能這個并發有1萬次,1萬次太多了,舉個簡單的例子,我就隨便說5萬次,并發5萬次,其實這也是一個負債均衡,第一個數據源承擔了一萬次,第二個數據源又承擔了一萬次,然后你還可以再細粒度,也可以這里面再拆分10個,放到這兒,一個數據庫可能承擔5千次,然后再2往下遞歸的鋪墊,這都行

相當于拆分的優缺點了,優點我就簡單的介紹一下了,垂直拆分的優點就這三個:1. 業務邏輯清晰2. 擴展性強3. 維護起來非常簡單在軟件設計上有一個什么啊,怎么說呢,有一個原則,我之前好像也說過,我記得外國有一個很牛的人,他說了一個話,別人都跟他一起說了,你做軟件開發吧,現在不是都講分布式事務嗎,分布式,如果你的應用能不用分布式事務的方式實現,原始垂直的方案實現,那你最好就原始垂直的方案,分布式第一個首要的原則,能不用分布式就不用分布式,能理解我說的意思吧,這是設計開始的第一個原則,就是盡量別用分布式,分布式帶來的成本,包括不可控的東西太多了,所以說垂直拆分就是最簡單的,水平拆分你得有一個規則,之前的規則你得做的足夠好,這才行,盡量的去避免多個數據源之間的聯合,這里面的join是什么意思呢,我跟你們說啊,事實上是這樣的,相當于這里一個數據源,這里兩個數據源,就是這邊有一張表,這邊有一張表,這兩個表之間要有一個join,要有一個join關系,但是你不能寫數據庫語句寫成那樣,這兩個數據源嗎,所以他們兩個有一個通用的字段,比如這邊規定有一個type類型,然后這邊有一個id,其他的,他們兩個有一個自定義的主外鍵關系,掛上鉤,通過這里的字段就可以找到這里惟一的數據,是這樣的,通過這種方案,這也可以叫做一種join然后就是水平拆分的優點:1. 可以提高并發的能力,肯定能提高并發的能力,我要把數據分到不同的分片上,不同的庫上了,然后提高系統的穩定性和負載能力然后下面就是有一個小例子,也很簡單的,其實我在這里說其實沒啥意義,還是得根據你以后的具體的工作,具體的需求,可能我要按照時間的維度,時間進行一個拆分,水平的拆表,可以按照不同的角色,進行拆分,供應商或者用戶,按照不同的業務規則等等去做,這種東西都不是不固定的,如果數據庫設計有一個固定的套路的話,那這個就太簡單了,這種事本來就是一個很難把控的一件事,然后比如你電商里買東西,有一些自營產品,還有一些第三方的產品,那就會進行分庫的操作,我自營的放到一個數據庫里面,還有訂單的分流,放到不同的數據節點上,有很多,真是沒有一個很細粒度的說明,只是一些大體上的概念上的問題,以后做實際案例的時候再說吧,這個目前只能是到這個程度了

拆分的缺點和解決方案,這塊就是你做數據拆分了,你無論是做水平拆分也好,還是做垂直拆分也好,你都會有一些共通的缺點主要是有三大缺點吧,小缺點一堆,但是我們要解決三大核心的缺點1. 第一大缺點是解決了分布式事務的問題,因為不管是水平還是垂直,你總是把數據分散到不同的數據源上了,比如物理來講就是返回了不同的機器,所以來說他就會有一些分布式事務的問題,肯定是有這個問題的,解決方案其實多了去了,我只是列這么幾種,解決方案,根據不同的實例,具體分析解決,那我舉三個常見的方案,第一種方案,比如你業務邏輯非常復雜的時候,這什么意思,說白了,就是你要有一個概念,我畫一個圖吧,比如現在我把原先一個數據庫的東西,我分成了三個數據庫,分成了三個數據庫,然后第一塊存了1,2,3,第二塊存了4,5,6,第三塊存了7,8,9,那就是一個很簡單的邏輯,像這種問題,只要是拆分了,涉及到分布式事務的問題,這是百分百會涉及的,我們應該怎么去解決分布式事務的問題呢,這個還是得按照你具體的問題具體的去分析,你只能這么說,比如說你這個業務邏輯非常復雜,但是數據量不大的時候,什么叫業務邏輯非常復雜啊,我們都寫過JAVA代碼,可能是業務邏輯很復雜,正常來講一個數據庫的話,你怎么去寫,從service開始,一直到service結束,我可能寫了2千多行的業務,甚至說更多,就是一個Service里面包含了兩千多行,你這個業務邏輯很復雜的時候,然后你還得操作不同的數據,你前1千行代碼,也操作這三條數據,后一千行代碼也操作另外一個一千行數據,最后你還得操作另外一個一千行數據,最后再結束,我舉的例子就是業務邏輯很復雜的時候,你應該怎么去考慮,業務邏輯復雜的時候的話,一般這種都是使用SOA,做通用的服務,就這么辦是最簡單,最省事的,我個人覺得是最OK的,在Service層上做多個切面,配置多個事務,我先不講具體怎么做,能理解嗎,使用SOA做通用的服務,在Service層上做多個切面,配置多個事務,首先我說的第一種方案是在業務邏輯復雜的時候,SOA我畫一個圖吧,只有想不到,沒有做不到的事情,舉個例子吧,就現在咱們說,這種電商的網站,可能不一定就是電商了,就比如WEB服務吧,這是我的WEB服務,這又是一個WEB服務,這又是一個WEB服務,可以吧,WEB服務干什么呢,WEB服務就是一個應用嗎,WEB APPLICATION,我要把它放到TOMCAT,或者WEB容器上去運行,那我把這個叫做WEB1,WEB2WEB3,這邊叫WEB1,這邊叫WEB2,這邊叫WEB3,這是我的三個WEB應用,三個應用涉及到不同的邏輯,相當于三個系統,這邊對應的可能就是我的服務層了,那么著三個服務層就是SOA,1,2,3,SOA1,SOA2,SOA3,就是這個意思,SOA是什么意思呢,咱們以前寫代碼的時候,寫JAVA代碼的時候,或者你做項目的時候,之前不是這么去寫的,就是一個JAVA Project,里面分層嗎,先有一個WEB層,就是Controller,然后就是Service層,然后Service Implement層,然后還有DAO層,數據訪問層,持久層,然后有什么實體啊,Entity,這個不說了,大體上就是這樣的,現在一種新型的都是怎么去做的呢,把WEB層提出來,他就類似于我們這里的WEB1,WEB2,WEB3, 然后所有的Service層都抽出來,轉換成不同的SOA服務,比如WEB1是針對于用戶的,這可能是user web1,那就涉及到增刪改查的,user service,就是us吧,我把它就當做一個服務了,那當然用戶還關聯一些角色啊,就是role,role service,還可能關聯一些崗位啊,什么權限啊,包括什么功能啊,總之跟這個模塊相關的service,我都給他獨立出來,抽象成一個一個的小service,然后直接扔到這個系統中,可能一個服務一個服務單獨的去linux中java -jar,然后就直接把這個服務給啟動了,之前也學過netty,學netty不是學了怎么起的嗎,java -jar啟動主函數,服務就起來了,那這個service其實我也可以這么去做,都一樣的,好了,那這里就提供了10個服務,SOA1就提供了10個服務,那這10個服務可能就針對WEB1去做服務的,那也可能有一種情況就是說,可以有一種什么情況啊,不一定這10個服務就是針對與他的,有可能針對于它,也可能針對于她,總之我這個SOA1,里面假設有100個小服務的話,里面有80個,甚至80個以上,針對WEB1的,可能有些服務是通用的服務,這個就不說了,比如這里是訂單的一個系統,ORDER,這一百個服務都是針對訂單,每個系統都有一些耦合,這是肯定的,包括第三個,比如購物車,這個WEB系統,那我現在的原則就是什么啊,就包括我以前做設計的時候,一個SOA只對應一個數據源,一個DATABASE,就是一個DB,然后這個SOA也是對應一個DB,一個數據源,這一個也對應一個DB,舉個例子,那假如我先做有一個問題,說WEB2里面就是有一個功能,就是需要SOA1里面的其中的一個服務,并且還要用到SOA3的一個服務,那這個東西怎么去做呢,他們兩個用的是不同的數據源,一個是DB1,一個是DB3,來一個SOA4,如果有這種公用的話,那我就可以單獨來一個Service,他可能就不返回任何的數據庫了,就是為了抽取公共的,也不一定訪問數據庫,可以訪問也可以不訪問,有沒有都一樣,然后這里面就寫一個service,這個怎么寫呢,咱們就叫public SOA4,里面去調SOA1,SOA3的service,里面加兩個事務的切面,相當于Spring的XML配置的話,加兩個execution,這兩個切面都對應上,都加到這一個方法上,這樣的話只要這個方法一失敗的話,同時就回滾兩個切面里的SOA1，和SOA3服務,我說的方案是針對于你的業務邏輯很復雜的時候,你要采用這種,可能我這里跨度很大,可能既要訪問SOA1,SOA2,SOA3,還有可能要訪問SOA5,可能提供更多的服務了,總之要調好多service的時候,那你就這么去做,這么去做就OK的

我就暴露兩個服務,真很簡單,就是你寫一個方法的時候,你這么去寫,public 這個方法我略了,這個方法里面我調一個SOA,我再把我兩個數據源,DB1和D3的數據源,這個本來就是一個SOA的服務,那這個服務肯定對應了一堆的配置,Spring的ApplicationContextxml,我把兩個數據源都放到這里面,不就OK了嗎,我再配置兩個事務,這個叫T1，這個叫T3,這個數據源叫D1,D3,然后我再配置兩個切面,D1的數據源配一下S方法,D3的數據源再配一下S方法,就好像加兩個Transaction一樣,在這個方法上加一個,然后在這個方法上又加一個,這不就OK了嗎,分布式的主要意思概念就是,分布式不是系統來的,他就是按照表來的,我可以很篤定的跟你說,我先做只要有兩個數據源,這里面放一部分表,這里面放一部分表,這個系統就是一個分布式系統,分布式概念就是這么來的

?

總結

以上是生活随笔為你收集整理的Oracle之垂直水平分库分表（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。