如今，數(shù)據(jù)的重要性已經(jīng)滲透到各個(gè)領(lǐng)域，并已成為每個(gè)行業(yè)發(fā)展和轉(zhuǎn)型的必要元素。但是，我們?nèi)匀恍枰獢?shù)據(jù)庫來幫助我們存儲(chǔ)和組織這些數(shù)據(jù)。在Internet時(shí)代，擁有可用功能的單個(gè)數(shù)據(jù)庫的時(shí)代已經(jīng)過去，對(duì)數(shù)據(jù)庫的新需求也在不斷出現(xiàn)。隨著這些新要求的提出，越來越多的公司意識(shí)到使用傳統(tǒng)數(shù)據(jù)庫來滿足不同需求的“一刀切”方法已不再有效。因此數(shù)據(jù)庫類型也在逐漸的增多，以此來滿足需求。那么數(shù)據(jù)庫類型有哪些？如何選擇合適的數(shù)據(jù)庫類型？

　　數(shù)據(jù)庫類型有哪些？

　　1.關(guān)系型數(shù)據(jù)庫

作為被廣泛采用的數(shù)據(jù)庫類型，關(guān)系型數(shù)據(jù)庫在很多場景下，比如企業(yè)的 ERP，CRM，財(cái)務(wù)系統(tǒng)和交易系統(tǒng)等，具有獨(dú)特的優(yōu)勢。這些場景下，客戶通常會(huì)有對(duì)于數(shù)據(jù)有強(qiáng)一致性的需求，要求數(shù)據(jù)庫支持事務(wù)性處理（Transactional Processing）。基于客戶這一需求，AWS 為此構(gòu)建了 Amazon Aurora 數(shù)據(jù)庫。Amazon Aurora 是一個(gè)針對(duì)云構(gòu)建的與 MySQL 和 PostgreSQL 兼容的關(guān)系型數(shù)據(jù)庫，它結(jié)合了高端商業(yè)數(shù)據(jù)庫的性能和可用性，以及開源數(shù)據(jù)庫的簡單性和成本效益。

　　2.鍵 - 值型數(shù)據(jù)庫

在移動(dòng)互聯(lián)網(wǎng)，電商，游戲以及物聯(lián)網(wǎng)等很多新型場景中，數(shù)據(jù)庫需要面對(duì)超大規(guī)模的數(shù)據(jù)處理，同時(shí)又需要低延遲的性能保障。對(duì)于這些需要極高的吞吐量和并發(fā)性、低延遲以及可靠性的需求，我們提供了 Amazon DynamoDB。這是一款適用于任何規(guī)模的快速靈活的 NoSQL 數(shù)據(jù)庫服務(wù)。

　　3.文檔型數(shù)據(jù)庫

很多客戶將 MongoDB 用作文檔數(shù)據(jù)庫，用于存儲(chǔ)、檢索和管理半結(jié)構(gòu)化數(shù)據(jù)。由于設(shè)置和管理 MongoDB 集群所帶來的復(fù)雜性，在 MongoDB 上構(gòu)建可以快速擴(kuò)展到多兆字節(jié)（TB）和每秒數(shù)十萬次讀寫的高性能、高可用性的應(yīng)用程序極具挑戰(zhàn)性。為此，AWS提供了Amazon DocumentDB，它是一項(xiàng)快速、可擴(kuò)展、高度可用且完全托管的文檔數(shù)據(jù)庫服務(wù)，支持 MongoDB 工作負(fù)載。作為一個(gè)文檔數(shù)據(jù)庫，Amazon DocumentDB 使得存儲(chǔ)、查詢和索引 JSON 數(shù)據(jù)變得簡單。

　　如何選擇合適的數(shù)據(jù)庫類型？

個(gè)人的理解是結(jié)合以下幾個(gè)方面來考慮：

　　1讀寫速度

這存儲(chǔ)數(shù)據(jù)方式往往決定讀寫的速度。

1）Mysql無論數(shù)據(jù)還是索引都存放在硬盤中。到要使用的時(shí)候才交換到內(nèi)存中。能夠處理遠(yuǎn)超過內(nèi)存總量的數(shù)據(jù)。

2）MongoDB的所有數(shù)據(jù)實(shí)際上是存放在硬盤的，所有要操作的數(shù)據(jù)通過mmap的方式映射到內(nèi)存某個(gè)區(qū)域內(nèi)。然后，MongoDB就在這塊區(qū)域里面進(jìn)行數(shù)據(jù)修改，避免了零碎的硬盤操作。

3）Redis所有數(shù)據(jù)都是放在內(nèi)存中的。但是它也支持?jǐn)?shù)據(jù)持久化到硬盤中。

我們都知道磁盤讀取數(shù)據(jù)的效率遠(yuǎn)遠(yuǎn)低于內(nèi)存。所以在一般情況下，這三者的讀寫數(shù)據(jù)的速度排序是：Redis>MongoDB>Mysql

　　2是否支持事務(wù)以及復(fù)雜查詢

MySql是關(guān)系型數(shù)據(jù)庫，支持事務(wù)操作以及join方式的復(fù)結(jié)構(gòu)化查詢。而MongoDB是非關(guān)系型數(shù)據(jù)庫，既不支持事務(wù)操作，也不支持join操作。Redis同樣不支持。

因此，針對(duì)以下場景應(yīng)考慮使用MySql：

1）業(yè)務(wù)數(shù)據(jù)中有大量結(jié)構(gòu)化數(shù)據(jù)，如用戶賬號(hào)、地址等。因?yàn)檫@些數(shù)據(jù)通常需要做結(jié)構(gòu)化查詢。

2）業(yè)務(wù)存在許多事務(wù)性操作，需要保證事務(wù)的強(qiáng)一致性。

　　3業(yè)務(wù)數(shù)據(jù)量增長速度

在一到兩年內(nèi)，業(yè)務(wù)數(shù)據(jù)的增長量不在預(yù)測范圍內(nèi)，優(yōu)先考慮使用MongoDB。

因?yàn)镸ongoDB內(nèi)建了sharding、很多數(shù)據(jù)分片的特性，容易水平擴(kuò)展，比較好的適應(yīng)大數(shù)據(jù)量增長的需求。而MySql在這方面表現(xiàn)要遜色些，MySql單表數(shù)據(jù)量達(dá)到5-10G時(shí)會(huì)出現(xiàn)明細(xì)的性能降級(jí)，需要做數(shù)據(jù)的水平和垂直拆分、庫的拆分完成擴(kuò)展。

Redis由于內(nèi)存容量限制，不會(huì)用來存儲(chǔ)大量數(shù)據(jù)。一般拿它做緩存。

　　4表結(jié)構(gòu)是否明確

如果在業(yè)務(wù)場景中，數(shù)據(jù)庫表接口不明確，數(shù)據(jù)還在不斷增加。例如以下場景，內(nèi)容管理平臺(tái)，用戶社交平臺(tái)，優(yōu)先考慮使用MangDB。

因?yàn)镸ongoDB是非結(jié)構(gòu)化文檔數(shù)據(jù)庫，擴(kuò)展字段很容易且不會(huì)影響原有數(shù)據(jù)。

上述就是關(guān)于數(shù)據(jù)庫類型有哪些，以及如何選擇合適的數(shù)據(jù)庫類型的全部內(nèi)容，想了解更多關(guān)于數(shù)據(jù)庫的信息，請繼續(xù)關(guān)注中培偉業(yè)。