轉自:http://blog.csdn.net/newjueqi/article/details/44003503
app后端的開發中，經常要面臨的一個問題是：數據放在哪里? mysql ？redis？mongodb？
現在有這么多優秀的開源數據庫產品，怎么根據業務場景來選擇合適的數據?
常用的數據庫產品的優缺點又是什么呢?
通過閱讀這篇文章，能幫你解決以上的疑惑，使你在碰到數據存儲選擇問題時思路更清晰。
1. redis，mongodb，mysql存儲數據的區別
數據，就涉及讀和寫這兩個問題．出於性能的考慮，當然希望讀和寫的速度越快越好．
計算機中，數據一般都放在內存或硬盤，眾所周知，內存的讀寫速度比硬盤快多了。因此，為了獲得更快的讀寫速度，數據盡可能放在內存中。
但是，內存的容量是非常有限的，例如，在ucloud的服務器上，最多只能擁有64G的內存，而ucloud的服務器上的單個硬盤，最多可高達1000G。
redis的數據是放在服務器的內存中，當內存用滿了，redis就沒折了（現在只有第三方的分布式解決方案，官方的分布式方案要在3.0版本才會出。）。當然了，為了防止數據丟失，可通過配置文件，把數據在硬盤上做一個備份。
mongodb的數據主要是放在內存中，如果mongodb發現內存滿了，數據再也放不下了，mongodb就把新增的數據放在硬盤中。如果是采用分布式架構，那基本不用考慮數據會放在硬盤中。
mysql的數據是放在硬盤中。雖然mysql也有緩存，但mysql緩存的是查詢的結果，而不是緩存數據。
2. redis，mongodb，mysql查找數據的區別
如果你想在一棟大樓里找某個房間，但是你不知道這個房間的門牌號，只記得這個房間的門是非常特別的，那找到這個房間唯一的方式只能每層樓逐個房間找一次，直到找到這個房間為止。
如果你知道了這個房間的門牌號，那很簡單，直奔那個樓層就是了。
redis的數據是基於“鍵值對”存儲，“鍵”相當於門牌號，“值”相當於房間。redis查找數據，每次都是直奔目標，讀寫速度當然高。
mongodb和mysql中，每組數據都有一個id（或者可以為每組數據建索引），這個id或索引就相當於門牌號。
mongodb和mysql中查找數據，有兩種模式，知道id或索引，和不知道知道id或索引。知道id或索引，就相當於知道門牌號，那就直奔目標就行了，效率很高。如果不知道id或索引的情況下查找數據，那就相當於每層樓逐個房間找，效率很低。
3. redis，mongodb，mysql適用場景
redis適用場景：
數據讀寫速度快，但由於redis數據只存放在一台服務器的內存中（現在只有第三方的分布式解決方案，官方的分布式方案要在3.0版本才會出來），所以存儲數據有限。
同時，由於redis存放的數據必須是鍵值對(key-value)的形式，在讀寫redis的數據時必須要知道鍵，這點需要考慮。
所以，在app后端中，最講求讀寫效率，最頻繁讀的數據一般都會放在redis中（當然，這部分數據同時也存在於mysql 或者mongodb中， redis中的數據是一個冗余，當數據更新的時候，兩部分都要更新）。
舉例，在社交app中，很多操作都需要驗證用戶的登錄信息，那一般怎么做的呢？
用戶登錄后，服務器會把一個token符串返回給用戶，假設這個token字符串為"abcdsdf", 服務器中已經登記了這個token符串，而且把這個tokentoken符串和用戶的信息關聯在一起，通過這個token符串就能查詢到用戶的信息。
當遇到需要驗證用戶的登錄信息，就把這個token字符串傳給服務器，服務器根據這個token的信息，在服務器中查找這個用戶的信息。
在社交app中，大多數的操作都需要這個驗證，可以看出，是個很頻繁的操作，而且這個操作需要在極短的時間內完成。
那么，這個token字符串和用戶的信息，就很適合放在redis中，把token字符串當成一個key(鍵)，用戶的信息當成是value（值），查找起來非常方便和高效。
當然了，驗證用戶的登錄信息還需要很多安全的措施，這里只講一個最簡單的模型，在以后的《app通訊安全性》一文中會講完善的安全措施。
mongodb適用場景：
a.網站數據：mongo非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的復制及高度伸縮性。
b.緩存：由於性能很高，mongo也適合作為信息基礎設施的緩存層。在系統重啟之后，由mongo搭建的持久化緩存可以避免下層的數據源過載。
c.大尺寸、低價值的數據：使用傳統的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。
d.高伸縮性的場景：mongo非常適合由數十或者數百台服務器組成的數據庫。
e.存儲地理坐標的數據。mongo支持非常強大的地理坐標的查詢，例如，可以在某個矩形范圍內的用戶。非常適合於LBS的應用。
mongodb不適合的場景：
a.高度事物性的系統：例如銀行或會計系統。傳統的關系型數據庫目前還是更適用於需要大量原子性復雜事務的應用程序。
例如，涉及金錢的操作，假設要把轉賬，必須從一個賬號上扣錢，再在另外一個賬號上把錢轉賬。這個操作必須保證要么兩個都完成，要么兩個都不做，不能只做一個。但很遺憾，由於mongodb不支持事務，所以沒法保證。
b. 傳統的商業智能應用：針對特定問題的BI數據庫會對產生高度優化的查詢方式。對於此類應用，數據倉庫可能是更合適的選擇。
c. 需要SQL的問題。雖然mongodb支持類似於sql的查詢方式，但它的查詢比起mysql還是有一定的差距。
mysql適用場景:
a. 事物性的系統。例如，在mongodb中舉例的轉賬的例子
b. 需要復雜SQL的問題。
簡單地來說，綜合考慮后，發現數據不適合放在redis和mongodb后，那就把數據放在mysql吧^-^