這篇是因為 DBA 同事最近問到關於 Aurora 的整合方案,其實 Aurora Integrating 文件都有寫到,在這邊我會稍微整理一下可能會用到的情境跟用法。
先講在前面,以下幾個 AWS 服務集成的用法都必須另外設定 IAM Policy 權限,而各個服務的集成限制也必須先詳細閱讀,像是 Aurora ML 的 MySQL 版本 ..
Aurora Invoking Lambda 這個功能主要是想要取代 MySQL stored procedure 透過內建函數 lambda_sync
、lambda_async
執行 Lambda,有 DBA 對 MySQL stored procedure 熟悉的人應該就知道限制很多,甚至根本乾脆不想用 … 但是 Invoking Lambda 可以支援的彈性就大的多,包含 Lambda 背後支援的一大包 Service integration …
當 Aurora 本身常需要執行複雜運算時又不想透過 Application 搞,就可以利用 Aurora Invoking Lambda 來跑 … 基本上就是原本 stored procedure 的使用情境。
將 Aurora Logs 丟到 CloudWatch Logs
這個沒什麼好講的,就是把 Aurora Logs 丟到 CloudWatch Logs,一來方便查詢,二來是 CloudWatch Logs 往後支援的 Event、Metrics、Alert … 等一拖拉庫支援。
透過 LOAD DATA FROM S3
、LOAD XML FROM S3
操作 S3 資料,來源資料 text 或 xml 格式,使用情境一般來說可能會是避免直接訪問 Aurora 或者非同步的資料寫入。
透過 SELECT INTO OUTFILE S3
將資料寫到 S3,使用情境最常見就是 Low Data 資料攜出,去識別化是很常見的情境。也有用來備份,畢竟 Aurora point in time 的備份並不會有 LOW Data。
Aurora Machine Learning
Aurora Machine Learning 是讓 Aurora 整合 SageMaker 和 Comprehend 直接對資料庫進行 Machine Learning,這大概是 AWS Database 做 ML 最簡單快速的用法,不需要侵入式的先把資料 dump 或者 replication 一份另外做,
由於 Aurora Machine Learning 的整合方式是直接對 Aurora SELECT,當資料結構改變或者分析資料異動時,只要修改 SELECT Function 就好,而 Application 可以直接對 SageMaker/Comprehend 獲取分析結果。
參考官方 Blog 範例「New for Amazon Aurora – Use Machine Learning Directly From Your Databases」價格上並不貴,但是對於資料庫版本有較高的需求 (MySQL 就要 5.7 以上),因為是基於執行 SELECT 的方式,Reader instance 也是必要項,不然會影響 Writer 效能。