數據庫類型
1.關係型數據庫
關係型數據庫,是指採用了關係模型來組織數據的數據庫。 簡單來講,關係模型指的就是二維表格模型,而一個關係型數據庫就是由二維表及其之間的聯繫所組成的一個數據組織。 關係模型中經常使用的概念:
關係:能夠理解爲一張二維表,每一個關係都具備一個關係名,就是一般說的表名 元組:能夠理解爲二維表中的一行,在數據庫中常常被稱爲記錄 屬性:能夠理解爲二維表中的一列,在數據庫中常常被稱爲字段 域:屬性的取值範圍,也就是數據庫中某一列的取值限制
關鍵字:一組能夠惟一標識元組的屬性,數據庫中常稱爲主鍵,由一個或多個列組
成
關係模式:指對關係的描述。其格式爲:關係名(屬性1,屬性2, ... ... ,屬性N),
在數據庫中成爲表結構
關係型數據庫的優勢:
容易理解:二維表結構是很是貼近邏輯世界的一個概念,關係模型相對網狀、層次
等其餘模型來講更容易理解
使用方便:通用的SQL語言使得操做關係型數據庫很是方便 易於維護:豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了
數據冗餘和數據不一致的機率
2. 關係型數據庫瓶頸
高併發讀寫需求
網站的用戶併發性很是高,每每達到每秒上萬次讀寫請求,對於傳統關係型數據庫來講,硬盤I/O是一個很大的瓶頸
海量數據的高效率讀寫 網站天天產生的數據量是巨大的,對於關係型數據庫來講,在一張包含海量數據的表中查詢,效率是很是低的
高擴展性和可用性
在基於web的結構當中,數據庫是最難進行橫向擴展的,當一個應用系統的用戶量和訪問量與日俱增的時候,數據庫卻沒有辦法像web server和app server那樣簡單的經過添加更多的硬件和服務節點來擴展性能和負載能力。對於不少須要提供24小時不間斷服務的網站來講,對數據庫系統進行升級和擴展是很是痛苦的事情,每每須要停機維護和數據遷移。
對網站來講,關係型數據庫的不少特性再也不須要了:
事務一致性
關係型數據庫在對事物一致性的維護中有很大的開銷,而如今不少web2.0系統對事物的讀寫一致性都不高
讀寫實時性
對關係數據庫來講,插入一條數據以後馬上查詢,是確定能夠讀出這條數據的,可是對於不少web應用來講,並不要求這麼高的實時性,好比發一條消息以後,過幾秒乃至十幾秒以後纔看到這條動態是徹底能夠接受的
複雜SQL,特別是多表關聯查詢
任何大數據量的web系統,都很是忌諱多個大表的關聯查詢,以及複雜的數據分析類型的複雜SQL報表查詢,特別是SNS類型的網站,從需求以及產品階級角度,就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能極大的弱化了
在關係型數據庫中,致使性能欠佳的最主要緣由是多表的關聯查詢,以及複雜的數據分析類型的複雜SQL報表查詢。爲了保證數據庫的ACID特性,咱們必須儘可能按照其要求的範式進行設計,關係型數據庫中的表都是存儲一個格式化的數據結構。每一個元組字段的組成都是同樣,即便不是每一個元組都須要全部的字段,但數據庫會爲每一個元組分配全部的字段,這樣的結構能夠便於標語表之間進行連接等操做,但從另外一個角度來講它也是關係型數據庫性能瓶頸的一個因素。
NoSQL
2009年初,Johan Oskarsson舉辦了一場關於開源分佈式數據庫的討論,Eric Evans在此次討論中提出了NoSQL一詞,用於指代那些非關係型的,分佈式的,且通常不保證遵循ACID原則的數據存儲系統。Eric Evans使用NoSQL這個詞,並非由於字面上的「沒有SQL」的意思,他只是以爲不少經典的關係型數據庫名字都叫「**SQL」,因此爲了表示跟這些關係型數據庫在定位上的大相徑庭,就是用了「NoSQL「一詞。
注:數據庫事務必須具有ACID特性,ACID是Atomic原子性,Consistency一致性,Isolation
隔離性,Durability持久性。
非關係型數據庫提出另外一種理念,例如,以鍵值對存儲,且結構不固定,每個元組能夠有不同的字段,每一個元組能夠根據須要增長一些本身的鍵值對,這樣就不會侷限於固定的結構,能夠減小一些時間和空間的開銷。使用這種方式,用戶能夠根據須要去添加本身須要的字段,這樣,爲了獲取用戶的不一樣信息,不須要像關係型數據庫中,要對多表進行關聯查詢。僅須要根據id取出相應的value就能夠完成查詢。但非關係型數據庫因爲不多的約束,他也不可以提供像SQL所提供的where這種對於字段屬性值狀況的查詢。而且難以體現設計的完整性。他只適合存儲一些較爲簡單的數據,對於須要進行較複雜查詢的數據,SQL數據庫顯的更爲合適。
關係型數據庫與非關係型數據庫的區別
關係型數據庫的最大特色就是事務的一致性:傳統的關係型數據庫讀寫操做都是事務的,具備ACID的特色,這個特性使得關係型數據庫能夠用於幾乎全部對一致性有要求的系統中,如典型的銀行系統。
可是,在網頁應用中,尤爲是SNS應用中,一致性卻不是顯得那麼重要,用戶A看到的內容和用戶B看到同一用戶C內容更新不一致是能夠容忍的,或者說,兩我的看到同一好友的數據更新的時間差那麼幾秒是能夠容忍的,所以,關係型數據庫的最大特色在這裏已經無用武之地,起碼不是那麼重要了。 相反地,關係型數據庫爲了維護一致性所付出的巨大代價就是其讀寫性能比較差,而像微博、facebook這類SNS的應用,對併發讀寫能力要求極高,關係型數據庫已經沒法應付(在讀方面,傳統上爲了克服關係型數據庫缺陷,提升性能,都是增長一級memcache來靜態化網頁,而在SNS中,變化太快,memchache已經無能爲力了),所以,必須用新的一種數據結構存儲來代替關係數據庫。
關係數據庫的另外一個特色就是其具備固定的表結構,所以,其擴展性極差,而在SNS中,系統的升級,功能的增長,每每意味着數據結構巨大變更,這一點關係型數據庫也難以應付,須要新的結構化數據存儲。
因而,非關係型數據庫應運而生,因爲不可能用一種數據結構化存儲應付全部的新的需求,所以,非關係型數據庫嚴格上不是一種數據庫,應該是一種數據結構化存儲方法的集合。 必須強調的是,數據的持久存儲,尤爲是海量數據的持久存儲,仍是須要一種關係數據庫。
非關係型數據庫簡介
SQLite
1. ACID事務
2. 零配置 – 無需安裝和管理配置
3. 儲存在單一磁盤文件中的一個完整的數據庫
4. 數據庫文件能夠在不一樣字節順序的機器間自由的共享
5. 支持數據庫大小至2TB
6. 足夠小, 大體3萬行C代碼, 250K
7. 比一些流行的數據庫在大部分普通數據庫操做要快 8. 簡單, 輕鬆的API
9. 包含TCL綁定, 同時經過Wrapper支持其餘語言的綁定 10. 良好註釋的源代碼, 而且有着90%以上的測試覆蓋率 11. 獨立: 沒有額外依賴
12. Source徹底的Open, 你能夠用於任何用途, 包括出售它 13. 支持多種開發語言,C, PHP, Perl, Java, ASP .NET,Python
歡迎關注本站公眾號,獲取更多信息