Amazon RDS

雲端服務 Amazon Web Service (1)

基本介紹

教學目標

學會如何根據不同的需求選擇 Amazon Web Service 中最適合的資料儲存服務。

重點概念

針對需求根據下表的不同項目進行評估,就能在初期篩選出最適合的資料儲存服務。

DynamoDB RDS Redshift EMR S3 Elasitc Cahche Glacier
平均延遲 毫秒 毫秒、秒 秒、分鐘 秒、分鐘、小時 毫秒、秒、分鐘 毫秒 小時
資料大小 GB ~ TBs GB ~ TB (3TB) TB ~ PB (1.6PB) GB ~ PB GB ~ PB GB GB ~ PB
項目大小 KB (64KB) KB KB (64KB) KB ~ MB KB ~ GB B ~ KB GB
結構
請求率 低 ~ 高
持久性 低 ~ 中
儲存成本

(參考資源: AWS re:Invent 2014 | (BDT310) Big Data Architectural Patterns and Best Practices on AWS )

相關資源

2014Q3 工作心得 (2)

Amazon 的雲端服務越來越方便,身為工程師常常會想要所有服務都自建才會有成就感,但卻忽略最重要的可用性 (Availability) 與延展性 (Scalability) 的問題。

針對可用性的問題,我們曾經嘗試使用 AWS EC2 上運行資料庫伺服器 (MongoDB) 取代 AWS RDS 資料庫雲端服務,AWS EC2 當預設 EBS 大小為 8 GB ,所以當資料內容佔儲存空間的 90% 時,就必需要進行擴充,最基本的問題則是如何在維持可用性的情況下進行資料庫大小的調整,此時 AWS RDS 資料庫雲端服務只需透過簡單的設定就能完成上述需求,反之自建則需要很複雜的流程才能在維持可用性的情況下進行資料庫大小的調整。

針對延展性的問題,我們曾經嘗試使用 AWS EC2 上運行負載平衡器伺服器 (Ngnix) 取代 AWS ELB 負載平衡雲端服務,最基本的問題則是如何當在每台 AWS EC2 的負載在特定條件時會自動進行伺服器的延展,此時 AWS ELB 負載平衡雲端服務,只需搭配 AWS Auto Scaling 自動延展雲端服務只需透過簡單的設定就能完成上述需求,反之自建需要很複雜的流程才能在特定條件時會自動進行伺服器的延展。

(註: Node.js 伺服器程式可以搭配 PM2 達到開機自動啟動,接著打包成 AMI 檔案就能夠套用至自動延展的流程之中。)

最後透過 AWS CloudWatch 資源監控服務,就能即時監控所有 AWS 雲端服務的運作情況,同時搭配 AWS SNS 推播通知雲端服務就能在緊緊事件發生的第一時間寄信給管理者進行危機處理。

2014Q2 工作心得 (1)

目前只要談到巨量資料分析,幾乎都會想到 Hadoop 的完整的生態環境,可是對於新創公司的我們資料量的確還未到達立即需要使用 Hadoop 分散式處理的程度,因為透過 Google Analytics 中的事件定義就能滿足我們當時對於資料的營運需求。

此外 Google BigQuery 雲端服務剛剛推出沒多久,並且有提供新創公司的試用方案,更重要的是 Hadoop 主要是基於 Google 在 2004 年所提出的 MapReduce 軟體架構進行分析,然而 Google BigQuery 主要是基於 Google 在 2010 年所提出的 Dremel 分散式資料分析系統,根據 Google 官方的研究報告,我們可以很清楚的了解 Dremel 的確比 MapReduce 擁有更快的處理效能。

所以我們就決定投入時間將 Amazon RDS 中 2014 年第二季資料匯入至 Google BigQuery 之中,接著透過 SQL 查詢指令將原本需要花費數三十分鐘以上才能完成的工作縮短至不到五分鐘皆能完成,最後再搭配 Google Spreedsheet 試算表中的 Script 腳本指令,就能夠透過資料以圖表呈現的方式讓行銷人員進行參考。