高并發(fā)Oracle數(shù)據(jù)庫系統(tǒng)的架構(gòu)與設(shè)計經(jīng)驗談，歡迎參與！

lanyuflying

回復 1# send_linux

oracle,mysql都用過，Oracle是非常喜歡的數(shù)據(jù)庫，雖然在互聯(lián)網(wǎng)環(huán)境下，mysql大行其道，但是Oracle的某些優(yōu)秀特性還是讓其在核心場合不可替代。下面一個一個說下。
1. Oracle的高并發(fā)問題分析與解決；
    （1）性能診斷，找出鎖等待，長時間sql，以及是否有索引失效(sql未走索引)等,
      （2）分析硬件性能是否能適應壓力：cpu耗用，內(nèi)存大小，內(nèi)存分配情況，磁盤io,網(wǎng)絡(luò)io  
2. 高并發(fā)數(shù)據(jù)庫架構(gòu)設(shè)計；
  高并發(fā)情況，通常和需要考慮數(shù)據(jù)量的問題。也就是高并發(fā)與大數(shù)據(jù)量（比如核心表單表超過千萬）經(jīng)常是相關(guān)的。單純高并發(fā)的解決主要考慮緩存和io。
   對于更常見的高并發(fā)與大數(shù)據(jù)量并存的情況，有以下幾個方面的問題：
   （1）索引：針對業(yè)務(wù)建立恰當?shù)乃饕?br />     (2) 分區(qū)：數(shù)據(jù)量很大的時候，根據(jù)情況使用分區(qū)表，并且，如果需要的話可以進一步分區(qū),結(jié)合分區(qū)建立分區(qū)索引。
    (3)合理規(guī)劃表空間，合理分布IO到不同的磁盤，考慮使用陣列，并讓數(shù)據(jù)庫服務(wù)器到陣列使用專用的網(wǎng)絡(luò)通道
    (4)  應用層：合理使用多進程或者多線程運行(避免資源征用導致并發(fā)能力下降)
     (5) 考慮使用應用層緩存
     (6)如果并發(fā)量太大，可以考慮RAC
   （7）進一步的可以考慮應用層的分庫，分表。這個時候拆分規(guī)則由專門的規(guī)則層維護。方案雖然復雜，但是擴展性很好。
     
3. timesten內(nèi)存數(shù)據(jù)庫相關(guān)應用。

    內(nèi)存數(shù)據(jù)庫，由于避免了磁盤IO,實時性很好。但是單機內(nèi)存的量一般不會特別大，所以高并發(fā)是優(yōu)勢，但是對于數(shù)據(jù)量很大時，就需要考慮劃分實時數(shù)據(jù)和歷史數(shù)據(jù)的問題，讓實時業(yè)務(wù)走內(nèi)存庫，歷史數(shù)據(jù)查詢類業(yè)務(wù)走磁盤庫。其他更深入的沒有了解，也寫不出來了。


   

aluocp

回復 13# lanyuflying


一看就是Oracle死粉了，在去IOE運動的大背景下，還能有這樣的言談，著實不易。

Oracle部分跟我書里的章節(jié)邏輯有不謀而合之處，需要補充一點就是統(tǒng)計信息的管理和性能影響分析，做到對高并發(fā)的可量化預測。

TimesTen部分可以參考一下書中的第6章，相信會有所裨益的。

beyondfly

頂一下，好活動，就是持續(xù)的時間有點短。

forgaoqiang

活動不錯 就是看上去有些 高大上了

ylky_2000

想結(jié)合實際工作咨詢兩個問題：
1、數(shù)據(jù)庫經(jīng)常莫名其妙的出現(xiàn)死鎖；物理上機器沒有斷電，網(wǎng)絡(luò)也沒有異常，一般出現(xiàn)死鎖的因數(shù)有哪些？分別如何解決？最好一勞永逸的避免。
2、高并發(fā)的中心思想是否是同一個數(shù)據(jù)庫服務(wù)器能承擔更多的并發(fā)訪問？除物理主機本身的性能因數(shù)外，還跟數(shù)據(jù)庫的哪些因數(shù)相關(guān)？高并發(fā)的核心思想是什么？
3、高并發(fā)與分布式數(shù)據(jù)庫從原理上來看有什么本質(zhì)的區(qū)別？
4、淘寶等號稱去o。他們就不擔心前面您提到的開源數(shù)據(jù)庫的幾個存在的問題嗎？
5、關(guān)于商業(yè)應用這塊的問題。oracle數(shù)據(jù)庫如果購買企業(yè)內(nèi)網(wǎng)辦公系統(tǒng)和對外商業(yè)系統(tǒng)版權(quán)如何購買？

thinkeasy

互聯(lián)網(wǎng)應用的開發(fā)與傳統(tǒng)應用的開發(fā)有本質(zhì)的區(qū)別就是數(shù)據(jù)庫設(shè)計上。

傳統(tǒng)的開發(fā)很大一部份業(yè)務(wù)流程是在數(shù)據(jù)庫上完成的，比如使用存儲過程、視圖、觸發(fā)器、計劃任務(wù)等方式。
互聯(lián)網(wǎng)應用在高并發(fā)的需求下，很多數(shù)據(jù)庫設(shè)計就明確提出了數(shù)據(jù)庫只起到存儲數(shù)據(jù)的功能。業(yè)務(wù)流程全是由程序或是腳本來完成。

去IOE其實是在這個基礎(chǔ)上提出來的�；ヂ�(lián)網(wǎng)開發(fā)的運用了很多分布式，將業(yè)務(wù)流程拆開，每臺服務(wù)器只處理簡單的業(yè)務(wù)流程。這樣對單一的服務(wù)器要求降到了最低，數(shù)據(jù)庫也一樣。

aluocp

回復 17# ylky_2000


1、數(shù)據(jù)庫死鎖是邏輯問題，跟物理機器和設(shè)備沒有關(guān)系。一勞永逸的辦法是沒有的，需要從應用程序本身入手，一般出現(xiàn)死鎖都是應用邏輯的設(shè)計出現(xiàn)問題了，想從數(shù)據(jù)庫層面解決是不大可能的，如果死鎖多，基本上不用考慮高并發(fā)了。
2、我的書里介紹了一個方法論，構(gòu)建數(shù)據(jù)庫森林體系，你可以參考一下。
3、分布式數(shù)據(jù)庫是解決高并發(fā)的一個思路，高并發(fā)是一個總稱，但是不是什么應用都能實現(xiàn)分布式的。
4、阿里的支付寶還沒有實現(xiàn)完全的去O嘛，如果什么時候銀行都實現(xiàn)了去O，那就另一番氣象了。阿里有能力自己研發(fā)數(shù)據(jù)庫OB，也可以自己改寫MySQL，這樣就可以很好的解決我書里提到的問題。但如果是傳統(tǒng)金融行業(yè)，即便做到了阿里那樣，也不可能去O的，也沒有必要非要去O。
5、這個需要咨詢Oracle公司。

aluocp

回復 18# thinkeasy


正解，不是什么應用都可以實現(xiàn)分布式的，不要盲目去IOE。

miniuinx

總的來說  Oracle還是很多核心應用的必選，而MYSQL還是有點讓人心悸，我在的這話行業(yè)目前全國還是都Oracle的，不敢用mysql。
個人覺得原因有以下：
1、不缺錢，
2、缺人，現(xiàn)場缺少維護MYSQL的人（這個不是說沒人會MYSQL維護，而是缺少推動這件事的人），
3、再開發(fā)難度大，前期所有軟件都圍著Oracle開發(fā)，在整一套MYSQL有點……
雖然現(xiàn)在有云，但這張網(wǎng)是私網(wǎng)，接入云的可能性幾乎沒有。

現(xiàn)在外面嚷嚷著去IOE, 路還是很漫長的。

wang290

aluocp 發(fā)表于 2015-02-05 09:27
回復 18# thinkeasy

現(xiàn)在的去ioe有點大躍進的味道啊，很值得深思啊