數據庫選型入門必讀：如何在眼花繚亂的產品中挑出最適合業務的？

互聯網+AI時代，隨著業務場景越來越復雜，各種開源和商業數據庫品類繁多，讓不少開發者眼花繚亂，無從下手。

業界有句俗語，任何脫離業務來談架構都是瞎扯。所以用戶在數據庫選型時，需要從自身業務架構、業務數據量、數據類型、甚至團隊成員的業務能力等多角度平衡，考量應該選擇何種數據庫。

那么，我們到底該如何根據每種數據庫的特性選擇最適合自己業務的？

強調事務，選它

首先談談應用最廣泛的關系型數據庫，關系型數據最大的特點便是事務，它能保證數據始終如一的一致性，這里就不得不提及一下事務的ACID特性：

原子性：事務是一個不可再分割的工作單元，事務中的操作要么都發生，要么都不發生，不存在只執行了其中某一個或者某幾個步驟。

一致性：事務執行后，數據庫狀態與其業務規則保持一致。如轉賬業務，無論事務執行成功與否，參與轉賬的兩個賬號余額之和應該是不變的。

隔離性：多個事務并發訪問時，事務之間是隔離的，一個事務不應該影響其它事務運行效果。

持久性：在事務完成以后，該事務對數據庫所作的更改便持久的保存在數據庫之中，不會因為異常、宕機而造成數據錯誤或丟失。

另外，通用的SQL語言使得操作關系型數據庫非常方便，支持join等復雜查詢。

根據它的特點，關系數據庫的適用場景通?？梢苑譃镺LTP和 OLAP。

其中，聯機事務處理（OLTP）存儲/查詢業務應用中活動的數據，以支撐日常的業務活動，是每個企業不可或缺的生產交易系統。這類型應用數據量普遍不大，強調實時、快速響應、數據強一致性，比如銀行存取錢，購物消費。

聯機分析處理（OLAP）存儲歷史數據以支撐復雜的分析操作，側重于決策支持，這類應用數據量大，高并行、低并發，可用性要求不高，比如客服系統，銷售系統等。

以MySQL為例，這是當前最流行的開源關系型數據庫，也是OLTP場景的首選數據庫。

華為的GaussDB(for MySQL)和GaussDB(openGauss)核心競爭力也是OLTP的處理能力，同時具備一定的OLAP的處理能力。

但是通常不建議把OLTP和OLAP業務完全混合，在典型的OLAP處理場景就應該使用面向OLAP設計的數據庫，而在典型的OLTP處理場景就使用面向OLTP設計的數據庫，否則既達不到OLAP的擴展性，又無法滿足OLTP的實時、高性能等要求。

需要強調的是，特別不建議基于OLAP去增加TP的能力，因為后者是實時和在線，而AP更多是分析，OLAP的數據庫往往無法達到性能要求，即便上線初期看似能滿足要求，但隨著業務量的增加，問題就會凸顯出來。

除此之外，還要根據是否支持JSON格式、支持的存儲模式等維度評估，細節很多，所以在根據業務場景選擇數據庫的時候，一定要慎之又慎，靈活變通。

最后在具體業務場景方面，安利以下華為云的數據庫產品。

網站業務——網站業務請求寫少讀多，可使用云數據MySQL只讀實例水平擴展讀負載能力，搭配分布式數據庫中間件DDM使用，實現自動讀寫分離和讀負載均衡。

移動應用——包含定位功能的移動應用可使用云數據庫Postgre SQL數據庫獲得位置運算能力；數據龐大的移動應用，搭配DDM使用華為云RDS MySQL數據庫，輕松應對分庫分表問題。

游戲業務——爆發式增長的玩家數據存儲和讀寫請求，可以使用華為云RDS快速擴容存儲，變更規格或部署新的游戲分區數據庫；游戲數據存檔或回退，可使用華為云RDS自動備份和PITR特性隨時閃回到任意時間點。

電商業務——電商“秒殺”、“搶購”等高并發的數據庫請求，可使用華為云RDS高規格實例；業務連續性要求高的電商業務，可使用華為云RDS雙機熱備，跨AZ部署獲得更高可用性支持。

金融業務——金融級業務連續性和數據可靠性要求，可使用華為云RDS雙機熱備，跨AZ部署，或者華為自研的分布式數據庫的GaussDB，確保服務高可用，數據多副本存儲和強一致性；金融級安全合規要求，可搭配數據庫安全服務DBSS使用，實時監測并攔截SQL注入，防脫敏數據泄露，審計數據庫日志。

針對特定場景，滿足高并發讀寫，選它

關系型數據庫雖好，但在很多方面也有些力不從心。比如面對高并發讀寫需求時，多表的關聯查詢、復雜的數據分析類型，為了保證ACID特性而犧牲的性能問題就凸顯出來了。

這種時候，就是非關系型數據庫的天下了。

NoSQL不再將數據的一致性作為重點，它針對特定場景，以高性能和使用便利為目的。目前，應用比較廣泛的非關系型數據庫有以下幾種：文檔數據庫、key-value數據庫、列存儲數據庫、時序數據庫和圖數據庫。

文檔數據庫：

文檔數據庫會將數據以文檔的形式儲存。每個文檔都是自包含的數據單元，是一系列數據項的集合。每個數據項都有一個名稱與對應的值，值既可以是簡單的數據類型，如字符串、數字和日期等；也可以是復雜的類型，如有序列表和關聯對象。數據存儲的最小單位是文檔，同一個表中存儲的文檔屬性可以是不同的，數據可以使用XML、JSON或者JSONB等多種形式存儲。

代表產品：MongoDB、CouchDB、RavenDB

適用場景：

1. 日志：企業環境下，每個應用程序都有不同的日志信息。文檔數據庫并沒有固定的模式，我們可以使用它儲存不同的信息。

2. 分析：因為它的弱模式結構，所以不改變模式下就可以儲存不同的度量方法以及添加新的度量。

備注：以MongDB為例，其使用場景很大程度上可以對標關系型數據庫，但是比較適合處理那些沒有join、沒有強一致性要求且表Schema會常變化的數據。

鍵值數據庫：

鍵值數據庫就像在傳統語言中使用的哈希表。可以通過key來添加、查詢或者刪除數據，鑒于使用主鍵訪問，所以會獲得不錯的性能及擴展性。它的優勢在于簡單、易部署、高并發。

主流代表產品：Riak、Redis、Memcached

適用場景：儲存用戶信息，比如會話、配置文件、參數、購物車等等，具體包括游戲場景中的角色信息、經驗道具信息、好友排名，電商場景中的海量商品展示信息、購物評論信息等，這些信息一般都和 ID（鍵）掛鉤，所以鍵值數據庫是個很好的選擇。

列存儲數據庫：

列存儲數據庫將數據儲存在列族中，一個列族存儲經常被一起查詢的相關數據。舉個例子，如果有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列族中，而薪資則在另一個列族中。

代表產品：Cassandra、HBase

適用場景：

1. 日志：可以將數據儲存在不同的列中，每個應用程序能夠將信息寫入自己的列族中。

2. 博客平臺：儲存每個信息到不同的列族中，舉個例子，標簽可以儲存在一個列族，類別、文章也可以分別存儲在不同的列族。

時序數據庫：

時序數據庫就是存放時序數據的數據庫，它需要支持時序數據的快速寫入、持久化、多緯度的聚合查詢等基本功能。對比傳統數據庫僅僅記錄了數據的當前值，時序數據庫記錄了所有的歷史數據。它的查詢也總是會帶上時間作為過濾條件，數據以時間流的方式存在，每條記錄包括時間戳。可以更加高效快速的存儲大量時間序列數據并對這些數據進行實時分析。

代表產品：Prometheus、InfluxDB和OpenTSDB

適用場景：IoT傳感器時序數據分析；證券及加密貨幣交易數據；軟硬件設備實時監控；都市環保數據采集等等。

圖數據庫：

數據以圖的方式儲存。實體會被作為頂點，而實體之間的關系則會被作為邊。比如我們有三個實體，Steve Jobs、Apple和Next，則會有兩個“Founded by”的邊將Apple和Next連接到Steve Jobs。

代表產品：Neo4J、Infinite Graph、OrientDB

適用場景：

1. 在一些關系性強的數據中，用于構建關系圖譜，例如社交網絡。

2. 推薦引擎。如果我們將數據以圖的形式表現，會非常有益于推薦的制定。

在非關系型數據庫服務領域，華為云也推出了GaussDB(for Mongo)、GaussDB (for Redis)、GaussDB (for Influx)、GaussDB(for Cassandra）。目前，GaussDB(for Mongo)、GaussDB(for Cassandra)、GaussDB (for Redis)已正式商用，開發者可以根據不同的數據模型和處理邏輯來選擇與業務相符的數據庫。

最后：

舉個簡單例子，如果你的業務有大量的結構化數據且存在許多事務性操作，那首選肯定就是MySQL這樣的數據庫。

如果你的業務經常有突發的流量高峰，則優先考慮適用MangoDB這樣的非關系型數據庫，有比較好的擴展性。

數據庫的選擇決定了業務的可持續發展，所以一定要多花功夫，“因地制宜”根據業務實際情況，選擇最適合的數據庫。

注：文章中部分概念性內容源自網絡。

數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。