在微服務設計中，資料庫的選型是不可缺少的一環，後台的核心是與資料打交道，在不同的業務場景選擇的資料庫不一樣， 好的資料庫選型能夠解決業務的效能瓶頸，如果資料庫選擇不恰當，會使得服務的效能上不去，因此我們需要對一些常用的資料庫有一些了解，這樣才能因地制宜，發揮系統最好的效能。
常見的資料庫分類：
資料庫型別
資料庫名稱
關係型資料庫
mysql，oracle，postgresql
記憶體資料庫
redis，memcache
時序資料庫
tsdb
文件型資料庫
mongodb
分布式資料庫
tidb
圖資料庫
neo4j，infinite graph，orientdb
列式儲存資料庫
hbase，clickhouse，elasticsearch
檔案儲存
eph，glusterfs等
可以看出，資料庫種類是很多的，每一種應用的領域也不一樣，很多大公司還會專門對資料庫進行定製，以提高資料訪問的效能，下面我們來分析不同業務場景下資料庫怎麼選擇。
關係型資料庫選擇
系型資料庫用的最多的是mysql，大部分網際網路企業都會選用mysql作為資料儲存，主要因為mysql有如下優點:
對於請求量，資料量不大的情況下，對mysql做增刪改查的業務效能還是很好的，並且mysql提供強一致性事務的支援，支援多種事務隔離級別，並且多種儲存引擎的選擇，使得mysql在資料庫中的地位是非常之高的。但是金無足赤人無完人，在業務擴充套件到一定規模，mysql的問題就暴露出來了，主要的問題有：
mysql對一些複雜型別的查詢支援是很弱的，舉個例子，如果我們要做個搜尋查詢的功能，根據各種指標，範圍去資料庫中搜尋資料，如果業務層通過mysql去實現，前期資料量小的情況下是沒多少問題的，但是如果表中資料量越來越多，或者搜尋的條件組合很複雜，那麼此時會很慢。因此，複雜查詢業務盡量不要使用mysql。另外如果業務擴大到一定規模，mysql單錶也會變得很大，這個時候效能會受到影響，如果已經不能優化，還需要做分表等擴充套件措施來解決業務的效能瓶頸。
如果遇到這些情況，目前業界的主流方案除了分割槽表，分庫分表，通過**中介軟體進行分表之外，比較熱門的就是分布式資料庫，分布式資料庫最大的特點是能夠自由擴充套件，不要考慮資料量瓶頸的問題。這兩年比較流行的是tidb資料庫，tidb是乙個分布式資料庫，最大的優點是相容mysql協議，並且通過raft協議保證資料一致性。因此mysql使用者可以很簡單的遷移到tidb來。並且tidb對一般的olap查詢支援也比較好，因此資料量大的情況下使用tidb是乙個更好的選擇。
記憶體資料庫
記憶體資料庫用的多的是redis，大多數業務場景都是用做快取，少部分對資料安全不敏感的場景用來做資料持久化，因為redis也支援資料持久化。遊戲行業以前用memcache比較多，現在也逐漸向redis靠攏。由於redis資料都放到記憶體中，並且在區域網環境通訊的代價也比較廉價，所以redis的效能非常好，並且redis支援多種型別的資料結構，在不同業務使用都非常方便。
但是redis也有著和mysql相似的問題，單機的redis會有效能瓶頸，理想情況下單機redis qps也只能達到10w，如果請求量非常大的情況下會對業務造成影響，並且redis是單執行緒的，雖然單執行緒能避免context切換的開銷，但是並不能利用多核特性，這在高效能應用領域是乙個致命打擊。集群化部署需要在業務層做雜湊來實現負載均衡，如果涉及到增刪節點還需要做資料遷移，這段時間也會對業務造成影響。因此，單執行緒即成就了redis同時也限制了redis，因此有不少大公司在實現多執行緒redis的專案來解決這個問題。
文件型資料庫
文件型資料庫比較有名的是mongodb，mongodb是非關係型資料庫，弱一致性，在4.0版本以上開始支援事務，提供snapshot isolation的事務隔離級別，這個隔離級別和mysql中的repeatable read隔離級別相同。mongodb內部採用gridfs做資料落地，對一些檔案物件支援比較友好。mongodb支援多種儲存引擎，可以適應不同的場景，並且使用方便，對一致性要求不高的業務場景用的很多，常用來儲存一些加工的中間資料，方便去展示， 也有一些公司使用mongodb做最終資料落地，因此，很多進行資料展示的業務可以使用使用mongodb，或者查詢條件多樣並且想提高查詢速度的場景也可以使用mongodb替換mysql。
mongodb雖然優點很多，但是也有很多場景是不適應的，剛剛提到過mysql是弱一致的，因此一些重要資料為了安全性考慮，不建議用mongodb。並且mongodb比較吃記憶體，如果返回大批量資料，會有記憶體不夠直接查詢失敗的情況，mongodb對olap查詢支援很弱，因此比較複雜的查詢場景也不建議使用mongodb。
列式儲存資料庫
提到列式儲存資料庫有必要先說一下什麼是行式儲存，像mysql這種屬於行式儲存，當我們查詢資料，都是以行為單位在磁碟儲存， 然後再記憶體做欄位挑選返回給使用者，如果表的字段很多我們只查詢一部分字段這樣磁碟查詢的開銷就會很大，在列式儲存資料庫中，資料存在磁碟以列為單位，我們查詢某些欄位只需要在對應的列上進行搜尋，這樣效能就會提高。
列式儲存比較出名的資料庫是clickhouse，clickhouse是定義為olap型別的資料庫，專門用來處理資料分析型業務。clickhouse採取了並行處理機制，所以做分析查詢速度非常快，對於一些搜尋，分析，資料規模大的查詢效能支援非常好，所以這種業務可以採用clickhouse去做。但是由於clickhouse專為分析查詢而生，因此對於更新刪除操作支援並不是怎麼好，修改刪除都是採取的追加寫方式，主要是為了避免隨機io，clickhouse會在底層非同步的去做資料合併，如果需要頻繁的對資料來源進行修改，那不絕對不要使用clickhouse。如果需要寫入資料，也需要採取批量寫入的方式，clickhouse會對資料進行壓縮儲存，提高資源利用率。
列式儲存另乙個比較出名的是elasticsearch，在一些偏向搜尋的場景比較用的比較多，支援倒排索引，並且支援各種聚合運算，查詢效能強勁，但是成本相比clickhouse比較高昂，可以根據業務進行選型，考慮。
時序資料庫
時序資料庫從字面意思理解來說是關於時間點的資料，時間序列表示的資料，一般在指標取樣的場景會用到，可以很直觀的看出資料隨時間變化，比較著名的有opentsdb，時序資料隨時間增長，如果資料沒有變化重複取上乙個值。時序資料庫適用於大批量的資料取樣分析，常用在批處理，流處理後的資料落地，這些資料經過加工後直接批量寫入到opentsdb中，供業務層訪問，以提高查詢效能。美中不足的是如果資料加工錯誤，糾錯成本太大。opentsdb底層是用的hbase，hbase特點是對寫效能支援比較好，底層也是為了避免隨機io採用追加寫的技術。讀通過順序讀保證效能，如果是隨機讀效能會很差，因此opentsdb應用場景限制於按時間維度分析資料的場景。
分布式檔案儲存系統
分布式檔案儲存系統的選型要根據檔案的形式，大小，用途去考慮。還需要對引數做大量的調優以得到最佳的效能。傳統的本地檔案系統檔案都是存在磁碟中，而分布式檔案系統檔案需要儲存在其他節點，本地進行訪問時還需要經過網路中轉的開銷，如果檔案比較大，頻寬就限制了傳輸的速度。這個時候就需要進行將檔案分片進行儲存。以glusterfs為例，glusterfs的 distributed volumes 屬於分布式卷，如果需要保證資料安全可以做冗餘，glusterfs支援replica和糾刪碼兩種資料冗餘方式，如果做資料冗餘，會影響讀寫效能。在做選型時，有這兩方面考慮，如果追求極致的資料安全，使用replica volumes，如果為了效能，也為了安全，使用糾刪碼的方式，如果追求極致效能，可以考慮分布式卷，但是如果出現機器宕機則會造成資料丟失。
微服務的資料庫設計
微服務設計的乙個關鍵是 資料庫設計，基本原則是每個服務都有自己單獨的資料庫，而且只有微服務本身可以訪問這個資料庫。它是基於下面三個原因。理想的設計是你的資料庫只有你的服務能訪問，你也只呼叫自己資料庫中的資料，所有對別的微服務的訪問都通過服務呼叫來實現 請參閱 微服務之間呼叫的最佳設計 當然，在實際應...
mysql資料庫如何做快取 MySql資料庫快取
對mysql查詢快取及sql server過程快取的理解及總結 一 mysql的query cache 1 query cache mysql query cache是用來快取我們所執行的select語句以及該語句的結果集。mysql在實現query cache的具體技術細節上類似典型的kv儲存，就...
微服務搭建資料庫系統
資料訪問層是微服務系統中比較重要的一環，怎樣通過 springboot 搭建資料庫環境，單資料來源與多資料來源的比較與實現方式，以及怎樣結合 mybatis 不僅能夠實現自動實現資料庫表與實體類 dao 層的自動生成，還能夠實現動態資料來源訪問等。多資料來源中常用到的核心技術。那麼，通過本場 cha...