LinkedIn 決定要在平台上面弄出遊戲...

也是清連結的消息,三月中的消息,LinkedIn 想要在平台上面弄出遊戲:「LinkedIn plans to add gaming to its platform」。

會是 puzzle 類型的遊戲,而且看起來有東西了:

It will be doing so by tapping into the same wave of puzzle-mania that helped simple games like Wordle find viral success and millions of players. Three early efforts are games called “Queens”, “Inference” and “Crossclimb.”

然後當時跟 LinkedIn 發言人確認也證實了這點:

“We’re playing with adding puzzle-based games within the LinkedIn experience to unlock a bit of fun, deepen relationships, and hopefully spark the opportunity for conversations,” the spokesperson said in a message to TechCrunch. “Stay tuned for more!”

試著走向更一般性的 social network?目前 LinkedIn 上面應該都是雞湯文與 clickbait,這個變化好像有點大...

估算 YouTube 影片總量的方式

Hacker News Daily 上看到「How big is YouTube? (」這篇,原文在「How Big is YouTube?」。


作者用的方法是觀察 YouTube 的 vid:

Here’s how this works: YouTube URLs look like this: watch?v=vXPJVwwEmiM

可以分析出來 vid 包括了 64-bit 的資訊,這個資料型態對工程師來說,看起來就很像是 uniformly distributed:

That bit after “watch?v=” is an 11 digit string. The first ten digits can be a-z,A-Z,0-9 and _-. The last digit is special, and can only be one of 16 values. Turns out there are 2^64 possible YouTube addresses, an enormous number: 18.4 quintillion. There are lots of YouTube videos, but not that many. Let’s guess for a moment that there are 1 billion YouTube videos – if you picked URLs at random, you’d only get a valid address roughly once every 18.4 billion tries.

然後就是隨機去產生 vid 去掃,這個方法跟 drunk dialing 的行為很像,算是 random sampling 的方式:

We refer to this method as “drunk dialing”, as it’s basically as sophisticated as taking swigs from a bottle of bourbon and mashing digits on a telephone, hoping to find a human being to speak to. Jason found a couple of cheats that makes the method roughly 32,000 times as efficient, meaning our “phone call” connects lots more often. Kevin Zheng wrote a whole bunch of scripts to do the dialing, and over the course of several months, we collected more than 10,000 truly random YouTube videos.

另外在 2011 年就有提出來利用 autocomplete 機制去算:

By comparing our results to other ways of generating lists of YouTube videos, we can declare them “plausibly random” if they generate similar results. Fortunately, one method does – it was discovered by Jia Zhou et. al. in 2011, and it’s far more efficient than our naïve method. (You generate a five character string where one character is a dash – YouTube will autocomplete those URLs and spit out a matching video if one exists.) Kevin now polls YouTube using the “dash method” and uses the results to maintain our dashboard at Tubestats.

目前他們的預估大約是 13B 左右的影片,換算大約是用掉 33.63 bits 了 (233.6):

In our case, our drunk dials tried roughly 32k numbers at the same time, and we got a “hit” every 50,000 times or so. Our current estimate for the size of YouTube is 13.325 billion videos – we are now updating this number every few weeks at

而這邊提到的 32768 * 50k 會中一次的部分,這邊的大約是 30.61 bits,這樣加起來是差不多 64 bits 沒錯。

不過要注意的是,他們沒有給出 interval,所以 13B 的上下可能是一倍左右的差距 (6.5B~26B 之類的),這邊的數字當作概念比較好...

GCP 的 IPv4 也要漲價了

前幾天收到 GCP 的信件,提到 2024/02/01 開始 IPv4 address 要漲價了,在「External IP address pricing」這邊也可以翻到這些資訊。

External IP 的部分,漲 25%:

Static and ephemeral IP addresses in use on standard VM instances will go from $.004 to $.005.

Static and ephemeral IP addresses in use on preemptible VM instances will go from $.002 to $.0025.

用一個月 720 小時算,一般 VM 的費用等於是從 $2.88/mo 漲到 $3.6/mo 左右的費用。

Cloud NAT 吃的 IPv4 address 的部分,從本來沒有收變成要收費:

Static and ephemeral IP addresses mapped to Cloud NAT Gateway will go from No Charge to $0.005.

GCP 提供每個區域的 Standard Tier Networking 每個月 200GB 的免費頻寬

GCP 提供每個區域 Standard Tier Networking 每個月有 200GB 的免費頻寬:「Announcing 200 GB free Standard Tier internet data transfer per month」。


另外雖然是每個區域都有 200GB/mo 的 free bandwidth,但通常也只會用一個或兩個區域,以台灣的 asia-east1 來說,如果有量在上面跑的話,省下來的會是 $0.07/GB 這個部分,大概就是 $14/mo 左右?

AWS Aurora Xanadu?

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


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,從單價可以看到差了蠻多...

Twitter 新政策禁止推廣其他社交平台的連結

看到 Paul Graham 這個宣告:

裡面提到的新政策在「Promotion of alternative social platforms policy」這邊,直接禁止其他社交平台:

At both the Tweet level and the account level, we will remove any free promotion of prohibited 3rd-party social media platforms, such as linking out (i.e. using URLs) to any of the below platforms on Twitter, or providing your handle without a URL:

  • Prohibited platforms:
    • Facebook, Instagram, Mastodon, Truth Social, Tribel, Post and Nostr
    • 3rd-party social media link aggregators such as,

Hacker News 的討論上面,Paul Graham 有回應 (帳號是 pg),他又提出了一些猜測與見解,包含了他覺得這個新政策會被收回:「Paul Graham is leaving Twitter for now (」。

I'm not leaving Twitter. It seems more likely than not that Elon will reverse the ban on links to other social media sites. I just don't want to hang out there in the meantime. Plus given the way things are going, it seemed like a good time to learn about alternatives.

I still think Elon is a smart guy. His work on cars and rockets speaks for itself. Nor do I think he's the villain a lot of people try to make him out to be. He's eccentric, definitely, but that should be news to no one. Plus I don't think he realizes that the techniques that work for cars and rockets don't work in social media. Those two facts are sufficient to explain most of his behavior.

He could still salvage the situation. He's the sort of person it would be a big mistake to write off. And I hope he does. I would be delighted to go back to using Twitter regularly.

不過的確如他說的,這是個好機會嘗試其他的 social network...

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 可能不會比較貴... (當然效能是另外的主題了)



Hacker News Daily 上看到「Show HN: API to query catalogs of 20 streaming services across 60 countries (」這個,但這個服務反而不是重點,有許多人發現裡面錯誤率頗高,而且也沒有台灣的資料,反倒是裡面有人提到 JustWatch 這個服務看起來比較好用...

像是「Friends」(這邊用的是中國的翻譯片名) 可以看到在台灣是在 Netflix 上,美國的話則是在 HBO Max (串流) 與 Apple TV (購買) 上可以看到。不過查 MythBusters 在兩個平台上都沒看到資料...

但整體上來說 JustWatch 搜出來的品質還是好不少...

法院認為 Apple 必須在 12 月 9 日前開放行動平台上的第三方支付

大標題是「Judge orders Apple to allow external payment options for App Store by December 9th, denying stay」,小標題是「And Apple announces it will appeal」。

本來 Apple 想要繼續拖延,但法院直接打槍,然後 Apple 決定要再上訴到第九巡迴庭,基本上我們就是在旁邊坐著等看戲...

另外前陣子 Google 宣佈在南韓會開放其他付款機制 (參考「Google 在南韓開放 app 裡面使用其他付款機制了」),就沒看到 Apple 這邊的動作,找了一下新聞只看到 Apple 在南韓的頭決定不幹了:「Apple's top exec in South Korea departs amid dispute over App Store」,也許之後再找看看...