Tag: relational

Amazon 又把一個大部門的 Oracle 系統轉移到了 AWS 自家的系統

算是 AWS 的 PR 稿，在老闆對雲的宣示與政治正確下本來就會陸陸續續轉過去...

這次是 Amazon 的 Consumer Business 從 Oracle 的系統換到 AWS 自己的系統：「Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database」。

原先有 75 PB 的資料與 7500 個 database：

We migrated 75 petabytes of internal data stored in nearly 7,500 Oracle databases to multiple AWS database services including Amazon DynamoDB, Amazon Aurora, Amazon Relational Database Service (RDS), and Amazon Redshift.

其中一個優點是省成本，但是也投入了超過一百個團隊一起參與轉移，會需要攤多久才會打平，這點在沒有看到內部財務資料其實沒辦法判斷，而且工程資源的稀缺性也是個沒有被看到的資訊：

Cost Reduction – We reduced our database costs by over 60% on top of the heavily discounted rate we negotiated based on our scale. Customers regularly report cost savings of 90% by switching from Oracle to AWS.

More than 100 teams in Amazon’s Consumer business participated in the migration effort.

然後 latency 的下降其實也只能參考，因為轉移系統的時候也會順便改寫，有多少是因為 AWS 服務本身帶出來，在沒有內部資料看不出來：

Performance Improvements – Latency of our consumer-facing applications was reduced by 40%.

管理成本算是裡面唯一可以參考的，畢竟是搬到可延展擴充的服務：

Administrative Overhead – The switch to managed services reduced database admin overhead by 70%.

另外，沒寫的東西比較有趣，像是他們沒有選擇 Athena 而是用 Redshift，看起來像是先轉上去，其他找機會再說...

Relational Database System (RDBMS) 運作的方式

在「How does a relational database work」這篇文章用了很長的篇幅講「資料庫如何把 SQL query 轉換為實際的操作」：

I’ll focus on what I think is essential: the way a database handles an SQL query.

資料庫也是人寫出來的，資料結構與演算法也是人設計出來的。你現在手上有資料，要怎麼把 SQL query 變成有效率的查詢操作行為，就是這篇文章在描述的。

看起來連 JOIN 的機制也講了不少...

資料結構、RDBMS、ORM

欠了很久的雜記。既然是雜記，只是把一些事情記錄下來，許多句子的主題會跳來跳去，請多見諒。

先解釋標題的三個詞彙。這邊要講的是三種存取資料的方式：

  • 資料結構：直接操作最底層的資料結構。
  • RDBMS (Relational Database Management System，關聯式資料庫)：透過 RDBMS 存取資料的方式，在 open source 領域比較常遇到 MySQL 與 PostgreSQL。由於與下面的 ORM 比較，這一條指的是透過 SQL query 去存取資料。
  • ORM (Object-Relational Mapping)：透過程式語言的 object 以及 object 之間的關聯性存取資料。

彈性最高、效能也最好的是直接的資料存取，但寫起來也最複雜；而 ORM 大致上就是反過來。

現代的 RDBMS 大多都有實做 ACID，在自己操作資料結構時考慮這塊會比較辛苦。兩個層級之間有一些 library 試著解決這個問題 (像是 BerkeleyDB 或是 LevelDB)，不過這篇文章暫時跳過。

MySQL 與其他的 RDBMS 比較起來欠了許多東西，但 High Availability 的成熟度以及效能而成為 open source 的第一選項。而也因為許多人使用，大家都知道 MySQL 的先天限制，也有許多 workaround 出現，所以大多數的狀況下這不是問題。

MySQL 的 InnoDB 其實寫的相當不錯，但 MySQL 的 SQL parser 一直都是 MySQL 的痛處，所以許多人使用 MySQL 時會儘量使用 simple query，而 ORM 的特性剛好可以搭上風。

使用 ORM 時最常見要避免的是 N+1 的問題，其他常見到的問題大多都不是 ORM 專有的。

先整理到這邊。