Multithreading 版本 pt-online-schema-change

看起來是個嘗試,Percona 的人試著修改 pt-online-schema-change,讓他可以在 INSERT 時 multi-threading,然後看效果:「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。

可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字,下圖是看相對比率):

如果沒有意外的話應該會有更多的測試,而這些測試沒問題的話,之後的官方版本裡面應該就會有這個功能。

Amazon EC2 的 M6g 系列正式推出了

先前提到 AWS 要在 EC2 上推出新的 ARM 架構主機 (參考「Amazon EC2 推出了新一代的 ARM 系統」這篇),最近正式推出了:「New – EC2 M6g Instances, powered by AWS Graviton2」。

當時的定價還沒出來,現在正式開賣後可以拉出來看了。

us-east-1 上 2 vCPU + 8GB RAM 這個級距的價錢出來,m5.large 是 USD$0.096/hour,m6g.large 是 USD$0.077/hour,低大約 20%,不過這是兩個不同的平台,只是抓一下感覺知道差距。

不過這個價差其實蠻有吸引力的,對於有支援 ARM 的應用程式,或是手上有 source code 的大型應用,可以測試看看效能有差多少,或是先等一下,這陣子應該就會有人初步測一些數字出來可以參考。

另外 AWS 有打算要出 C6gR6g 的計畫,算是在雲上面補齊 ARM 的戰線:

We are not going to stop at general purposes M6g instances, compute optimized C6g instances and memory optimized R6g instances are coming soon, stay tuned.

目前支援的區域不算多,不過幾個老區域都先上了:

Now it’s your turn to give it a try in one the following AWS Regions : US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), and Asia Pacific (Tokyo).

Internet Archive 的頻寬...

看到「Thank you for helping us increase our bandwidth」這邊在說明 Internet Archive 的流量資訊:

看起來平常就是滿載的情況,然後加上去的流量馬上就被吃掉了... 這些資料看起來是放在 Cacti 這邊,不過只有 error rate 有開放讓大家翻,流量的部份看起來要登入才能看。

CloudFront 在印度的第六個區域:加爾各答

查了一下資料才發現,印度應該是僅次於北美的單一國家 CloudFront 最多點的地區:「Amazon CloudFront announces its first Edge locations in Kolkata and Hamburg」。

以「Amazon CloudFront Key Features」這頁列出的資料可以看到印度有第六個區域了:

Edge locations: Bangalore, India (3); Chennai, India (2); Hong Kong, China (3); Hyderabad, India (4); Kolkata, India; Kuala Lumpur, Malaysia (2); Mumbai, India (3); Manila, Philippines; New Delhi, India (4); Osaka, Japan; Seoul, South Korea (4); Singapore (4); Taipei, Taiwan(3); Tokyo, Japan (16)

不過如果以節點總數來說的話,印度與日本都是 17 個 (德國是 16 個),而且光東京這區就 16 個,這又更感覺得出網路重鎮的味道...

Hacker News 上對實體機房的討論 (雲與地的討論)

看到 Hacker News 上的「Ask HN: Is your company sticking to on-premise servers? Why?」這邊在討論為什麼還是有公司使用傳統的實體機房。

用雲的價值在於彈性,因為雲上加機器的時間成本比傳統實體機房低很多:加的量小的時候,主要的成本就是簽核需要的時間 (即使是電子簽) 與 setup 的時間 (如果沒有自動化),量大的時候可能會需要另外採購。

另外很多雲端服務的廠商除了 IaaS 以外也提供了很多 SaaS 的服務,這點對於建制的成本又降低了不少。

相反的,如果你的需求已經很固定了 (變動不大),而且又已經有一定的規模了,用傳統實體機房自己搭建會便宜很多,即使包含人力維護成本也都還是低很多。

另外討論裡也有提到雲端的頻寬費用,這一直都是雲端的痛點:目前雲上面的頻寬都超貴,所以用規模大一點的雲端公司會透過架構上的設計,把大的流量利用 HTTP/HTTPS 的 CDN 省下來。像是使用 AWSNetflix 設計了 Open Connect,藉以降低頻寬成本。

不過說到頻寬,AWS 的 Amazon Lightsail 就是個有趣的東西了,一樣是在 AWS 的架構內,但帳務上面把整包費用包的跟外面的 VPS 一樣...

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞,Zoom 的新聞稿:「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」,Keybase 的新聞稿:「Keybase joins Zoom」,看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告,裡面多到讓人不知道怎麼吐槽的部份,我們就把唯一的粗體字拉出來討論好了:

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題,影音上面因為 transcoding 的問題,如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做:

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream,這種方式其他家都已經很熟悉了,缺點也很明顯,就是吃各種資源,包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream,有點像是 progressive image 的方式,第一個 stream1 的畫質最低,第二個 stream2 則是「補強」第一個 stream1,這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式,直接可以疊加加密後的 stream1 + stream2,不過 bitrate 應該不會降低,就算真的設計的出來應該也沒用...

如果是 a) 的方式,業界對於 key 的交換都已經解的還不錯了,但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式,很明顯該找的是 codec 的公司 (要做出可以疊加的 codec),而不是搞密碼學的公司。

回到原來的問題,現有的團隊有 2500 人,裡面的技術團隊沒辦法搞定 end-to-end encryption,ok 沒關係,那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧?所以我翻了一下他的 LinkedIn 看了一下他的經歷,對不起我錯了,我瞬間不知道怎麼寫下去了,我豆頁痛...

EC2 宣佈 Reserved Instances 降價

Amazon EC2 的 Reserved Instances 宣佈降價:「EC2 Price Reduction – For EC2 Instance Saving Plans and Standard Reserved Instances」。

文章裡先列出 M5/C5/R5 的:

可以看到 R5 在一年是完全沒動,然後有些也是 0%,不過大多數應該是都有降:

Below I’ve given a snapshot of some of the savings across the M5, C5, and R5 instance types, however there are also price reductions for the instance types C5n, C5d, M5a, M5n, M5ad, M5dn, R5a, R5n, R5d, R5ad, R5dn, T3, T3a, Z1d, and A1.

以這些資料看起來是降了一些,但實際想要翻 T3a 系列機器的歷史資料時發現不好找,用搜尋引擎可以在「Where can I find Amazon EC2 price history?」這邊看到「https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/index.csv」這個地方,看起來是「New – AWS Price List API」這邊的資訊,不過看起來沒有 RI 的資料,只有 AmazonEC2 的資料 (所以對應到的都是 $0.00)。

之後看看有沒有其他地方有留這些資訊好了...

HTML 轉 SVG

在「html-to-svg」這邊看到的,專案在 GitHub 上的「as-a-service/html-to-svg」這邊。

整個服務的程式碼其實很短 (大約 50 行?),因為主要的業務是透過 Chrome (headless) 生出 PDF 檔,再用 Inkspace 把 PDF 轉成 SVG:「htmltosvg.js」。

主要是 Inkspace 可以做 PDF 轉 SVG 這件事情算是新知...

AWS Elemental Link:直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link,可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上:「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎,大約 524 立方公分):

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI,規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限),然後設備除了透過一般電力供電以外,也可以用 PoE 供電,可以少接一條電源線:

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995,但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品,好像沒看到類似可以直接送到網路服務的產品...