共計(jì) 2295 個字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。
這篇文章給大家分享的是有關(guān) AWS 有哪 6 款數(shù)據(jù)庫的內(nèi)容。丸趣 TV 小編覺得挺實(shí)用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。
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í)亞馬遜移植了市面上常用的幾款數(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ā)的讀寫實(shí)際上是一對兒矛盾的綜合體。
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)行大量的聚合計(jì)算：數(shù)據(jù)量大，計(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ù)哦！！！
你說這就可以了吧：傳統(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)報(bào)告，北京到上海的一趟貨車延遲了，那有多少用戶會受到影響呢？一趟車可能影響 10 條物流鏈路？影響 50 個城市? 影響 2000 個用戶？估計(jì)我們需要把系統(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ù)庫。因?yàn)楹芏鄬?shù)據(jù)的查新都是以時間段為基礎(chǔ)的。Timestream 就是針對這個場景的。
QLDB
QLDB 的全稱是 Quantum Ledger Database。它的應(yīng)用場景也很好理解，最適合的場景是“記賬本”。“賬本”是不能被更改的，每一筆記錄都不能被改動，被忠實(shí)的記錄下來，已被查詢。QLDB 就應(yīng)運(yùn)而生了。是不是有點(diǎn)兒“區(qū)塊鏈”的意思？只不過 QLDB 是有中心的。
感謝各位的閱讀！關(guān)于“AWS 有哪 6 款數(shù)據(jù)庫”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
