AWS數(shù)據(jù)庫介紹,aws免費數(shù)據(jù)庫-ESG跨境

AWS數(shù)據(jù)庫介紹,aws免費數(shù)據(jù)庫

AWS數(shù)據(jù)庫介紹

當有人問：數(shù)據(jù)庫分哪幾類？

我們通常的回答是：關系型的和非關系型的。

這個答案沒毛病，但是略顯簡單粗暴。如果深究一下，非關系型數(shù)據(jù)庫還有很多種型。

有種分類方法，把數(shù)據(jù)庫分成了8個大類：你沒看錯，是數(shù)據(jù)庫庫庫庫庫庫庫庫！

為什么要分這么細呢？因為時代不同了，現(xiàn)代化應用對數(shù)據(jù)處理的要求越來越苛刻。

傳統(tǒng)的關系型數(shù)據(jù)庫，發(fā)展了幾十年，遵從ACID原則，強關聯(lián)、數(shù)據(jù)一致性，擅長事務處理。

事務處理這個功能很重要，比如用銀行卡轉賬，必須保證對方賬戶錢增加的同時，而你的賬戶對應地減少了，中間出了差錯，數(shù)據(jù)庫就要“回滾”。

多少年來的金融級交易，都離不開關系型數(shù)據(jù)庫的支撐，而企業(yè)大量的ERP、CRM系統(tǒng)，都是靠關系型數(shù)據(jù)庫扛著的。

可是，隨著社交、電商、IoT等業(yè)務和應用蓬勃發(fā)展，數(shù)據(jù)尤其是非結構化數(shù)據(jù)爆發(fā)增長，傳統(tǒng)關系型數(shù)據(jù)庫有點獨木難支。

于是，數(shù)據(jù)庫進入了八仙過海，各顯神通的時代，不同的數(shù)據(jù)庫在各自的崗位上，提供了獨特的價值。

舉個例子，在電商的場景下，用戶的主要身份信息賬號密碼等，一般存在關系型數(shù)據(jù)庫里。

但用戶的“購物車”，有人放了1件商品，有的剁手黨可能會放100件商品，用關系型數(shù)據(jù)庫存儲就很不靈活。

這時候，鍵值數(shù)據(jù)庫就派上了用場，用“鍵值對”來存儲用戶的購物車信息，水平可以任意擴展。

再比如在交通和制造場景下，數(shù)據(jù)需要按照時間順序進行存儲，這里的時間不只是一個度量標準，不是一個字段，而是一個坐標的主坐標軸。

這時候，就需要時間序列數(shù)據(jù)庫，有點像我們的常見的股票交易數(shù)據(jù)，橫軸是時間，縱軸是不同時間下的所有數(shù)據(jù)。

再比如社交網絡應用，需要快速查找某人與某人的關系。

此時如果使用圖數(shù)據(jù)庫，可以快速get到結果，但是用關系型數(shù)據(jù)庫，需要大量的查詢時間，甚至超時。

總之，應用千差萬別，數(shù)據(jù)豐富多彩，要想應用跑的爽，就要投其所好，選最合適的數(shù)據(jù)庫。

而且如今，大多數(shù)現(xiàn)代應用，都不是單一類型數(shù)據(jù)庫來支撐，往往眾人拾柴，各干自己擅長的一部分。

所以，對于架構師來說，根據(jù)自家業(yè)務，把數(shù)據(jù)庫選好、規(guī)劃好很重要，同時，還要有DBA來配置和管理數(shù)據(jù)庫。

想想就很頭大！

有沒有供應商，能夠提供一攬子解決方案呢？

還真有，那就是Amazon Web Services(AWS)，上面提到的8種類別的數(shù)據(jù)庫，AWS全部提供！

AWS能提供的數(shù)據(jù)庫類型和引擎太多，我們就挑幾類來講講吧。

首先還是說關系型數(shù)據(jù)庫，雖然數(shù)據(jù)庫分類這么多，但站C位的還是“關系”，大多數(shù)系統(tǒng)的主數(shù)據(jù)都還是用關系型數(shù)據(jù)庫。

AWS的托管式Amazon Relational Database Service(Amazon RDS)服務，提供了多種引擎。

不管開發(fā)者習慣用哪種，商用的Oracle、SQL Server，開源的MySQL、MariaDB、PostgreSQL，在AWS上都能找到。

同時，AWS還提供了一套自家特色RDS方案，這就是著名的「極光」數(shù)據(jù)庫——Amazon Aurora。

Amazon Aurora提供MySQL和PG兩種兼容引擎，跨3個AZ最多提供15個讀副本、6份數(shù)據(jù)拷貝，跨區(qū)橫向擴展讀寫，跨區(qū)復制。

“極光普照”之下，吞吐量是MySQL的5倍、PG的3倍，成本卻只有傳統(tǒng)商業(yè)級數(shù)據(jù)庫的十分之一。

看到“3AZ”，是不是擔心部署和管理很復雜？沒關系，Amazon Aurora是全托管的，所有操作，云上幫你全簡化。

同時，Amazon Aurora跟AWS上的機器學習、BI、分析類的組件可以深度集成，你甚至不需要專業(yè)的機器學習知識，用標準的SQL語句就能進行機器學習預測了。

著名的虎牙直播，就采用了Amazon Aurora數(shù)據(jù)庫解決方案，相對靜態(tài)的信息，使用Amazon Aurora存儲，動態(tài)的信息則使用Amazon DynamoDB存儲。

除了性能比MySQL好太多以外，故障恢復也是極速的，異常狀態(tài)下，10s內就能自動實現(xiàn)故障轉移，終端用戶無感知。

另外，虎牙直播的Nimo TV是出海業(yè)務，利用AWS全球數(shù)據(jù)庫功能，可以就近部署，提升用戶本地體驗。

我們再來說說AWS上的其它非關系型數(shù)據(jù)庫吧。

當下最流行的緩存數(shù)據(jù)庫是Redis和Memcached，AWS提供Amazon ElastiCache，兼容這兩種引擎，為實時應用提供亞毫秒延遲。

如果談到文檔數(shù)據(jù)庫，大家肯定會對MongoDB很熟悉，AWS的Amazon DocumentDB提供對MongoDB的兼容能力。

不止于兼容，Amazon DocumentDB比標準的MongoDB托管服務快兩倍，支持自動故障轉移，并在3個AZ上提供6份數(shù)據(jù)副本。

AWS上的圖數(shù)據(jù)庫托管服務叫做Amazon Neptune，可存儲數(shù)十億的“關系”，查詢起來，延遲是毫秒級別的。

Amazon Neptune被廣泛應用于社交網絡、知識圖譜、生命科學、IT運維等領域。

還有寬表數(shù)據(jù)庫Amazon Keyspaces，分類賬數(shù)據(jù)庫Amazon QLDB，以及剛剛上新的時序數(shù)據(jù)庫Amazon Timestream……

總之，只有想不到的，沒有AWS做不到的。

講到這里，我想大家對AWS云上數(shù)據(jù)庫服務的類型和能力，大概都心中有數(shù)了。

這兩年，我也看到越來越多本地部署的數(shù)據(jù)庫，被云上數(shù)據(jù)庫替代和“碾壓”。

那么，如果你也有了數(shù)據(jù)庫上云的想法，如何才能方便、安全、快捷地把本地數(shù)據(jù)“搬”上云呢？

AWS提供了一系列DMS服務：從線下到云上、從庫到庫、庫結構轉換……，數(shù)據(jù)復制可實現(xiàn)近乎0停機時間，以保障業(yè)務不中斷，客戶無感知。

這種遷移服務靠譜不？Amazon自己就是最好的成功案例。

亞馬遜公司100多個業(yè)務團隊，各種復雜的、在線的、高并發(fā)的業(yè)務，電商、廣告、視頻、游戲、支付，原來總共使用了7500多個甲骨文數(shù)據(jù)庫，數(shù)據(jù)多達75 PB。

如今，這些數(shù)據(jù)庫全部被遷移、分流到AWS多種云數(shù)據(jù)庫上了。

自己家的云數(shù)據(jù)庫到底香不香？遷移后數(shù)據(jù)庫成本降低60%，管理工作減少了70%，而對于重要的應用，性能提高40%！

這就是活生生的云數(shù)據(jù)庫最佳實踐呀！

云上數(shù)據(jù)庫庫庫庫庫庫庫庫，八仙過海。

AWS，就是那片云海！

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發(fā)表后的30日內與ESG跨境電商聯(lián)系。