數據庫場景比較
MySQL還是PostgreSQL?
1、如果你的應用對數據的完整性和嚴肅性要求不高，但是追求處理的高速度。例如是一個論壇和社區，你應該使用MySQL。
2、你的應用是一個嚴肅的商業應用，對數據完整性要求很高。而且你希望對一些商業數據邏輯進行很好的封裝，例如是一個網上銀行，你應該使用PostgreSQL。
3、你的應用處理的是地理數據，由於R-TREES的存在，你應該使用PostgreSQL。
4、等等
MongoDB適用案例
1. 事件記錄
應用程序對事件記錄各有需求。在企業級解決方案中，許多不同的應用程序都需要記錄事件。文檔數據庫可以把所有這些不同類型的事件都存起來，並作爲事件存儲的”中心數據庫”使用。如果事件捕獲的數據類型一直在變，那麼就更應該用文檔數據庫了。可以按照觸發事件的應用程序名”分片”，也可以按照order_processed(表示訂單已處理)或customer_logged(表示客戶已記錄)等事件類型”分片”。
2. 內容管理系統及博客平臺
由於文檔數據沒有”預設模式”，而且通常支持JSON文檔，所以它們很適合在用”內容管理系統”及網站發佈程序上，也可以用來管理用戶評論、用戶註冊、用戶配置和麪向Web文檔。
3. 網站分析與實時分析
文檔數據庫可存儲實時分析數據。由於可以只更新部分文檔內容，所以用它來存儲”頁面瀏覽量”(page view)或”獨立訪問數”會非常方便，而且無需改變模式即可新增度量標準。分析：鑑於它的弱模式結構，不改變模式下就可以儲存不同的度量方法及添加新的度量。
4. 電子商務應用程序
電子商務類應用程序通常需要較爲靈活的模式，以存儲產品和訂單。同時，它們也需要在不做高成本數據庫重構及數據遷移的前提下進行其數據模型。
5. 日誌。企業環境下，每個應用程序都有不同的日誌信息。Document-Oriented數據庫並沒有固定的模式，所以我們可以使用它儲存不同的信息。
MongoDB不適用場合
目前事務型業務、以及關聯操作業務不適合。
在不同的文檔上添加事務。Document-Oriented數據庫並不支持文檔間的事務，如果對這方面有需求則不應該選用這個解決方案。
鍵值（Key-Value）數據庫
鍵值數據庫就像在傳統語言中使用的哈希表。你可以通過key來添加、查詢或者刪除數據，鑑於使用主鍵訪問，所以會獲得不錯的性能及擴展性。
適用的場景
儲存用戶信息，比如會話、配置文件、參數、購物車等等。這些信息一般都和ID（鍵）掛鉤，這種情景下鍵值數據庫是個很好的選擇。
不適用場景
1. 取代通過鍵查詢，而是通過值來查詢。Key-Value數據庫中根本沒有通過值查詢的途徑。
2. 需要儲存數據之間的關係。在Key-Value數據庫中不能通過兩個或以上的鍵來關聯數據。
3. 事務的支持。在Key-Value數據庫中故障產生時不可以進行回滾。
Cassandra使用場景
1. 事件記錄
由於列族數據庫可存放任意數據結構，所以它很適合用來保存應用程序狀態或運行中遇到的錯誤等事件信息。在企業級環境下，所有應用程序都可以把事件寫入Cassandra數據庫。它們可以用appname:timestamp(應用程序名：時間戳)作爲行鍵，並使用自己需要的列。由於Cassandra的寫入能力可擴展，所以在事件記錄系統中使用它效果會很好。
2. 內容管理系統與博客平臺
使用列族，可以把博文的”標籤”(tag)、”類別”(category)、”鏈接”(link)和”trackback”（俗稱引用告知，是一種網誌工具，它可以讓文章作者知道該文讀者中有哪些人撰寫了哪些與之有關的文章）等屬性放在不同的列中。評論信息即可以與上述內容放在同一行，也可以移到另一個”鍵空間”。同理，博客用戶與實際博文亦可存於不同列族中。博客平臺：我們儲存每個信息到不同的列族中。舉個例子，標籤可以儲存在一個，類別可以在一個，而文章則在另一個
3. 計數器
在網絡應用程序中，通常要統計某頁面的訪問人數並對其分類，以算出分析數據。此時可使用ConterColumnType來創建列族。
創建好列族後，可以使用任意列記錄網絡應用程序中每個用戶訪問每一頁面的次數。
也可以使用CQL增加計數器的值。
4. 限期使用
我們可能需要向用戶提供試用版，或是在網站上將某個廣告條顯示一定時間。這些功能可以通過”帶過期時限的列”(expiring column)來完成。這種列過了給定時限後，就會又Cassandra自動刪除。這個時限叫做TTL(Time To Live，生存時間)，以秒爲單位。經過TTL指定的時長後，這種列就被刪掉了。程序若檢測到此列不存在，則可收回用戶訪問權限或移除廣告條。
5. 日誌。因爲我們可以將數據儲存在不同的列中，每個應用程序可以將信息寫入自己的列族中。
Cassandra不適合場合
有些問題是有列族數據庫來解決並不是最佳選擇，例如需要以”ACID事務”執行寫入及讀取操作的系統。如果想讓數據庫根據查詢結果來聚合數據(例如sum求和)或avg(求平均值)，那麼得把每一行數據都讀到客戶端，並在此執行操作。
在開發早期原型或開始試探某個技術方案時，不太適合用Cassandra。開發初期無法確定查詢模式的變化情況，而查詢模式一旦改變，列族的設計也要隨之修改。這將阻礙產品創新團隊的工作並降低開發者的生產能力。
在關係型數據庫中，數據模式的修改成本很高，而這卻降低了查詢模式的修改成本；Cassandra則與之相反，改變其查詢模式要比改變數據模式代價更高。
1. 如果我們需要ACID事務。Cassandra就不支持事務。
2. 原型設計。如果我們分析Cassandra的數據結構，我們就會發現結構是基於我們期望的數據查詢方式而定。在模型設計之初，我們根本不可能去預測它的查詢方式，而一旦查詢方式改變，我們就必須重新設計列族。
圖數據庫(Neo4j)適用案例
1. 互聯數據
部署並使用圖數據庫來處理社交網絡非常高效。社交圖裏並不是只能有”朋友”這種關係，例如也可以用它們表示僱員、僱員的學識，以及這些僱員與其他僱員在不同項目中的工作位置。任何富含鏈接關係的領域都很適合用圖數據庫表示。
假如同一個數據庫含有不同領域(像社交領域、空間領域、商務領域等)的領域實體，而這些實體之間又有關係，那麼圖數據庫提供的跨領域遍歷功能，可以讓這些關係變得更有價值。
2. 安排運輸路線、分派貨物和基於位置的服務
投遞過程中的每個地點或地址都是一個節點，可以把送貨員投遞貨物時所經全部節點建模爲一張節點圖。節點間關係可帶有距離屬性，以便高效投遞貨物。距離與位置屬性也可用在名勝圖(graph of places of interest)中，這樣應用程序就可向用戶推薦其附件的好餐館及娛樂場所了。還可將書店、餐館等售點(point of sales)做成節點，當用戶靠近時通知他們，以提供基於位置的服務。
3. 推薦引擎
在系統中創建節點與關係時，可以用它們爲客戶推薦信息，例如”您的朋友也買了這件產品”或”給這些貨品開發票時，通常也要爲哪些貨品一併開票”。還可以用它們向旅行者提議：來巴塞羅那旅遊的人一般都會去看看安東尼.高迪所設計的建築。
用圖數據庫推薦信息時，有個副作用值得注意：隨着數據量變多，推薦信息所用的節點及關係數也激增。同一份數據可以挖掘出不同信息。例如，既可以從中看出客戶總是將其與那些產品一併購買，也可以查出與此產品一併開發票的其餘產品。若兩者不匹配，則可發出警示。圖數據庫與其他”推薦引擎”一樣，也可以根據關係間的模式偵測交易欺詐。如果我們將數據以圖的形式表現，那麼將會非常有益於推薦的制定
4. 在一些關係性強的數據中
圖數據庫Neo4j不適用場合
在更新全部或某子集內的實體時就是這樣。比如，在某個”數據分析解決方案”中，只要一個屬性變了，全部實體就都得更新。此時圖數據庫的效果就不理想了，因爲沒有哪個簡單的操作能一次性改變所有節點中的某個屬性。即便數據模型適合問題領域，某些圖數據庫可能也無法處理那麼大的數據量，尤其在執行”全局圖操作”時更是如此。
不適合的數據模型。圖數據庫的適用範圍很小，因爲很少有操作涉及到整個圖。