AWS有哪6款數(shù)據(jù)庫

這篇文章給大家分享的是有關(guān)AWS有哪6款數(shù)據(jù)庫的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

AWS有哪6款數(shù)據(jù)庫呢？

確切地說，我認(rèn)為是7款數(shù)據(jù)庫：

* RDS

* RDS-Aurora

* Redshift

* DynamoDB

* Neptune

* Timestream

* QLDB

(RDS和RDS-Aurora有些人認(rèn)為是同款數(shù)據(jù)庫。)

這幾款數(shù)據(jù)庫真是各有神通，幾乎把所有數(shù)據(jù)庫相關(guān)的應(yīng)用場(chǎng)景都捕捉到了。

接下來逐一介紹下：

RDS （Relational Database Service)

RDS顧名思義就是“關(guān)系型數(shù)據(jù)庫”。這里其實(shí)亞馬遜移植了市面上常用的幾款數(shù)據(jù)庫，做成了“云”的版本給客戶，包括：Oracle，MySQL, MS SQL, MariaDB, PostgreSQL。

這么做的好處，就是客戶教育成本低，遷移成本低，用自己熟悉的數(shù)據(jù)庫，又享受了云端的高可用和高性能。

這些好像沒啥，很“正?！?，還不夠“喪心病狂”，但是接下來的幾款數(shù)據(jù)庫產(chǎn)品，AWS就要開掛了。

RDS-Aurora

雖然說，Aurora是掛在RDS下面的一個(gè)數(shù)據(jù)庫產(chǎn)品，但是我認(rèn)為它完全是不一樣的。不能和其它RDS數(shù)據(jù)庫相提并論。

數(shù)據(jù)庫的一個(gè)核心問題就是解決“高并發(fā)”，其中包括：高并發(fā)的“讀”，和高并發(fā)的“寫”。（比如一個(gè)電商平臺(tái)的網(wǎng)站，對(duì)商品的查詢都是讀，下訂單則都是寫了。）

你可能會(huì)說，高并發(fā)的“讀”不難處理?。】啥鄮讉€(gè)數(shù)據(jù)部分不就行了？比如，一份數(shù)據(jù)放在10個(gè)服務(wù)器上--對(duì)于讀，來說，是這樣的。

但是，如果系統(tǒng)里面有很多數(shù)據(jù)副本的時(shí)候，高并發(fā)的“寫”就不能有效的同步到所有的副本上了--所以，高并發(fā)的讀寫實(shí)際上是一對(duì)兒矛盾的綜合體。

Aurora通過“日志即數(shù)據(jù)”的概念，把“數(shù)據(jù)引擎”和“數(shù)據(jù)存儲(chǔ)”進(jìn)行了有效的分割，從而達(dá)到了空前的高并發(fā)讀寫機(jī)能。

傳統(tǒng)的普通數(shù)據(jù)庫服務(wù)，或者普通的自建數(shù)據(jù)庫機(jī)構(gòu)，“寫”只能發(fā)生在一個(gè)“主”數(shù)據(jù)上，然后“主”再把自己的數(shù)據(jù)同步給其它副本。Aurora則不同，“寫”可以發(fā)生在任何一個(gè)可用區(qū)上。Aurora的架構(gòu)使用了3個(gè)可用區(qū)，每個(gè)可用區(qū)有2個(gè)副本，也就是一共6個(gè)副本，這6個(gè)副本都可以進(jìn)行讀寫。極大的彌補(bǔ)了，傳統(tǒng)數(shù)據(jù)庫對(duì)高并發(fā)的瓶頸。這是不是很“喪心病狂”？這是如何做到的？！

細(xì)節(jié)，在這里就不贅述了，有興趣的話，可以咨詢我們的架構(gòu)師~

高并發(fā)的讀寫是典型的OLTP（On-Line Transaction Processing聯(lián)機(jī)事務(wù)處理過程）中發(fā)生的場(chǎng)景。那么對(duì)于OLAP （On-Line Analytical Processing 在線分析過程），AWS提出了什么產(chǎn)品呢？

Redshift

和OLTP場(chǎng)景下，數(shù)據(jù)庫需要支持高并發(fā)讀寫不同，OLAP場(chǎng)景下數(shù)據(jù)庫讀寫頻率很低，數(shù)據(jù)庫需要進(jìn)行大量的聚合計(jì)算：數(shù)據(jù)量大，計(jì)算量也大。（比如，一天結(jié)束之后，我們需要對(duì)今天的用戶行為進(jìn)行分析，所有用戶行為數(shù)據(jù)可能是幾個(gè)TB。）

這時(shí)候，就需要Redshift出場(chǎng)了。Redshift說起來也是關(guān)系型數(shù)據(jù)庫，但是它和RDS們有個(gè)本質(zhì)的不同，它不是按“行”來存儲(chǔ)數(shù)據(jù)的，而是按“列”來的。不僅如此，它還按照“列”，對(duì)數(shù)據(jù)進(jìn)行了排序！基本上這就是為了做“聚合”而誕生的數(shù)據(jù)庫啊！而且按列聚合的數(shù)據(jù)庫很方便壓縮，Redshift可以處理PB級(jí)數(shù)據(jù)哦?。。?/p>

你說這就可以了吧：傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，AWS有了；OLTP數(shù)據(jù)庫有了；OLAP數(shù)據(jù)庫也有了。AWS覺得還不夠！

DynamoDB

上面的都是關(guān)系型數(shù)據(jù)庫。DynamoDB是AWS提供的一款“非關(guān)系型數(shù)據(jù)庫”，特別以“鍵值存儲(chǔ)”為核心。可以高效的進(jìn)行大數(shù)據(jù)/大文件的快速讀取。

如果你是游戲行業(yè)/醫(yī)療行業(yè)/影視娛樂行業(yè)有大文件需要讀取的話，那么你有福了。：）

Neptune

關(guān)系型數(shù)據(jù)庫有了，非關(guān)系型也有了！還不夠嗎？對(duì)于亞馬遜來說，當(dāng)然不夠！

AWS又推出了“圖數(shù)據(jù)庫”。在現(xiàn)在這個(gè)社交應(yīng)用（大數(shù)據(jù)相關(guān)性）橫行的年代，沒有圖數(shù)據(jù)庫，取一個(gè)簡(jiǎn)單的人際關(guān)系，用“關(guān)系型數(shù)據(jù)庫”真是要累死的。舉2個(gè)簡(jiǎn)單的例子：

1. 我們想知道用戶A和用戶B是幾度好友？如果A和B是直接好友也就罷了，用關(guān)系型數(shù)據(jù)庫Join一次也就行了。但是，萬一是10度好友呢？總不能Join 10次吧。關(guān)鍵是，如果不知道是幾度好友，難道要無限的Join下去嗎？

2. 我們的物流系統(tǒng)報(bào)告，北京到上海的一趟貨車延遲了，那有多少用戶會(huì)受到影響呢？一趟車可能影響10條物流鏈路？影響50個(gè)城市?影響2000個(gè)用戶？估計(jì)我們需要把系統(tǒng)里面所有的數(shù)據(jù)都關(guān)聯(lián)查詢一遍才能有個(gè)結(jié)論，成本太高了。

在上面的場(chǎng)景里面（也就是不斷的大量的Join出現(xiàn)的時(shí)候），圖數(shù)據(jù)庫就是一個(gè)利器了。

這都已經(jīng)好幾款數(shù)據(jù)庫了，還不夠嗎？AWS覺得還不夠。2018年的時(shí)候，它居然同時(shí)發(fā)布了兩款新數(shù)據(jù)庫！??！

我真是要給這家公司跪了。

Timestream

顧名思義，Timestream是和時(shí)間相關(guān)的數(shù)據(jù)庫。因?yàn)楹芏鄬?duì)數(shù)據(jù)的查新都是以時(shí)間段為基礎(chǔ)的。Timestream就是針對(duì)這個(gè)場(chǎng)景的。

QLDB

QLDB的全稱是Quantum Ledger Database。它的應(yīng)用場(chǎng)景也很好理解，最適合的場(chǎng)景是“記賬本”?！百~本”是不能被更改的，每一筆記錄都不能被改動(dòng)，被忠實(shí)的記錄下來，已被查詢。QLDB就應(yīng)運(yùn)而生了。是不是有點(diǎn)兒“區(qū)塊鏈”的意思？只不過QLDB是有中心的。

感謝各位的閱讀！關(guān)于“AWS有哪6款數(shù)據(jù)庫”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！