sql,nosql

1. 關係型數據庫

關係型數據庫，是指採用了關係模型來組織數據的數據庫。

關係模型是在1970年由IBM的研究員E.F.Codd博士首先提出的，在以後的幾十年中，關係模型的概念獲得了充分的發展並逐漸成爲主流數據庫結構的主流模型。

簡單來講，關係模型指的就是二維表格模型，而一個關係型數據庫就是由二維表及其之間的聯繫所組成的一個數據組織。

關係模型中經常使用的概念：

• 關係：能夠理解爲一張二維表，每一個關係都具備一個關係名，就是一般說的表名
• 元組：能夠理解爲二維表中的一行，在數據庫中常常被稱爲記錄
• 屬性：能夠理解爲二維表中的一列，在數據庫中常常被稱爲字段
• 域：屬性的取值範圍，也就是數據庫中某一列的取值限制
• 關鍵字：一組能夠惟一標識元組的屬性，數據庫中常稱爲主鍵，由一個或多個列組成
• 關係模式：指對關係的描述。其格式爲：關係名(屬性1，屬性2， ... ... ，屬性N)，在數據庫中成爲表結構

關係型數據庫的優勢：

• 容易理解：二維表結構是很是貼近邏輯世界的一個概念，關係模型相對網狀、層次等其餘模型來講更容易理解
• 使用方便：通用的SQL語言使得操做關係型數據庫很是方便
• 易於維護：豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了數據冗餘和數據不一致的機率

2. 關係型數據庫瓶頸

• 高併發讀寫需求

網站的用戶併發性很是高，每每達到每秒上萬次讀寫請求，對於傳統關係型數據庫來講，硬盤I/O是一個很大的瓶頸

• 海量數據的高效率讀寫

網站天天產生的數據量是巨大的，對於關係型數據庫來講，在一張包含海量數據的表中查詢，效率是很是低的

• 高擴展性和可用性

在基於web的結構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像web server和app server那樣簡單的經過添加更多的硬件和服務節點來擴展性能和負載能力。對於不少須要提供24小時不間斷服務的網站來講，對數據庫系統進行升級和擴展 是很是痛苦的事情，每每須要停機維護和數據遷移。

對網站來講，關係型數據庫的不少特性再也不須要了：

• 事務一致性

關係型數據庫在對事物一致性的維護中有很大的開銷，而如今不少web2.0系統對事物的讀寫一致性都不高

• 讀寫實時性

對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性，好比發一條消息以後，過幾秒乃至十幾秒以後纔看到這條動態是徹底能夠接受的

• 複雜SQL，特別是多表關聯查詢

任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品階級角度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了

在關係型數據庫中，致使性能欠佳的最主要緣由是多表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢。爲了保證數據庫的ACID特性，咱們 必須儘可能按照其要求的範式進行設計，關係型數據庫中的表都是存儲一個格式化的數據結構。每一個元組字段的組成都是同樣，即便不是每一個元組都須要全部的字段， 但數據庫會爲每一個元組分配全部的字段，這樣的結構能夠便於標語表之間進行連接等操做，但從另外一個角度來講它也是關係型數據庫性能瓶頸的一個因素。

3. NoSQL

NoSQL一詞首先是Carlo Strozzi在1998年提出來的，指的是他開發的一個沒有SQL功能，輕量級的，開源的關係型數據庫。這個定義跟咱們如今對NoSQL的定義有很大的 區別，它確確實實字如其名，指的就是「沒有SQL」的數據庫。可是NoSQL的發展慢慢偏離了初衷，咱們要的不是「no sql」，而是「no relational」，也就是咱們如今常說的非關係型數據庫了。

2009年初，Johan Oskarsson舉辦了一場關於開源分佈式數據庫的討論，Eric Evans在此次討論中再次提出了NoSQL一詞，用於指代那些非關係型的，分佈式的，且通常不保證遵循ACID原則的數據存儲系統。Eric Evans使用NoSQL這個詞，並非由於字面上的「沒有SQL」的意思，他只是以爲不少經典的關係型數據庫名字都叫「**SQL」,因此爲了表示跟這些關係型數據庫在定位上的大相徑庭，就是用了「NoSQL「一詞。

注：數據庫事務必須具有ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔離性，Durability持久性。

非關係型數據庫提出另外一種理念，例如，以鍵值對存儲，且結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長一些本身的鍵值對，這 樣就不會侷限於固定的結構，能夠減小一些時間和空間的開銷。使用這種方式，用戶能夠根據須要去添加本身須要的字段，這樣，爲了獲取用戶的不一樣信息，不須要 像關係型數據庫中，要對多表進行關聯查詢。僅須要根據id取出相應的value就能夠完成查詢。但非關係型數據庫因爲不多的約束，他也不可以提供像SQL 所提供的where這種對於字段屬性值狀況的查詢。而且難以體現設計的完整性。他只適合存儲一些較爲簡單的數據，對於須要進行較複雜查詢的數據，SQL數 據庫顯的更爲合適。

4. 關係型數據庫  V.S.  非關係型數據庫

關係型數據庫的最大特色就是事務的一致性：傳統的關係型數據庫讀寫操做都是事務的，具備ACID的特色，這個特性使得關係型數據庫能夠用於幾乎全部對一致性有要求的系統中，如典型的銀行系統。

可是，在網頁應用中，尤爲是SNS應用中，一致性卻不是顯得那麼重要，用戶A看到的內容和用戶B看到同一用戶C內容更新不一致是能夠容忍的，或者 說，兩我的看到同一好友的數據更新的時間差那麼幾秒是能夠容忍的，所以，關係型數據庫的最大特色在這裏已經無用武之地，起碼不是那麼重要了。

相反地，關係型數據庫爲了維護一致性所付出的巨大代價就是其讀寫性能比較差，而像微博、facebook這類SNS的應用，對併發讀寫能力要求極 高，關係型數據庫已經沒法應付(在讀方面，傳統上爲了克服關係型數據庫缺陷，提升性能，都是增長一級memcache來靜態化網頁，而在SNS中，變化太 快，memchache已經無能爲力了)，所以，必須用新的一種數據結構存儲來代替關係數據庫。

關係數據庫的另外一個特色就是其具備固定的表結構，所以，其擴展性極差，而在SNS中，系統的升級，功能的增長，每每意味着數據結構巨大變更，這一點關係型數據庫也難以應付，須要新的結構化數據存儲。

因而，非關係型數據庫應運而生，因爲不可能用一種數據結構化存儲應付全部的新的需求，所以，非關係型數據庫嚴格上不是一種數據庫，應該是一種數據結構化存儲方法的集合。

必須強調的是，數據的持久存儲，尤爲是海量數據的持久存儲，仍是須要一種關係數據庫這員老將。

5. 非關係型數據庫分類

因爲非關係型數據庫自己自然的多樣性，以及出現的時間較短，所以，不想關係型數據庫，有幾種數據庫可以一統江山，非關係型數據庫很是多，而且大部分都是開源的。

這些數據庫中，其實實現大部分都比較簡單，除了一些共性外，很大一部分都是針對某些特定的應用需求出現的，所以，對於該類應用，具備極高的性能。依據結構化方法以及應用場合的不一樣，主要分爲如下幾類：

• 面向高性能併發讀寫的key-value數據庫：

key-value數據庫的主要特色即便具備極高的併發讀寫性能，Redis,Tokyo Cabinet,Flare就是這類的表明

• 面向海量數據訪問的面向文檔數據庫：

這類數據庫的特色是，能夠在海量的數據中快速的查詢數據，典型表明爲MongoDB以及CouchDB

• 面向可擴展性的分佈式數據庫：

這類數據庫想解決的問題就是傳統數據庫存在可擴展性上的缺陷，這類數據庫能夠適應數據量的增長以及數據結構的變化

 

1.實質。
非關係型數據庫的實質：非關係型數據庫產品是傳統關係型數據庫的功能閹割版本，經過減小用不到或不多用的功能，來大幅度提升產品性能。
2.價格。
目前基本上大部分主流的非關係型數據庫都是免費的。而比較有名氣的關係型數據庫，好比Oracle、DB二、MSSQL是收費的。雖然Mysql免費，但它須要作不少工做才能正式用於生產。
3.功能。
實際開發中，有不少業務需求，其實並不須要完整的關係型數據庫功能，非關係型數據庫的功能就足夠使用了。這種狀況下，使用性能更高、成本更低的非關係型數據庫固然是更明智的選擇。

關係型數據庫經過外鍵關聯來創建表與表之間的關係，非關係型數據庫一般指數據以對象的形式存儲在數據庫中，而對象之間的關係經過每一個對象自身的屬性來決定

 

關係型數據庫和非關係型數據庫應該怎樣選擇?

1.RDBMS都使用的比較多了,最近些年NoSQL也發展的比較快,相關的介紹:http://nosql-database.org/
2.至於如何選擇,我以爲更多的仍是看他們的區別和適用的場景,我建議混合使用,發揮每種數據庫的優勢;
3.其實這個問題能夠轉變成關係型數據庫和非關係型數據庫的差別和特色:
(1)關係型數據庫的最大特色就是事務的一致性:傳統的關係型數據庫讀寫操做都是事務的,具備ACID的特色,這個特性使得關係型數據庫能夠用於幾乎全部對一致性有要求的系統中;因此說必須強調的是,數據的持久存儲,尤爲是海量數據的持久存儲;
優勢:

1)容易理解:二維表結構是很是貼近邏輯世界的一個概念,關係模型相對網狀,層次等其餘模型來講更容易理解;

2)使用方便:通用的SQL語言使得操做 關係型數據庫很是方便;

3)易於維護:豐富的完整性(實體完整性,參照完整性和用戶定義的完整性)大大減低了數據冗餘和數據不一致的機率;
瓶頸:

1)高併發讀寫需求;2)海量數據的高效率讀寫;3)高擴展性和可用性
(2)可是有不少不須要關係型數據庫的特性場景,能夠採用NoSQLs:
1)數據模型比較簡單;
2)要靈活性更強的IT系統;
3)對數據庫性能要求較高;
4)不須要高度的數據一致性;
5)對於給定key,比較容易映射覆雜值的環境;

 

 

什麼是SQL

SQL指結構化查詢語言,是一門ANSI(美國國家標準學會)標準的計算機語言,主要用來訪問和操做數據庫系統.某些關係型數據庫要求在每一個SQL 命令的末端使用分號，如MySQL（若不在命令末尾使用分號則報錯），若是使用的關係型數據庫是MS SQL Server或者SQL Server ，則不須要在每一個SQL命令末端使用分號。

RDBMS

RDBMS指的是關係型數據庫管理系統,RDBMS是SQL的基礎,一樣也是不少如今關係型數據庫的基礎,RDBMS的數據是存儲在被稱爲表的數據庫對象中,表是相關數據項的集合,由行和列組成,這也是關係型數據的典型特徵.

DML和DDL

SQL分爲兩個部分：數據操做語言（DML）和數據定義語言（DDL）。

DML主要用於執行查詢，更新，插入和刪除的語法。SQL主要的DML語句有：

1）SELECT ----從數據庫表中獲取數據

2）UPDATE ----更新數據庫表的數據

3）DELETE ----從數據庫表中刪除數據

4）INSERT INTO ----向數據表中插入數據

DDL主要建立和刪除數據庫或者表格，也能夠定義索引（鍵），規定表之間的連接以及施加表間的約束。主要的DDL語句有：

1）CREATE DATABASE ----建立新數據庫

2）ALTER DATABASE ----修改數據庫

3）CREATE TABLE ----建立新表

4）ALTER TABLE ----變動數據庫表

5）DROP TABLE ----刪除表

6）DROP DATABASE ----刪除數據庫

7）CREATE INDEX ----建立索引（搜索鍵）

8）DROP INDEX ----刪除索引   

主流的關係型數據庫

Microsoft SQLServer,  IBM DB2,  Oracle, MySQL，  Microsoft Access，  Sybase，IBM Informix.

NoSQL

NoSQL,指的是非關係數據庫。由上面的敘述能夠看到關係型數據庫中的表都是存儲一下格式化的數據結構，每一個元組字段的組成都是同樣的，即便不是 每一個元組都須要全部的字段，但數據庫會爲每一個元組都分配全部的字段，這樣的結構能夠便於表與表之間進行鏈接等操做，但從另外一個角度來講它也是關係數據庫性 能瓶頸的一個因素。而非關係數據庫以鍵值對存儲，它的結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長或減小一些本身的鍵值對，這樣 就不會侷限於固定的結構，能夠減小一些時間和空間的開銷。

NoSQL有那些

MangoDB，Membase，Hypertale，Apache Cassandra，BigTable，CouchDB，dynamoDB，SimpleDB, HBase（HadoopDatabase） ,Redis

 

 

 非關係數據庫只實現了關係數據庫一部分的功能，但所以很大程度上擴充了某些功能的性能。通常用關係數據庫就夠了。嚴格說mysql在關係數據庫兄是實現得 也不是很完整的一類，從而在某些查詢上，mysql有超出嚴格關係數據庫不少的性能。具體應用須要權衡，特別是關聯條件不少的數據，非關係數據庫通常不合 適，有時候甚至mysql也不合適。

 

 

非關係型數據庫MongoDB
隨着如今分佈式數據庫的崛起,部分的項目的後臺已經漸漸的時候這種非關係型的數據庫來設計了,那麼這種數據庫有什麼樣的有點呢?
(1) 大 家都知道後期的數據庫將是很是龐大的一個東西,好多的項目都是使用的關係型的數據庫來支撐的,他們無疑是一個很是不錯的選擇,要考慮到後期程序的運行的效 率,那時候你們就會考慮使用程序來實現數據庫的分佈(或者使用很是好的服務器來支撐),可是後期發現的mongo確實能夠幫助你們解決這種分佈式所帶來的 問題,mongo在設計出就是考慮到了這些問題,你只需創建一些引用的關係方可實現。 (2) Mongo 是一種面向對象的數據庫，因此很適合面向對象的這種語言來使用(必須C#,java等高級語言),它本來只是被人們用來作緩存使用的數據庫,就和 android的內置的sqlite同樣,可是這並不會影響它的強大的鋒芒,他們發現他們設計的這種思想很是的可貴,就加以發展,也就是咱們如今看到的 mongoDB。 (3) 強大的查詢功能,mongo中的查詢能夠使用Pattern來查詢,數據存儲的時候能夠存儲json格式的數據,固然咋們查詢的時候就能夠xx.xx.xx=xxx這樣的格式來匹配json格式的字段了。 (4) Mongo因爲是非關係型的數據庫,因此字段的存儲也是很是的隨便的,關係型數據庫在設計的時候通常就會把全部的字段都肯定好了,可是mongo不同,在設計的時候先後臺約定好哪些字段爲必要的字段和類型。那麼前臺即可以很靈活的傳一些字段到後臺來。 (5) 可是mongo也有不少的缺點的,相對關係型數據庫mongo的設計很是的複雜,甚至一個表中會出現多個表的引用並且這些引用都是多對多的關係，然而關係型數據庫設計的時候一般會把多對多的關係轉化爲兩個一對多來實現的。 (6) Hibernate框架，好比咱們在開發jsp的一些項目的時候，能夠使用到hibernate框架來影射數據庫中的表與表之間的關係，可是mongo是作不到的，因此當設計到操做到多張表的時候就要本身動手敲代碼了。(我作多寫一個API寫了300行涉及到了五張表聯合操做,好多方法還封裝了)。 (7) Mongo的存儲很是的隨便也致使了一些缺點，插入數據的時候字段能夠隨便的加沒有任何的約束

(1) 當需求提出來的時候，關係型數據庫是經過主外鍵的關係來關聯多張表的，雖然mongo中沒有明顯的主外鍵的關係可是咱們能夠經過對數據庫的設計來實現這樣 的關係。 Example：一個團隊下面能夠有多個業務可是一個業務只能歸屬一個團隊。 咱們能夠這樣設計，在業務表中加一個字段teamId類型爲DBRef引用的類型，而團隊的表中加一個字段taskId類型是一個 List<DBRef>的類型，這樣就能夠體現了團隊和業務是一對多的關係了。 擴展：若是團隊和業務的關係是多對多的關係的話，咱們能夠將業務中的teamId也換成List<DBRef>來方團隊ID的引用集合。
(2) 關係型數據庫在存放數據的時候儘可能的作到分開來存放，可是mongo卻不是這樣的，設計的時候最好是遵循執行增長操做的時候繁瑣一點不要緊，可是查詢的時候必定要簡單，畢竟查詢是sql語句中最長使用的。

 

從關係型數據庫到非關係型數據庫

　　自1970年，埃德加·科德提出關係模型以後，關係數據庫便開始出現，通過了 40多年的演化，現在的關係型數據庫具有了強大的存儲、維護、查詢數據的能力。但在關係數據庫日益強大的時候，人們發現，在這個信息爆炸的「大數據」時 代，關係型數據庫遇到了性能方面的瓶頸，面對一個表中上億條的數據，SQL語句在大數據的查詢方面效率欠佳。咱們應該知道，每每添加了越多的約束的技術， 在必定程度上定會拖延其效率。

       在1998年，Carlo Strozzi提出NOSQL的概念，指的是他開發的一個沒有SQL功能，輕量級的，開源的關係型數據庫。注意，這個定義跟咱們如今對NoSQL的定義有 很大的區別，它確確實實字如其名，指的就是「沒有SQL」的數據庫。可是NoSQL的發展慢慢偏離了初衷，CarloStrozzi也發覺，其實咱們要的 不是"nosql"，而應該是"norelational"，也就是咱們如今常說的非關係型數據庫了。

       在關係型數據庫中，致使性能欠佳的最主要因素是多表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢。 爲了保證數據庫的ACID特性，咱們必須儘可能按照其要求的範式進行設計，關係型數據庫中的表都是存儲一些格式化的數據結構，每一個元組字段的組成都同樣，即 使不是每一個元組都須要全部的字段，但數據庫會爲每一個元組分配全部的字段，這樣的結構能夠便於表與表之間進行鏈接等操做，但從另外一個角度來講它也是關係型數 據庫性能瓶頸的一個因素。

       非關係型數據庫提出另外一種理念，他以鍵值對存儲，且結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長一些本身的鍵值對， 這樣就不會侷限於固定的結構，能夠減小一些時間和空間的開銷。使用這種方式，用戶能夠根據須要去添加本身須要的字段，這樣，爲了獲取用戶的不一樣信息，不需 要像關係型數據庫中，要對多表進行關聯查詢。僅須要根據id取出相應的value就能夠完成查詢。但非關係型數據庫因爲不多的約束，他也不可以提供想 SQL所提供的where這種對於字段屬性值狀況的查詢。而且難以體現設計的完整性。他只適合存儲一些較爲簡單的數據，對於須要進行較複雜查詢的數 據，SQL數據庫顯得更爲合適。

       目前出現的NoSQL(Not only SQL，非關係型數據庫)有不下於25種，除了Dynamo、Bigtable之外還有不少，好比Amazon的SimpleDB、微軟公司的 AzureTable、Facebook使用的Cassandra、類Bigtable的Hypertable、Hadoop的HBase、 MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。這些NoSQL各有特點，是基於不一樣應用場景而開發的，而其中以 MongoDB和Redis最爲被你們追捧。

       如下是MongoDB的一些狀況：

　　MongoDB是基於 文檔的存儲的（而非表），是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散， 是相似json的bjson格式，所以能夠存儲比較複雜的數據類型。模式自由(schema-free)，意味着對於存儲在MongoDB數據庫中的文 件，咱們不須要知道它的任何結構定義。若是須要的話，你徹底能夠把不一樣結構的文件存儲在同一個數據庫裏。Mongo最大的特色是他支持的查詢語言很是強 大，其語法有點相似於面向對象的查詢語言，幾乎能夠實現相似關係數據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。

       Mongo主要解決的是海量數據的訪問效率問題。由於Mongo主要是支持海量數據存儲的，因此Mongo還自帶了一個出色的分佈式文件系統 GridFS，能夠支持海量的數據存儲。因爲Mongo能夠支持複雜的數據結構，並且帶有強大的數據查詢功能，所以很是受到歡迎。

 

 自1970年，埃德加·科德提出關係模型以後，關係數據庫便開始出現，通過了40多年的演化，現在的關係型數據庫具有了強大的存儲、維護、查詢數據的 能力。但在關係數據庫日益強大的時候，人們發現，在這個信息爆炸的「大數據」時代，關係型數據庫遇到了性能方面的瓶頸，面對一個表中上億條的數據，SQL 語句在大數據的查詢方面效率欠佳。咱們應該知道，每每添加了越多的約束的技術，在必定程度上定會拖延其效率。

       在1998年，Carlo Strozzi提出NOSQL的概念，指的是他開發的一個沒有SQL功能，輕量級的，開源的關係型數據庫。注意，這個定義跟咱們如今對NoSQL的定義有 很大的區別，它確確實實字如其名，指的就是「沒有SQL」的數據庫。可是NoSQL的發展慢慢偏離了初衷，CarloStrozzi也發覺，其實咱們要的 不是"nosql"，而應該是"norelational"，也就是咱們如今常說的非關係型數據庫了。

       在關係型數據庫中，致使性能欠佳的最主要因素是多表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢。 爲了保證數據庫的ACID特性，咱們必須儘可能按照其要求的範式進行設計，關係型數據庫中的表都是存儲一些格式化的數據結構，每一個元組字段的組成都同樣，即 使不是每一個元組都須要全部的字段，但數據庫會爲每一個元組分配全部的字段，這樣的結構能夠便於表與表之間進行鏈接等操做，但從另外一個角度來講它也是關係型數 據庫性能瓶頸的一個因素。

       非關係型數據庫提出另外一種理念，他以鍵值對存儲，且結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長一些本身的鍵值對， 這樣就不會侷限於固定的結構，能夠減小一些時間和空間的開銷。使用這種方式，用戶能夠根據須要去添加本身須要的字段，這樣，爲了獲取用戶的不一樣信息，不需 要像關係型數據庫中，要對多表進行關聯查詢。僅須要根據id取出相應的value就能夠完成查詢。但非關係型數據庫因爲不多的約束，他也不可以提供想 SQL所提供的where這種對於字段屬性值狀況的查詢。而且難以體現設計的完整性。他只適合存儲一些較爲簡單的數據，對於須要進行較複雜查詢的數 據，SQL數據庫顯得更爲合適。

       目前出現的NoSQL(Not only SQL，非關係型數據庫)有不下於25種，除了Dynamo、Bigtable之外還有不少，好比Amazon的SimpleDB、微軟公司的 AzureTable、Facebook使用的Cassandra、類Bigtable的Hypertable、Hadoop的HBase、 MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。這些NoSQL各有特點，是基於不一樣應用場景而開發的，而其中以 MongoDB和Redis最爲被你們追捧。

       如下是MongoDB的一些狀況：

　　MongoDB是基於 文檔的存儲的（而非表），是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散， 是相似json的bjson格式，所以能夠存儲比較複雜的數據類型。模式自由(schema-free)，意味着對於存儲在MongoDB數據庫中的文 件，咱們不須要知道它的任何結構定義。若是須要的話，你徹底能夠把不一樣結構的文件存儲在同一個數據庫裏。Mongo最大的特色是他支持的查詢語言很是強 大，其語法有點相似於面向對象的查詢語言，幾乎能夠實現相似關係數據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。

       Mongo主要解決的是海量數據的訪問效率問題。由於Mongo主要是支持海量數據存儲的，因此Mongo還自帶了一個出色的分佈式文件系統 GridFS，能夠支持海量的數據存儲。因爲Mongo能夠支持複雜的數據結構，並且帶有強大的數據查詢功能，所以很是受到歡迎。

 

 

 

關係型數據庫和非關係型數據庫的選擇，以及替代方法(mysql替代mongodb)

我作的項目由於涉及到大量的歷史數據增長而採用的非關係型數據（mongodb），可是在實際開過程當中遇到了不少問題，有開發方面的，也有管理方面的，因而我思考了 用關係型數據庫mysql代替非關係型數據庫mongodb的思路 。

目前尚未實施，由於對項目的改動會很大，但願你們能看看個人思路，最好能提一些意見，謝謝各位了。

方案的 核心 在於 將目前一個數據庫分割爲兩個數據庫，一個當前交易庫，一個歷史數據查詢庫 。

---------------------------詳細方案以下----------------------------------

創建兩個mysql數據庫，一個是當前業務庫叫bussDB，一個是數據中心庫叫datacenterDB。

 兩個數據庫如何運做： 

一、datacenterDB庫和bussDB庫表結構基本徹底一致。bussDB庫存放正在進行的交易，datacenterDB庫存放當前正在進行的交易和全部歷史交易。
二、業務後臺管理系統和業務前臺網站都直接鏈接bussDB庫進行正常業務操做。
三、歷史查詢、分析統計系統鏈接datacenterDB庫進行查詢統計。
四、bussDB庫按照適合oltp(交易型)的庫進行數據庫存儲和建模的優化。
五、datacenterDB庫按照適合olap(分析型、數據倉庫)的庫進行數據庫存儲和建模的優化，能夠使用表分區和集羣等技術。
六、天天晚上，自動定時經過ETL工具（數據庫同步工具）將bussDB庫中的信息自動同步到datacenterDB庫中。
七、設置程序自動在交易完成後180天之後將交易信息清除，清除以後關於該交易的查詢在datacenterDB庫中查詢。

爲何要分爲兩個數據庫：

一、適合交易的數據庫和適合分析的數據庫建模有必定區別，bussDB是交易型，而datacenterDB是查詢分析型。
二、bussDB庫須要保證快速響應，不由於歷史數據的不斷增大而影響速度，所以須要按期清除數據和數據轉存。
三、bussDB庫是一個事務型的數據庫，須要保證事務完整性，所以不適合作集羣，應採起垂直擴展（高性能服務器）。
四、datacenterDB庫是一個數據倉庫的數據庫，須要集羣和水平擴展（廉價PC，作集羣）。

  爲何要用關係型數據庫而不用非關係型數據庫。

一、在以上方式設計的bussDB庫的狀態下，對於增刪改查操做，關係型數據庫和非關係型數據庫的性能開銷基本一致，由於全部表的數據量都很是小，小於百萬級，由於在千萬級數據量如下，關係型數據庫只要設置了索引，都是很是快的。
二、在性能方面一致的狀況下，非關係數據庫的缺點在於沒法支持動態鏈接查詢應用，即sql中的join操做，或者說是join效率不如關係型數據庫高，另 外也不支持分組(group)和統計操做(count/sum/avg等)，在業務系統中存在大量的join操做，好比，報表打印、銀行繳費對帳、員工、 機構、角色、交易、科目、字典等複雜應用都涉及到大量關聯，因此非關係型數據庫在這些處理方面不如關係型數據庫靈活和性能高，編寫的代碼可讀性和健壯性也 較低。
三、關係型數據庫的管理工具好比sqlyong，比非關係型數據庫的管理工具更豐富，也更完善。對於數據庫的DBA維護而言，關係型數據庫的批量更新、導入、導出、備份、優化等方式和資料都豐富，對於開發人員的入門門檻，關係型數據庫也比較低。
四、關係型數據庫的發展歷史和穩定性要超過非關係型數據庫。
五、既然在性能一致的狀況下爲何不用關係型數據庫呢。
六、datacenterDB庫就必須是用關係型數據庫了，由於datacenterDB大量的統計應用都是基於sql中的統計函數的，好比查詢交易業務 性別比例、學歷分佈等，都涉及到sql操做，好比，join,group by xxx,sum(),count(),avg()等，這些都是非關係型數據庫不支持的。

 

 

 1.NoSQL與關係型數據庫設計理念比較

 關係型數據庫中的表都是存儲一些格式化的數據結構，每一個元組字段的組成都同樣，即便不是每一個元組都須要全部的字段，但數據庫會爲每一個元組分配全部的字段，這樣的結構能夠便於表與表之間進行鏈接等操做，但從另外一個角度來講他也是關係型數據庫性能瓶頸的一個因素。

非關係型數據庫以鍵值對存儲，他的結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長一些本身的鍵值對，這樣就不會侷限於固定的結構可 以減小一些時間和空間的開銷。非關係型數據庫的要點是非關係的、分佈式的、水平可擴展的，具備模式自由、支持簡易複製、簡單的API、最終一致性、大容量 數據等特性。除此以外還有文檔型、列存儲型、圖形數據庫、XML數據庫等。

 

2.優缺點：

相對關係型數據庫，NoSQL具備如下優勢：

1）數據存儲非結構化。非關係型數據庫以鍵值對存儲，它的結構不固定，每個元組能夠有不同的字段，每一個元組能夠根據須要增長本身的鍵值對，這樣能夠構造不固定的結構，從而減小時間和空間的開銷。 2）可以運行在便宜的PC服務器集羣上，能夠經過物理性PC集羣數據庫服務器節點的擴充實現數據庫水平拓展，使數據庫擁有良好的橫向和縱向擴展能力。

3）可以適應現代網絡對數據庫高併發讀寫請求以及對海量數據的高速訪問能力。

 

 

關係型和非關係型數據庫——學習筆記

關係數據庫（英語：Relational database），是建立在關係模型基礎上的數據庫，藉助於集合代數等數學概念和方法來處理數據庫中的數據。現實世界中的各類實體以及實體之間的各類聯 系均用關係模型來表示。關係模型是由埃德加·科德於1970年首先提出的，並配合「科德十二定律」。現現在雖然對此模型有一些批評意見，但它仍是數據存儲 的傳統標準。標準數據查詢語言SQL就是一種基於關係數據庫的語言，這種語言執行對關係數據庫中數據的檢索和操做。
關係模型由關係數據結構、關係操做集合、關係完整性約束三部分組成。
實體關係模型:實體關係模型（Entity-Relationship Model），簡稱E-R Model，是陳品山（Peter P.S Chen）博士於1976年提出的一套數據庫的設計工具，他運用真實世界中事物與關係的觀念，來解釋數據庫中的抽象的數據架構。實體關係模型利用圖形的方 式（實體-關係圖（Entity-Relationship Diagram））來表示數據庫的概念設計，有助於設計過程當中的構思及溝通討論。
關係操做:
1）數據查詢:
   A.選擇
   B.投影
   C.鏈接
   D.並
   E.交
   F.差
   G.除 2）數據操做:
   A.增長
   B.刪除
   C.修改
   E.查詢
完整性約束包括：
   1）實體完整性
   2）參照完整性

   3）用戶定義完整性

關係型數據庫的特色：
   1）關係型數據庫的最大特色就是事物的一致性，爲了維護一致性所付出的巨大代價就是讀寫性能比較差
   2）具備固定的表結構，擴展性差
   3）數據的持久化須要關係型數據庫
非關係型數據庫：NoSQL，有時也稱做Not Only SQL的縮寫，NoSQL不使用SQL做爲查詢語言。其數據存儲能夠不須要固定的表格模式，也常常會避免使用SQL的JOIN操做，通常有水平可擴展性的 特徵。NoSQL的實現具備二個特徵：使用硬盤，或者把隨機存儲器做存儲載體。 主要分爲一下幾類：    1）面向高性能併發讀寫的Key-Value數據庫：Key-Value數據庫的主要特色就是具備極高的併發讀寫性能，Redis,Tokyo Cabinet,Flare就是這類的表明。    2）面向海量數據訪問的面向文檔數據庫：這類數據庫的特色是，能夠在海量的數據中快速的查詢數據。典型表明爲MongoDB以及CouchDB。

   3）面向可擴展性的分佈式數據庫：這類數據庫想解決的問題就是傳統數據庫在可擴展性上的缺陷，這類數據庫能夠適應數據量的增長以及數據結構的變 化，Google Appengine的Big Table就是這類的典型表明，而且，BigTable特別適用於Map Reduce處理。

參考：

http://zh.wikipedia.org/wiki/NoSQL

http://zh.wikipedia.org/wiki/%E9%97%9C%E8%81%AF%E5%BC%8F%E8%B3%87%E6%96%99%E5%BA%AB

http://www.sigma.me/2011/06/11/intro-to-nosql.html

 

 

 

 

非關係型數據庫NoSQL的崛起

2012年12月06日15:45騰訊科技[微博]童雲我要評論(0)

字號： T|T

[導讀]《連線》雜誌對NoSQL的歷史進行了追溯。介紹了最古老的NoSQL數據庫之一CouchDB，創造者達卡茨的故事有助於幫助解釋NoSQL運動的興起，和這種數據庫與競爭者的巨大的差別。

CouchDB的創造者達米安·卡茨（騰訊科技配圖）

騰訊科技訊（童 雲）北京時間12月6日消息，《連線》雜誌網絡版近日刊載文章，對NoSQL（非關係型數據庫）的來源與歷史進行了追溯。文章主要介紹了最古老的 NoSQL數據庫之一CouchDB，這種數據庫的創造者達米安·卡茨受到了在線協做平臺Lotus Notes的啓發，他的故事有助於幫助解釋NoSQL運動的興起，及爲什麼這種數據庫與以往的數據庫存在如此巨大的差別。

如下是這篇文章的全文：

在追溯NoSQL運動的源頭時，大多數互聯網人士都會想到谷歌(微博)和亞馬遜。

隨 着自身網絡服務日益取得巨大而成功的增加，谷歌和亞馬遜須要新的方法來存儲不斷增長的服務器所帶來的數量龐大的數據，因而兩家公司都爲此而創造了一個新的 軟件平臺——谷歌構建了BigTable平臺，而亞馬遜則構建了Dynamo平臺。在這兩家互聯網巨頭髮布研究論文來描述其各自的數據存儲平臺之後，其餘 許多公司也都尋求進行復制。

其結果是，一支NoSQL（非關係型數據庫）「大軍」就此產生，這種數據庫是專爲在數千臺服務器之間運做而設計的。這些新時代的軟件平臺——包括Cassandra、HBase和Riak等——對數據庫市場進行了改造，不只有助於Facebook和Twitter等諸多互聯網巨頭的運做，同時也涵蓋了更多的傳統業務。

「如 果你看看市場上全部的NoSQL解決方案，那麼就會發現每一種解決方案都能追溯至亞馬遜Dynamo論文或谷歌BigTable論文。」雲計算公司 Joyent首席技術官賈森·霍夫曼（Jason Hoffman）說道。「若是谷歌或是亞馬遜沒人曾寫過一份學術報告（來描述NoSQL平臺）的話，那麼今天的世界將會是個什麼樣子呢？」

好 吧，若是真是那樣，那麼世界還將擁有另外一種最古老的NoSQL數據庫之一，那就是CouchDB。CouchDB的創造者達米安·卡茨（Damian Katz）並未受到谷歌、亞馬遜或是其餘任何網絡巨頭的啓發，而是受到了在線協做平臺Lotus Notes的啓發，這個平臺最初是在二十世紀七十年代和八十年代開發的。

雖然 Lotus Notes以身爲一個電子郵件系統而聞名於世，但事實上它並不是只是個電郵系統，同時仍是構建依賴於數據庫的應用的基礎——換句話說，是有組織的信息集合。 經過使用Lotus Notes這個平臺，企業能構建從開支申報應用到IT幫助桌面工具等全部東西。卡茨就是構建這種應用的人之一，他從1995年開始就爲Lotus開發 Notes應用。他表示，即便是在那時，這個平臺也已經展現出一些特性，而正是這些特性讓今天的NoSQL數據庫取得了如此之大的成功。

正 如其餘NoSQL後繼者同樣，Lotus Notes也一樣來自於關係數據庫的「領地」。關係數據庫是創建在關係數據庫模型基礎上的傳統數據庫，藉助於集合代數等概念和方法來處理數據庫中的數據。 「那是一個複雜的系統，能經過關係數據庫讓本來難以作到的事情變得簡單。」卡茨說道。

從 不少方面來講，卡茨的故事都有助於幫助解釋NoSQL運動的興起——以及爲什麼這種數據庫與以往的數據庫存在如此巨大的差別。雖然這場運動毫無疑問是取得了 成功，但NoSQL數據庫的概念仍舊很難肯定下來——「NoSQL意味着如此之多且各有不一樣的事情，要看你正在討論什麼而定。」谷歌傑出工程師安德魯·菲 克斯（Andrew Fikes）最近曾這樣對咱們說道——在整個科技行業中，還有不少人還沒有把握到這些新數據庫的重要性。

「NoSQL」 其實該算是用詞不當，由於NoSQL數據庫並非爲了摒棄SQL（Structured Query Language，結構化查詢語言，這是一種數據庫查詢和程序設計語言，用於存取數據以及查詢、更新和管理關係數據庫系統，同時也是數據庫腳本文件的擴展 名）；更好的名稱原本應該是「non-relational database」（非關係型數據庫）。NoSQL數據庫不使用爲關係數據庫提供支撐的整齊數據圖表。

NoSQL數據庫擁有兩種基本特性：首先，這種數據庫能在許多服務器之間延展——容許用戶在必要時候擴大運算，甚至是在不一樣的地理位置之間也能夠——其次，這種數據庫能給用戶帶來按本身喜歡的方式架構數據的自由度，正是這第二個特性與Lotus Notes很是類似。

柏拉圖式的理想

Notes 平臺是受PLATO Notes的啓發而創造出來的，後者是一個在伊利諾斯大學PLATO主機上運行的在線社區。PLATO Notes的創造者大衛·伍利（David R. Woolley）曾在1994年寫道，這個項目始於1973年，當時還只是一個簡單的報錯系統。在最開始的時候，人們經過編輯一個文本文件的方式來報錯， 但這種方式帶來了一些問題。

「那樣作根本沒有安全性可言，想要確切地知道是誰寫了一份報錯文件是不可能作到的。」伍利說道。「大多數人都會報錯時簽上名字或至少是名字的首字母縮寫，但沒有什麼東西能強制他們這樣去作。有些時候，會有愛開玩笑的人以爲，刪除整個文件是件頗有意思的事情。」

因 此，當時年僅17歲的伍利就被分配到了一項任務，那就是創造一個更具結構性的系統來報錯。他開發出來的工具容許用戶將其報錯報告輸入到一個應用中去，該應 用會把報告保存爲文本文件，並加上用戶的姓名和提交日期。而後，支持部門的員工能分屏顯示和查看這些文件，就像咱們今天的電子郵件客戶端同樣：報錯報告列 表在上面，報告文本在底下。

隨後，全部這些信息會被保存爲一個大的文本文件，而不是關係數據庫。今天，咱們將其稱爲「文件數據庫」（document database）。

你能夠把一個關係數據庫看做一個龐大的電子表格，數據以圖表、行和列的方式組織起來。若是你想要增長一個域，那麼就新增一列，這一列會在表格的每一行中出現，從而讓你的數據變得結構化和統一化，但管理許多無結構性的數據或是以多種方式構建結構的數據則要困難一些。

文件數據庫更像是文件的集合，每個「入口」都是一個文件，並且都能擁有本身的結構。若是你想要對一個「入口」添加一個域，那麼這樣作的同時不會對其餘任何「入口」形成影響。

不久之後，PLATO開發者就添加了更多的Notes應用。到二十世紀七十年代末，他們擁有了一個電子郵件應用，一個通常用途留言板，以及網絡遊戲等，諸如此類。

在 1984年，雷·奧茲（Ray Ozzie）——一名Lotus開發者，在伊利諾斯大學上學時曾在PLATO工做過——離開了Louts，本身開創了一家名爲Iris Associates的公司。隨後，Lotus對這家公司進行了投資，雙方簽署了一項協議，內容是Lotus將擁有使用Iris旗艦產品的獨家權利：一個 基於PLATO的企業用系統。

時至今日，許多人都認爲Lotus Notes是一個過期的系統，應該像WordPerfect和Novell Netware那樣被扔進同一個垃圾桶。可是，Notes爲它以後的幾乎全部類型的企業通訊和協做應用鋪平了道路，從微軟Outlook電子郵件客戶端到Jive Software等社交網絡工具再到CouchDB數據庫都是如此。

卡茨與CouchDB

1995年時，卡茨以夏季實習生的身份加入Lotus；大約就在同一時間，Lotus被IBM收購。卡茨在Lotus Notes顧問部門工做了一段時間，而後又回到這家公司，加入了Iris團隊，當時Iris已被Lotus正式收購。

在 Iris，卡茨對Lotus Notes的精髓做出了改進。他重寫了爲Formula提供支持的引擎，這是用來開發Notes應用的腳本語言。卡茨表示，當時他遠不能勝任這項工做，但 他同時認爲本身天生就是要寫代碼的人。「每完成一個@function，我就跟打了一針毒品似的；我就像是個癮君子，在不停地尋找下一個須要修補的地 方。」他後來在本身的博客中這樣寫道。

卡茨在2005年離開Lotus，加盟了一家名 爲Koobie的創業公司；但在不久之後，他就啓動了一項事業，目標是將Lotus Notes的思潮帶入現代社會，這最終演變成了CouchDB。卡茨曾在一篇早期的博客中談到這個項目，當時他寫道：「Couch就是爲網絡而從頭開始構 建的Lotus Notes。」

最第一版本的CouchDB使用一種相似於 Formula的編程語言，但不久之後卡茨就帶領這個項目走向了新的方向，從平臺轉變成了一個專用的數據庫。「MySQL是其人氣度達到頂峯的產物。」卡 茨說道。「當時若是你告訴人們說，你在開發某種相似於Lotus Notes的東西，那麼就會讓他們發出驚歎的聲音。」

在 這條發展的道路上也存在很多坎坷。在2007年初，卡茨到了Sun Microsystems的MySQL團隊工做，放棄了構建CouchDB的工做。可是，這個開源項目吸引了其餘的開發者堅持不懈地爲之努力，其中著名的 有詹·雷納德（Jan Lehnardt）和諾亞·斯萊特（Noah Slater）等。斯萊特推出了JSON，在當時以文本文件來對數據進行結構化的新格式。在Sun休陪產假時，卡茨最後替換了整個CouchDB存儲引 擎，用XML取代了JSON。在那時，卡茨認識到與使用Formula式的引擎相比，使用網絡應用標準語言JavaScript多是一種更好的想法。 「一旦咱們推出JavaScript之後，」他說道，「這個項目就真正騰飛了起來。」

Couch的商業化

在 2007年，「復活」後的CouchDB受到了IBM的關注。不久之後，卡茨的名字回到了這家公司的工資單上，負責全職開發CouchDB。最爲關鍵的 是，IBM贊成將這個項目捐給非營利組織Apache基金會（Apache Foundation），這意味着IBM還不得不向開發者和CouchDB用戶受權使用該公司的相關專利。這也就是說，IBM將沒法起訴CouchDB侵 犯了與Lotus Notes相關的專利。

與此同時，NoSQL運動則全速展開。谷歌和亞馬遜的論文令這種模式——此前已經有開源開發者倡導這種模式——變得流行起來，同時也爲如何讓其在現實世界中運做起來提供了某種深入的理解。

一 家名爲10gen的公司從2007年開始致力於開發一個名爲MongoDB的NoSQL文件數據庫，用BigTable做爲參照模式。「那是徹底獨立 的，MongoDB、Couch和Lotus Notes兩兩之間沒有太多的平行之處。」10gen創始人德懷特·梅里曼（Dwight Merriman）說道。一年之後，Facebook開放了Cassandra的源碼，那是一個NoSQL數據庫，整合了來自於Dynamo和 BigTable的概念。到2009年，隨着CouchDB、Cassandra、MongoDB及其餘NoSQL數據庫加速發展，科技博客 ReadWriteWeb提出了一個問題，那就是關係型數據庫是否已註定滅亡。

與此同時，當時供職於Last.fm的約翰·奧斯卡森（Johan Oskarsson）主持召開了首次NoSQL會議，無心中給這場本來定義鬆散的運動起了一個名字。

在 形勢一片大好的大肆宣傳浪潮中，卡茨、雷納德和克里斯·安德森（J. Chris Anderson）創立了Couch.io，來對CouchDB進行商業化。到這個時候，一個由麻省理工學院物理學家組成的團隊已經開創了一家名爲 Cloudant的CouchDB公司，致力於開發本身版本的數據庫，這個數據庫名爲BigCouch。雖然Couch.io（後來改名爲 CouchOne）難以在現實世界中找到本身的位置，但很快就經過與另外一家NoSQL公司Membase合併的方式找到了本身的立足點。

Membase 須要一名新的首席技術官，而CouchOne則須要一名首席執行官；Couch須要一種更好的方式來將規模擴大至大量的服務器，而這正是Membase所 能提供的；Membase須要一種更好的數據結構，而CouchDB能提供這種結構；極可能最重要的是，Membase擁有被卡茨認爲是可以持續運營的商 業模式。在合併之後，新公司和新的數據庫都被命名爲Couchbase。

可是，這次合 並交易所帶來的一個麻煩的結果是與Apache基金會的關係破裂。「咱們真的曾付出過不少努力來讓這種變化同步發生。」卡茨說道。「但到最後的結果是，與 Apache項目所能達到的前進速度相比，咱們須要的速度要快得多。」最終的結局是，卡茨決定放棄他本身創立的項目，全心致力於Couchbase的發 展。在2012年1月份，也就是合併交易完成的一年之後，他在本身的博客上發表了一封措辭強硬的「告別信」，寫道：「CouchDB的將來是什麼？那就是 Couchbase。」

斯萊特此時已經成爲Apache的CouchDB項目負責人，他用一條簡短的Twitter消息對此做出了迴應：「CouchDB的將來仍是CouchDB。」

卡 茨認可，他本來能夠處理得更加老練一些，但說到最後，這個故事證實了NoSQL已經變得多麼活力四射。開發者仍在頑強地致力於開發CouchDB，哪怕沒 有卡茨的參與也仍是堅持不懈。Cloudant也仍舊致力於開發CouchDB，承諾將把BigCouch的代碼還給這個項目。

Couchbase也正處在發佈2.0版本數據庫的邊緣，此前該公司已經爭取到了NTT DoCoMo和AOL等大客戶。文件數據庫的想法在開發者的腦海中已經生根，這不只要感謝CouchDB及其諸多分支，同時也要感謝MongoDB所帶來的人氣。

與此同時，IBM則將放棄Lotus這個品牌名；Notes則將繼續生存下去，至少如今是這樣。在它的背後多是最好的年華，但它爲將來更多的美好時光搭好了舞臺。

附：數據庫大事年表

1961年：通用電氣着手開發Integrated Data Store（IDS，集成數據存儲）。一般來說，IDS被認爲是第一個「徹底的」數據庫。在今天的NoSQL數據庫出現的數十年之前，IDS所作的就是現在NoSQL和大數據的工做。

1967：IBM 開發出Information Control System and Data Language/Interface（ICS/DL/I，信息控制系統與數據語言/界面），這是阿波羅（Apollo）項目的分級數據庫。ICS隨後變 成了Information Management System（IMS，信息管理系統），與IBM的System360主機整合到一塊兒。

1970年：IBM研究員埃德加·科德（Edgar Codd）發表題爲《大型共享數據庫的關係模型》（A Relational Model of Data for Large Shared Data Banks）論文，創建了關係型數據庫所使用的數學基礎。

1973年：大衛·伍利（David R. Woolley）開發出了PLATO Notes，用一個文本文件做爲報錯系統的數據存儲方式。PLATO Notes對隨後Lotus Notes的出現造成了影響。

1974 年：IBM着手開發System R，將科德的關係型數據庫模型變成了現實，首次使用了SQL（結構化查詢語言），隨後這個系統演變成了商業化產品IBM DB2。在科德研究的啓發下，伯克利大學的學生邁克爾·斯通布雷克（Michael Stonebraker）和尤金·王（Eugene Wong）開始開發INGRES，它隨後成爲了PostGreSQL、Sybase及其餘許多關係型數據庫的基礎。

1979年：第一個公開可用版本的Oracle數據庫發佈。

1984年：雷·奧茲（Ray Ozzie）成立Iris Associates，創造了一個受PLATO Notes啓發的組合件系統。

1988年：由文件數據庫提供支持的Lotus Agenda發佈。

1989年：Lotus Notes發佈。

1990年：Objectivity發佈了期間對象數據庫。

1991年：Key-value類型數據庫Berkeley DB發佈。

2003年：Live Journal開放最第一版本Memcached的源碼。

2005年：達米安·卡茨（Damien Katz）開放CouchDB源碼。

2006年：Google發表BigTable論文。

2007年：亞馬遜發表Dynamo論文。10gen開始編制MongoDB代碼。Powerset開放BigTable clone克隆版Hbase的源碼。

2008年：Facebook開放Cassandra源碼。

2009年：科技博客ReadWriteWeb提出一個問題：「關係型數據庫是否已註定滅亡？」 Redis發佈。首次NoSQL會議在舊金山召開。

2010年：Memcached項目的一些負責人與社交遊戲公司Zynga開放Membase源碼。