SQLite 官方自己搞的 Cloud Backed SQLite

SQLite 自己搞了一套使用雲端空間為儲存空間的技術:「Cloud Backed SQLite」,對應的 Hacker News 討論可以看「Cloud Backed SQLite (sqlite.org)」這邊。

他說目前支援 Azure Blob StorageGoogle Cloud Storage,這點比較有趣,沒有提到 Amazon S3

The system currently supports Azure Blob Storage and Google Cloud Storage. It also features an API that may be used to implement support to other cloud storage systems.

跟之前的 sql.js 專案不太一樣,sql.js 的作法是用 HTTP range 存取現有的 SQLite 資料庫檔案,而這次的這個專案則是改變底層架構,去配合雲端環境的特點。

雲端的 storage 因為每個 access 都會有很高的 latency (相比於本地的空間),所以要避免太多 random access,儘量以 sequential access 為主,這個特性像是以前在處理傳統磁頭硬碟時的技巧。

另外一個特點是雲端空間有多檔案的概念,所以也可以利用這個方式設計資料結構。

還蠻有趣的計畫,而且是官方搞的...

AWS Aurora Xanadu?

在「Why PostgreSQL High Availability Matters and How to Achieve It (yugabyte.com)」裡面看到 AWS 也在研發類似 GCP 提供的 Spanner 的服務,計畫名稱叫做 Aurora Xanadu:「36328981」。

franckpachot

Google has Spanner. AWS is working on something similar (project Aurora Xanadu). And both have YugabyteDB in their marketplace. Those are Distributed SQL (Global ACID), not Citus. For DataWarehouse which doesn't need ACID, there are other services.

也先把這個連結備份起來,看看後面是不是直接拿這個名字來用?

GCP 的 Disks 與 AWS 的 EBS 的比較...

下午在升級 GCP 上面的跳板機的時候,發現機器用的是 Standard Persistent Disk (Standard PD),這是個 HDD 架構,跑起來超慢,研究了一下發現 AWS 與 GCP 兩邊的差異其實有點大,整理一下...

價錢的部分,AWS 的部分拿東京區 (ap-northeast-1) 的價錢來看,GCP 則是拿台灣區 (asia-east1) 來看。

先看 SSD 的部分:

AWS 最常用的 gp3 是 $0.096/GB,無論空間大小,效能上都提供 3000 IOPS 與 125MB/sec throughput,另外可以加價購買 IOPS 與 throughput。不過也因為這個性質,拿來當開機碟很好用。

早期的 gp2 則是 $0.12/GB,效能上提供 3 IOPS/GB,但最低會給 100 IOPS,所以當開機碟也還可以,不會到太慢。

GCP 如果是 Balanced Persistent Disk (Balanced PD) 是 $0.1/GB,效能上會提供 6 Read IOPS/GB + 6 Write IOPS/GB + 0.28MB/sec/GB throughput;以 10GB 的 disk 來說會是 60 Read IOPS + 60 Write IOPS + 2.8MB/sec throughput。

如果是 SSD Persistent Disk (SSD PD) 是 $0.17/GB,效能上是 30 Read IOPS/GB + 30 Write IOPS/GB + 0.48MB/sec/GB throughput;以 10GB 的 disk 來說會是 300 Read IOPS + 300 Write IOPS + 28MB/sec throughput。

再來是 HDD 的部分:

AWS 這邊代號是 standard,價錢是 $0.08/GB,另外 IOPS 每 1M 個 IOPS 也要收 $0.08,如果是拿來開機的話還好,但如果是有應用在上面操 IOPS 的話就不太便宜了。

GCP 這邊是 Standard Persistent Disk (Standard PD),價錢是 $0.04/GB,效能上提供 0.75/GB Read IOPS + 1.5/GB Write IOPS + 0.12MB/sec/GB throughput;以 10GB 的 disk 來說會是 7.5 Read IOPS + 15 Write IOPS + 1.2MB/sec throughput。

所以如果是不太在意效能的情況下要找 C/P 值 (但也不到完全不在意?),在 AWS 上用 standard 就不太划算,畢竟多一些些費用就可以用 gp3,對效能提升巨大;但在 GCP 上就會想用 Standard PD,從單價可以看到差了蠻多...

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇,大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情,基本上討論的內容大概都想的到...

AWS 這邊的話,最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態),但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種),讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著,官方現在應該是主力在推 DynamoDB

兩種完全不同的作法...

AWS DataSync 支援 GCP 與 Azure 上的 Storage 上的資料了

AWS DataSync 宣佈支援 GCP 與 Azure 上的 Storage 了:「New for AWS DataSync – Move Data Between AWS and Other Public Locations」,比較特別的是,文章的 URL 有提到這兩家的產品,但在標題上反而就沒提到...

這測的重點就是支援 Google CloudMicrosoft Azure 的 object storage 產品:

Today, we added to DataSync the capability to migrate data between AWS Storage services and either Google Cloud Storage or Microsoft Azure Files.

之前大家都是自己開機器手動搬,現在可以直接付錢 (依照 GB 計費) 用服務搬了,不過要注意網路頻寬的流出部份還是有費用...

GCP 推出 AlloyDB,一套相容 PostgreSQL 協定的資料庫服務

也是在清 RSS reader 的時候翻到的,看起來是在今年的 Google I/O 上發表的服務,AlloyDB:「AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage」,值得提的是這篇有中文版可以看:「適用於 PostgreSQL 的 AlloyDB 隆重登場:從此擺脫成本高昂的老舊資料庫」。

另外還有一篇比較偏 PR 的文章也可以看看:「Introducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databases」,這篇就比較針對的提到了與 AWS 的服務相比,但畢竟是 PR 稿沒有明講 (出事會比較好打模糊戰),但我猜測是與 Aurora 對比:

AlloyDB was also two times faster for transactional workloads than Amazon’s comparable service.

宣稱在 OLTP 上快了兩倍 (原來的三倍?),但應該都是以 PostgreSQL 下去改,猜測可能是底層的 storage 與 replication 比較好?

AlloyDB 設計上是考慮了 HTAP (Hybrid transactional/analytical processing) 的使用,所以同時可以提供 OLAP 與 OLTP 的應用:

[...] This makes AlloyDB a great fit for business intelligence, reporting, and hybrid transactional and analytical workloads (HTAP).

直接在一個資料庫內處理 OLAP 與 OLTP 這點的確會讓 AlloyDB 比 AWS 目前能提供的方案方便不少 (然後想一下 BigQuery 團隊...)。

目前在 AWS 對應的方案應該是透過 Redshift 來解決,另外一個方案是透過 Athena 來跑。

最後來看價錢,如果效能變成兩倍但價錢也是兩倍的話,就代表在價格上沒優勢。

先看機器的部份,如果是拿 Aurora 這邊 Intel-based 的 db.r5.24xlarge (96 vCPU + 768 GB RAM) 來算的話是 US$13.92/hr,而如果換算到 AlloyDB 的話是 US$14.94528/hr,相除是 0.9314,大約 7% 的差距,可以算是同一個級距。

如果 Aurora 這邊是拿 ARM-based 的 db.r6g.16xlarge (64 vCPU + 512 GB RAM) 來算的話是 US$8.306/hr,換算到 AlloyDB 的話是 US$9.96352/hr,相除是 0.8336,這邊就差超過 16% 了...

(這邊剛好回顧一下 "Amazon’s comparable service" 這段,不確定他是跟 Intel-based 比還是跟 ARM-based 比,畢竟 ARM 除了比較便宜外,還有效能的提昇)

但最大的差異應該是在 storage 相關的部份。其中 Aurora 這邊的空間與 I/O 是分開收費的,以 us-east-1 來說,storage 是 US$0.10/GB/mo,而 I/O 是 US$0.20/million-requests,在 AlloyDB 這邊來說,Regional cluster storage 是 US$0.0004109/GB/hr (us-east4),變成是 US$0.295848/GB/mo,兩邊相比後可以算出來對等的計價會是 AWS 的 storage 加上 AWS 給你 1.47M 的 I/O (per GB)。

這樣算起來把資料丟 S3 跑 Athena 可能不會比較貴... (當然效能是另外的主題了)

光就檯面上的資料來看,看起來是個不錯的東西,等後續有人跳進去用看看感想...

Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 GoogleAWS 都釋出往 OpenTelemetry 靠攏的消息:「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係,找了一下果然發現之前有些計畫在跑:「AWS X-Ray SDK w/ OpenTelemetry API」,不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線,本來在推的 OpenCensusOpenTracing 從網站上可以看到決定會再支援兩年,但重心會改放到 OpenTelemetry 上:

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息,先前有一些稿子是會往 OpenTelemetry 支援,但這一波沒看到新聞稿...

架設 MTProxy 加快 Telegram 的速度

在台灣如果是透過 HiNetTelegram 是沒什麼問題 (不需要翻牆),不過連結的 preview 以及圖片影片讀取的速度實在很慢,試著在 GCP (彰濱機房) 跟 Vultr (東京機房) 上架 Proxy 測試看看,發現速度都改善很多...

這邊用的是官方提供的 MTProxy,我把安裝的懶人包放在自己的 wiki 上了:「MTProxy」,在 AWS 或是 GCP 上安裝時,因為網卡拿到的是 Private IP 而非對外的 Public IP,需要指定 --nat-info 告訴 MTProxy 要針對協定裡面的 IP address 另外處理。

跑一陣子再來看看有什麼可以調整的...

Google Cloud Platform 在台灣的機房可以開 Standard Network 的機器了

Google Cloud Platform 一開始是提供 Premium Network,會透過 Google 自家的網路骨幹連到最近的點,然後再透過當地的機房交換出去,這樣可以確保頻寬的穩定性,但成本當然也就比較高...

後來提供了 Standard Network 則是從機房出去後就直接交換,成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇),但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請?),所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了,不確定是已經全開了還是分批開。

測了一下發現網路相當... 爛?是還在調整嗎...

像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題):

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms

然後 168.95.1.1139.175.1.1 也都很差 (61.31.1.1 不給 ping):

PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data.
64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms
64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms
64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms

--- 168.95.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data.
64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms
64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms
64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms

--- 139.175.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms

不過學術網路倒是還不錯:

PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data.
64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms
64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms
64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms

--- 140.112.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data.
64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms
64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms
64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms

--- 140.113.250.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data.
64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms
64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms
64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms

--- 140.117.11.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms

有需要的人可以測試看看了...

GCE 的 IP 要收費了...

收到信件通知,本來在 GCE 上使用的 Public IP address 是免費的,2020 年開始變成要收 USD$0.004/hr (Standard,約 USD$2.88/month) 或是 USD$0.002/hr (Preemptible,約 USD$1.44/month):

First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.

從 2020 年一月開始生效,但是前三個月會用 100% discount 的方式呈現在帳單上 (所以還是免費),這樣你會知道你的 IP address 費用會吃多少錢:

We will fully discount any external IP usage for the first 3 months to help you quantify the impact of these pricing changes. Please take note of the following dates:

January 1, 2020: Although your invoice will show your calculated external IP-related charges, these will be fully discounted and you will not need to pay these.
April 1, 2020: You will need to pay for any incurred external IP-related charges shown on your invoice.

其實整體成本應該是還好,但看到漲價總是不開心... XD