常見的幾個非關係型資料庫(NoSQL)、非關係型和關係型的區別
阿新 • • 發佈：2019-02-18
NoSQL
2009年初，Johan Oskarsson舉辦了一場關於開源分散式資料庫的討論，Eric Evans在這次討論中提出了NoSQL一詞，用於指代那些非關係型的，分散式的，且一般不保證遵循ACID原則的資料儲存系統。Eric Evans使用NoSQL這個詞，並不是因為字面上的“沒有SQL”的意思，他只是覺得很多經典的關係型資料庫名字都叫“**SQL”,所以為了表示跟這些關係型資料庫在定位上的截然不同，就是用了“NoSQL“一詞。
注：資料庫事務必須具備ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation
var script = document.createElement(‘script’); script.src = ‘http://static.pay.baidu.com/resource/baichuan/ns.js’; document.body.appendChild(script);
隔離性，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
Redis
Redis是一個很新的專案。Redis本質上是一個Key-Value型別的記憶體資料庫，很像memcached，整個資料庫統載入在記憶體當中進行操作，定期通過非同步操作把資料庫資料flush到硬碟上進行儲存。因為是純記憶體操作，Redis的效能非常出色，每秒可以處理超過 10萬次讀寫操作。Redis的出色之處不僅僅是效能，Redis最大的魅力是支援儲存List連結串列和Set集合的資料結構，而且還支援對List進行各種操作，它的值可以是string，list，sets，或者是ordered sets。例如 從List兩端push和pop資料，取List區間，排序等等，對Set支援各種集合的並集交集操作，此外單個value的最大限制是1GB，不像 memcached只能儲存1MB的資料，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向連結串列，實現一個輕量級的高性 能訊息佇列服務，用他的Set可以做高效能的tag系統等等。另外Redis也可以對存入的Key-Value設定expire時間，因此也可以被當作一 個功能加強版的memcached來用。 Redis的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高效能讀寫，並且它沒有原生的可擴充套件機制，不具有scale（可擴充套件）能力，要依賴客戶端來實現分散式讀寫，因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。根據Redis的官網測試報告，50個併發請求，10w次訪問，寫速度為11x10e4/s,讀速度為8100次/s.目前使用Redis的網站有 github，Engine Yard。
redis支援的各種資料型別包括string,list ,set ,sorted set 和hash
1. keys
redis本質上一個key-value db，所以我們首先來看看他的key.首先key也是字串型別，但是key中不能包括邊界字元
由於key不是binary safe的字串，所以像”my key”和”mykey\n”這樣包含空格和換行的key是不允許的
順便說一下在redis內部並不限制使用binary字元，這是redis協議限制的。”\r\n”在協議格式中會作為特殊字元。
redis 1.2以後的協議中部分命令已經開始使用新的協議格式了(比如MSET)。總之目前還是把包含邊界字元當成非法的key吧， 免得被bug糾纏。
另外關於key的一個格式約定介紹下，object-type:id:field。比如user:1000:password，blog:xxidxx:title
還有key的長度最好不要太長。道理很明顯佔記憶體啊，而且查詢時候相對短key也更慢。不過也推薦過短的key，
比如u:1000:pwd,這樣的。顯然沒上面的user:1000:password可讀性好。