Home » Posts tagged "on"

Amazon DynamoDB 的 Point-In-Time Recovery

Amazon DynamoDB 在 3/26 發出來的功能,以秒為單位的備份與還原機制:「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。

先打開這個功能:

打開後就會開始記錄,最多可以還原 35 天內的任何一個時間點的資料:

DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.

這時候就算改變資料或是刪除資料,實際上在系統內都是 Copy-on-write 操作,所以需要另外的空間,這部份會另外計價:

Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.

有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果),現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD

最後有提到支援的地區,是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援:

PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.

比對一下,應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域,另一個是本來上新功能就偏慢的區域。

GitHub 升級到 Rails 3 了...

GitHub 從 2.3.github 特製版升級到 Rails 3:「Upgrading GitHub to Rails 3 with Zero Downtime」,其中切換的原因之一是維護成本:

This choice has bitten us in the form of gem incompatibility, having to manually backport security patches, missing out on core framework performance and feature improvements, and being unable to easily contribute back to the open source rails project.

升級的過程工程浩大,用了四個人的全職時間去做到完美切換:

Over the last six months, we’ve had a team of 4 engineers working full time on upgrading to Rails 3.

接下來不知道是不是繼續切換到 Rails 4...

UPSERT

維基百科對 UPSERT 的說明:(取自「Merge (SQL)」條目)

A relational database management system uses SQL MERGE (also called upsert) statements to INSERT new records or UPDATE existing records depending on whether or not a condition matches.

MySQL 裡的兩種語法其實就是在實做這個需求:

  • REPLACE INTO ...
  • INSERT INTO ... ON DUPLICATE KEY UPDATE ...

而前者其實是後者的一個特例 (當 INSERT 發現有 dupe key 時把現有的 record 改成與 INSERT 時相同的條件)。

而計數器是後者常見的 case 之一:當 record 不存在的時候塞一筆進去,並且將 counter 設為 1;當 record 存在的時候對 counter 加一更新。像是這樣的 SQL query:

INSERT INTO my_table SET id = ?, num = 1 ON DUPLICATE KEY UPDATE num = num + 1;

由於這是常見的需求,使得這個語法是目前少數 MySQL 比 PostgreSQL 好用的地方。

在「A Case for Upserts」這篇就看到抱怨 PostgreSQL 不實做這個功能...

不過我覺得作者寫得有點誇張,INSERT INTO ... ON DUPLICATE KEY UPDATE ... 應該是可以模擬出來的功能:當 INSERT 失敗後再跑 UPDATE。而 REPLACE INTO ... 是特例,也就當然可以模擬出來。

AWS IAM 支援 SAML 2.0

剛剛看到 AWS 宣佈 AWS IAM 支援 SAML 2.0:「AWS Identity and Access Management Using SAML」。

SAML 是 Single Sign-On 協定的一種,2001 年就推出來了,不過其中用到的架構頗為複雜,由於是 XML 交換技術,再加上要在 XML 上面簽名 (XML Signature),其實我不是很喜歡這東西... @_@

當初會硬要接觸是因為 Google Apps 的 SSO 是使用 SAML,真是懷念啊...

由於是個公開標準,有不少企業 SSO 方案都有支援 SAML。而 AWS IAM 支援 SAML 就相當於讓控管的部份整合起來了... 我好像也應該來弄弄了?

Archives