數據庫場景選型

 

關係型數據庫場景選擇：

本文不討論SQLite，這玩意兒差很少就是充當XML配置來使用的，就是軟件的一些配置能夠用它來存，雖然它讀寫速度很快，可是它不少數據庫的必要性（完整事務）沒有支持，衡量數據庫的指標也不僅是讀寫性能，最後，項目怎麼適合怎麼用吧，也沒有特別限制。

 

SQLite劣勢：

1.寫入粒度粗，寫入是全表排它鎖，會鎖定其餘鏈接的寫操做直到完成寫入，因此高併發下要完蛋。

2.基於文件I/O的，直接讀寫db文件，缺少管理和優化，沒有網絡鏈接數據庫這層，缺少安全性。

 

SQLite優點：

1.基於文件IO，速度快。

2.簡單，不用配置，移動端和嵌入式端最好用了。

 

 其餘數據庫基於網絡鏈接，因此瓶頸主要會卡在網絡IO上。因此會以爲慢。

 

首先，數據庫選型，應當考慮如下問題：

1.對數據一致性（ACID）的要求如何（要求越高，越不合適使用MySQL），若是是支付相關，更應該是Oracle

2.對數據保護的要求如何（要求越高，越不合適使用MySQL）

3.數據的讀寫好比何（越高，越須要考慮使用MySQL）

4.數據的規模如何 （數據規模較小是使用MySQL便可，中等規模時，Oracle可能更加經濟，規模很大時，須要從整個架構層面來考慮）

5.業務變化的頻繁程度如何（頻繁變化的業務，意味着頻繁的數據結構變動，意味着使用MySQL的相對成本越高）

6.自身的技術能力如何（Oracle的第三方服務更好，自身沒有比較NB的技術能力，仍是使用成熟產品Oracle比較合適）

 

固然，關係型數據庫的誕生之初，主要是爲了企業設計的，由於企業內部系統需求變化不快，因此用基於二維表結構的關係型數據庫（RDBMS）很合適，而隨着今年互聯網大數據等Web應用，才催生了一堆NoSQL數據庫（非關係型），由於數據結構更加靈活，更加適合需求變化快的場景。

 

例子：

  若是是內網項目，天天同時也就幾百個終端，那麼MySQL就是不錯的選擇。當下火熱的創業Web應用互聯網公司也多用MySQL，用戶不算多也是顯而意見的

 

 

固然最後，估計也有多是錢的緣由（之一）：

 

NoSQL數據庫場景選擇：

曾在多家大公司任職的軟件架構師兼顧問Kristóf Kovács在博客中對主流的NoSQL數據庫（Cassandra、Mongodb、CouchDB、Redis、Riak、Membase、Neo4j以及HBase）進行了全方位的對比。

雖然SQL數據庫是很是有用的工具，但經歷了15年的一支獨秀以後壟斷即將被打破。這只是時間問題：被迫使用關係數據庫，但最終發現不能適應需求的狀況不勝枚舉。

可是NoSQL數據庫之間的不一樣，遠超過兩SQL數據庫之間的差異。這意味着軟件架構師更應該在項目開始時就選擇好一個適合的NoSQL數據庫。針對這種狀況，這裏對 Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j和HBase進行了比較：

注：NoSQL是一項全新的數據庫革命性運動，NoSQL的擁護者們提倡運用非關係型的數據存儲。現今的計算機體系結構在數據存儲方面要求具 備龐大的水平擴 展性，而NoSQL致力於改變這一現狀。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數據庫。

1. CouchDB

所用語言： Erlang
特色：DB一致性，易於使用
使用許可： Apache
協議： HTTP/REST
雙向數據複製，
持續進行或臨時處理，
處理時帶衝突檢查，
所以，採用的是master-master複製（見編注2）
MVCC – 寫操做不阻塞讀操做
可保存文件以前的版本
Crash-only（可靠的）設計
須要不時地進行數據壓縮
視圖：嵌入式 映射/減小
格式化視圖：列表顯示
支持進行服務器端文檔驗證
支持認證
根據變化實時更新
支持附件處理
所以， CouchApps（獨立的 js應用程序）
須要 jQuery程序庫

最佳應用場景：適用於數據變化較少，執行預約義查詢，進行數據統計的應用程序。適用於須要提供數據版本支持的應用程序。

例如： CRM、CMS系統。 master-master複製對於多站點部署是很是有用的。

注：master-master複製：是一種數據庫同步方法，容許數據在一組計算機之間共享數據，而且能夠經過小組中任意成員在組內進行數據更新。

2.Redis

所用語言：C/C++
特色：運行異常快
使用許可： BSD
協議：類 Telnet
有硬盤存儲支持的內存數據庫，
但自2.0版本之後能夠將數據交換到硬盤（注意， 2.4之後版本不支持該特性！）
Master-slave複製（見編注3）
雖然採用簡單數據或以鍵值索引的哈希表，但也支持複雜操做，例如 ZREVRANGEBYSCORE。
INCR & co （適合計算極限值或統計數據）
支持 sets（同時也支持 union/diff/inter）
支持列表（同時也支持隊列；阻塞式 pop操做）
支持哈希表（帶有多個域的對象）
支持排序 sets（高得分表，適用於範圍查詢）
Redis支持事務
支持將數據設置成過時數據（相似快速緩衝區設計）
Pub/Sub容許用戶實現消息機制

最佳應用場景：適用於數據變化快且數據庫大小可碰見（適合內存容量）的應用程序。

例如：股票價格、數據分析、實時數據蒐集、實時通信。

注：Master-slave複製：若是同一時刻只有一臺服務器處理全部的複製請求，這被稱爲 Master-slave複製，一般應用在須要提供高可用性的服務器集羣。

3. MongoDB

所用語言：C++
特色：保留了SQL一些友好的特性（查詢，索引）。
使用許可： AGPL（發起者： Apache）
協議： Custom, binary（ BSON）
Master/slave複製（支持自動錯誤恢復，使用 sets 複製）
內建分片機制
支持 javascript表達式查詢
可在服務器端執行任意的 javascript函數
update-in-place支持比CouchDB更好
在數據存儲時採用內存到文件映射
對性能的關注超過對功能的要求
建議最好打開日誌功能（參數 –journal）
在32位操做系統上，數據庫大小限制在約2.5Gb
空數據庫大約佔 192Mb
採用 GridFS存儲大數據或元數據（不是真正的文件系統）

最佳應用場景：適用於須要動態查詢支持；須要使用索引而不是 map/reduce功能；須要對大數據庫有性能要求；須要使用 CouchDB但由於數據改變太頻繁而佔滿內存的應用程序。

例如：你本打算採用 MySQL或 PostgreSQL，但由於它們自己自帶的預約義欄讓你望而卻步。

4. Riak

所用語言：Erlang和C，以及一些Javascript
特色：具有容錯能力
使用許可： Apache
協議： HTTP/REST或者 custom binary
可調節的分發及複製(N, R, W)
用 JavaScript or Erlang在操做前或操做後進行驗證和安全支持。
使用JavaScript或Erlang進行 Map/reduce
鏈接及鏈接遍歷：可做爲圖形數據庫使用
索引：輸入元數據進行搜索（1.0版本即將支持）
大數據對象支持（ Luwak）
提供「開源」和「企業」兩個版本
全文本搜索，索引，經過 Riak搜索服務器查詢（ beta版）
支持Masterless多站點複製及商業許可的 SNMP監控
　　最佳應用場景：適用於想使用相似 Cassandra（相似Dynamo）數據庫但沒法處理 bloat及複雜性的狀況。適用於你打算作多站點複製，但又須要對單個站點的擴展性，可用性及出錯處理有要求的狀況。

例如：銷售數據蒐集，工廠控制系統；對宕機時間有嚴格要求；能夠做爲易於更新的 web服務器使用。

5. Membase

所用語言： Erlang和C
特色：兼容 Memcache，但同時兼具持久化和支持集羣
使用許可： Apache 2.0
協議：分佈式緩存及擴展
很是快速（200k+/秒），經過鍵值索引數據
可持久化存儲到硬盤
全部節點都是惟一的（ master-master複製）
在內存中一樣支持相似分佈式緩存的緩存單元
寫數據時經過去除重複數據來減小 IO
提供很是好的集羣管理 web界面
更新軟件時軟無需中止數據庫服務
支持鏈接池和多路複用的鏈接代理

最佳應用場景：適用於須要低延遲數據訪問，高併發支持以及高可用性的應用程序

例如：低延遲數據訪問好比以廣告爲目標的應用，高併發的 web 應用好比網絡遊戲（例如 Zynga）

6. Neo4j

所用語言： Java
特色：基於關係的圖形數據庫
使用許可： GPL，其中一些特性使用 AGPL/商業許可
協議： HTTP/REST（或嵌入在 Java中）
可獨立使用或嵌入到 Java應用程序
圖形的節點和邊均可以帶有元數據
很好的自帶web管理功能
使用多種算法支持路徑搜索
使用鍵值和關係進行索引
爲讀操做進行優化
支持事務（用 Java api）
使用 Gremlin圖形遍歷語言
支持 Groovy腳本
支持在線備份，高級監控及高可靠性支持使用 AGPL/商業許可

最佳應用場景：適用於圖形一類數據。這是 Neo4j與其餘nosql數據庫的最顯著區別

例如：社會關係，公共交通網絡，地圖及網絡拓譜

7. Cassandra

所用語言： Java
特色：對大型表格和 Dynamo支持得最好
使用許可： Apache
協議： Custom, binary (節約型)
可調節的分發及複製(N, R, W)
支持以某個範圍的鍵值經過列查詢
相似大表格的功能：列，某個特性的列集合
寫操做比讀操做更快
基於 Apache分佈式平臺儘量地 Map/reduce
我認可對 Cassandra有偏見，一部分是由於它自己的臃腫和複雜性，也由於 Java的問題（配置，出現異常，等等）

最佳應用場景：當使用寫操做多過讀操做（記錄日誌）若是每一個系統組建都必須用 Java編寫（沒有人由於選用 Apache的軟件被解僱）

例如：銀行業，金融業（雖然對於金融交易不是必須的，但這些產業對數據庫的要求會比它們更大）寫比讀更快，因此一個天然的特性就是實時數據分析

8. HBase

（配合 ghshephard使用）

所用語言： Java
特色：支持數十億行X上百萬列
使用許可： Apache
協議：HTTP/REST （支持 Thrift，見編注4）
在 BigTable以後建模
採用分佈式架構 Map/reduce
對實時查詢進行優化
高性能 Thrift網關
經過在server端掃描及過濾實現對查詢操做預判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基於 Jruby（ JIRB）的shell
對配置改變和較小的升級都會從新回滾
不會出現單點故障
堪比MySQL的隨機訪問性能

最佳應用場景：適用於偏好BigTable:)而且須要對大數據進行隨機、實時訪問的場合。

例如： Facebook消息數據庫（更多通用的用例即將出現）

注：Thrift 是一種接口定義語言，爲多種其餘語言提供定義和建立服務，由Facebook開發並開源。

references:

https://www.zhihu.com/question/29088685

 https://www.zhihu.com/question/31417262

https://www.zhihu.com/question/22798301

https://www.zhihu.com/question/21771941

http://www.jb51.net/article/51599.htm