正文

最近了解了一點非關(guān)系型數(shù)據(jù)庫，剛剛接觸，覺得這是一個很好的方向，對于大數(shù)據(jù) 方面的處理，非關(guān)系型數(shù)據(jù)庫能起到至關(guān)重要的地位。這里我主要是整理了一些前輩的經(jīng)驗，僅供參考。

回到頂部

關(guān)系型數(shù)據(jù)庫的特點

  1.關(guān)系型數(shù)據(jù)庫 

關(guān)系型數(shù)據(jù)庫，是指采用了關(guān)系模型來組織數(shù)據(jù)的數(shù)據(jù)庫。 簡單來說，關(guān)系模型指的就是二維表格模型，而一個關(guān)系型數(shù)據(jù)庫就是由二維表及其之間的聯(lián)系所組成的一個數(shù)據(jù)組織。常見 的關(guān)系型數(shù)據(jù)庫有Oracle、Mysql、sql server等等。

2. 關(guān)系型數(shù)據(jù)庫瓶頸 
高并發(fā)讀寫需求 
網(wǎng)站的用戶并發(fā)性非常高，往往達(dá)到每秒上萬次讀寫請求，對于傳統(tǒng)關(guān)系型數(shù)據(jù)庫來說，硬盤I/O是一個很大的瓶頸 
海量數(shù)據(jù)的高效率讀寫 網(wǎng)站每天產(chǎn)生的數(shù)據(jù)量是巨大的，對于關(guān)系型數(shù)據(jù)庫來說，在一張包含海量數(shù)據(jù)的表中查詢，效率是非常低的 
高擴展性和可用性 
在基于web的結(jié)構(gòu)當(dāng)中，數(shù)據(jù)庫是最難進行橫向擴展的，當(dāng)一個應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時候，數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點來擴展性能和負(fù)載能力。對于很多需要提供24小時不間斷服務(wù)的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移。  
對網(wǎng)站來說，關(guān)系型數(shù)據(jù)庫的很多特性不再需要了： 
事務(wù)一致性 
關(guān)系型數(shù)據(jù)庫在對事物一致性的維護中有很大的開銷，而現(xiàn)在很多web2.0系統(tǒng)對事物的讀寫一致性都不高 
讀寫實時性 
對關(guān)系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出這條數(shù)據(jù)的，但是對于很多web應(yīng)用來說，并不要求這么高的實時性，比如發(fā)一條消息之后，過幾秒乃至十幾秒之后才看到這條動態(tài)是完全可以接受的 
復(fù)雜SQL，特別是多表關(guān)聯(lián)查詢 
任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品階級角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了  
在關(guān)系型數(shù)據(jù)庫中，導(dǎo)致性能欠佳的最主要原因是多表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報表查詢。為了保證數(shù)據(jù)庫的ACID特性，我們必須盡量按照其要求的范式進行設(shè)計，關(guān)系型數(shù)據(jù)庫中的表都是存儲一個格式化的數(shù)據(jù)結(jié)構(gòu)。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為