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

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

我們提供的服務(wù)有：網(wǎng)站建設(shè)、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、定陶ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的定陶網(wǎng)站制作公司

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)用場景都捕捉到了。

接下來逐一介紹下：

RDS （Relational Database Service)

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

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

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

RDS-Aurora

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

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

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

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

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

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

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

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

Redshift

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

這時候，就需要Redshift出場了。Redshift說起來也是關(guān)系型數(shù)據(jù)庫，但是它和RDS們有個本質(zhì)的不同，它不是按“行”來存儲數(shù)據(jù)的，而是按“列”來的。不僅如此，它還按照“列”，對數(shù)據(jù)進(jìn)行了排序！基本上這就是為了做“聚合”而誕生的數(shù)據(jù)庫?。《野戳芯酆系臄?shù)據(jù)庫很方便壓縮，Redshift可以處理PB級數(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ù)庫”，特別以“鍵值存儲”為核心。可以高效的進(jìn)行大數(shù)據(jù)/大文件的快速讀取。

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

Neptune

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

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

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

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

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

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

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

Timestream

顧名思義，Timestream是和時間相關(guān)的數(shù)據(jù)庫。因為很多對數(shù)據(jù)的查新都是以時間段為基礎(chǔ)的。Timestream就是針對這個場景的。

QLDB

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

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

新聞標(biāo)題：AWS有哪6款數(shù)據(jù)庫
文章起源：http://m.jiaotiyi.com/article/ispcej.html