MangoDB 改名為 FerretDB (雪貂)

先前提到的 MongoDB 相容方案 MangoDB,透過PostgreSQL 當底層而且維持 open source license 的方案 (參考先前寫的「MangoDB:拿 PostgreSQL 當作後端的 MongoDB 相容層」),正式改名為 FerretDB:「MangoDB has a new name, and the momentum is stronger than ever. Meet FerretDB!」。

依照官方的說明,應該就是收到 C&D notice 了:

Moreover, a representative of MongoDB Inc. asked us to stop using the MangoDB name on our website, GitHub, or anywhere else, due to similarity or potential confusion.

Hacker News 上沒什麼討論,不過這邊還是列一下:「MangoDB has a new name (ferretdb.io)」,裡面有提到另外的「Ferret Database」這個網站,看起來是真的雪貂網站 XDDD

MangoDB:拿 PostgreSQL 當作後端的 MongoDB 相容層

Hacker News Daily 上看到「A truly Open Source MongoDB alternative」這個東西,在「MangoDB: An open-source MongoDB alternative (mangodb.io)」的討論也可以翻一翻。

MongoDB 最主要的問題就是 4.0 以及以後的版本變成 SSPL 後就不是 open source license 了。

而 MangoDB 是個 Proxy service,前端提供 MongoDB 的協定,後端則是 PostgreSQL

GitHub 上的「MangoDB-io/MangoDB」這邊可以看到 MangoDB 主要是用 Golang 寫的,軟體授權則是 Apache License 2.0

The core of our solution is a stateless proxy, which converts MongoDB protocol queries to SQL, and uses PostgreSQL as a database engine. This will be compatible with MongoDB drivers, and should work as a drop-in replacement to MongoDB in many cases.

這對於只有提供 MongoDB 當儲存層的軟體來說會是個替代方案。不過如果是自己開發的話,這其實也證明了可以直接用 PostgreSQL,基本上 MongoDB 的功能都可以在 PostgreSQL 上找到方案。

話說這個讓我想到 2019 年 AWS 推出 Amazon DocumentDB 的時候,大家都一直在猜 Amazon DocumentDB 是不是拿 PostgreSQL 前面加上一些東西 (參考「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」),後來也有人發現再更早之前就有人 PoC 過了:「A proof of concept MongoDB clone built on Postgres (github.com/jerrysievert)」,現在一般的公認應該就是,只是 AWS 沒有 open source 出來。

目前 MangoDB 還在早期的階段,但看起來這波應該會有一些能量進去幫忙...

Amazon DocumentDB 推出相容 MongoDB 4.0 的版本

在「Amazon DocumentDB (with MongoDB compatibility) adds support for MongoDB 4.0 and transactions」這邊看到 AWSAmazon DocumentDB 上推出相容 MongoDB 4.0 的版本。

把年初在 Ptt 上寫的「Re: [請益] 選擇mongoDB或是relational database ??」這篇拿出來講一下,MongoDB 4.0 最大的改進就是 multi-document transactions 了。

不過 AWS 先前推出 DocumentDB (MongoDB) 時看到的限制,大家都猜測是用 PostgreSQL 當底層 (「AWS 推出 MongoDB 服務:Amazon DocumentDB」與「大家在猜 Amazon DocumentDB 的底層是不是 PostgreSQL...」),雖然目前還是不太清楚,但如果這個猜測屬實的話,要推出各種 transaction 的支援完全不是問題 XDDD

Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇,裡面給了五個建議,其中第五點頗有趣:

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊,你不要扯其他 database 啊,你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊,反過來才是用 InnoDB 的常態吧,而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD

DynamoDB 也有固定的 IP address 區段了

AWS 宣佈 DynamoDB 也有固定的 IP address 區段了:「AWS specifies the IP address ranges for Amazon DynamoDB endpoints」,對於使用 IP firewall 的人可以多一些控制權。

資料可以在 https://ip-ranges.amazonaws.com/ip-ranges.json 這邊抓到,裡面 serviceDYNAMODB 的就是了。

因為沒看到 IPv6 的位置,才發現 DynamoDB 目前沒有提供 IPv6 Endpoint...

貴不少的 DynamoDB On-Demand...

DynamoDB 用起來比較困難的部份就是規劃 R/W capacity,所以 AWS 就推出了 DynamoDB On-Demand,直接計算用多少而不用規劃 R/W capacity:「Amazon DynamoDB On-Demand – No Capacity Planning and Pay-Per-Request Pricing」。

先講一下歷史,在 2014 的時候 Jeff Barr 就有在「Auto Scale DynamoDB With Dynamic DynamoDB」這邊提到開一台 t1.micro 在上面跑程式實做 DynamoDB 的 auto scaling。

另外在 2017 年的時候 AWS 自己推出了同樣的功能,就不需要開機器了,交給 AWS 的服務處理就可以了:「New – Auto Scaling for Amazon DynamoDB」。

所以就一般性的需求來說,其實目前的方案夠用:常態性的需求提昇,以及有預期性的活動時可以手動事前提昇。

目前想到唯一會炸掉的情境應該是突然被熱門媒體報導,而導致大量的 guest session 衝進來,而且架構上又沒有針對 guest session 用 cache 擋住 (Amazon DynamoDB Accelerator 也是個選項),導致壓力就全部到後端的 DynamoDB,而 auto scaling 機制需要時間看到量才會調整,在這段時間就有可能短時間倒站。

回來看這次的 On-Demand 提出來的價錢。以 us-east-1 的價錢來看:

Write request units	$1.25 per million write request units
Read request units	$0.25 per million read request units

而本來要自己規劃 R/W capacity 的價錢是 (這邊是 hourly):

Write capacity unit (WCU)	$0.00065 per WCU
Read capacity unit (RCU)	$0.00013 per RCU

由於不管是 On-Demand 還是本來的規劃,Read 價錢都是 Write 的 1/5,所以只要看 Write 一樣可以知道差距。

接下來把 On-Demand 的價錢換算成 3600 個 request units 就可以比較單價,是 $0.0045 (Write),大約是本來版本 6.92 倍的費用...

而且對於已經有規模的應用,這邊還沒算 Reserved Capacity 會有折扣的部份?

這個定價策略讓我想到 AWS Fargate 的情況... 如果你可以接受這個價錢,你可以平常就開五倍的 R/W capacity 在上面啊 XDDD

Cloudflare 的 Workers KV

Cloudflare 推出了 Workers KV 服務:「Building With Workers KV, a Fast Distributed Key-Value Store」。

是個 key-value 結構服務 (全球性,eventually consistent,約 10 秒的同步時間),key 的限制是 2KB,value 是 64KB,一個 namespace 最多 10 億筆資料。

讀取可以到 100k+ read/s,但寫入是 1 write/s/key,可以看出來主要是為了讀取資料而設計的。

現有的 worker ($5/month) 會送一些量,包括 1GB 的空間與一千萬次的讀取:

Your $5 monthly Workers compute minimum includes 1 GB of KV storage and up to 10 million KV reads. If you use less than the 10 million included Worker requests now, you can use KV without paying a single cent more.

超過的部份另外再收:

Beyond the minimums, Workers KV is billed at $0.50 per GB-month of additional storage and $0.50 per million additional KV reads.

這樣好像整個 blog 的基本功能都可以直接在上面跑了... 而搜尋靠外部服務,圖片與影音也可以靠外部空間協助?

Amazon DynamoDB 提供 Docker Image 讓開發者可以在本地端測試

AWS 推出了 Amazon DynamoDB 的相容 Docker Image,讓開發者可以在本地端測試 DynamoDB 的 API:「Use Amazon DynamoDB Local More Easily with the New Docker Image」,在 amazon/dynamodb-local 這邊可以拉到,裡面其實是包 Java:

DynamoDB local is now available to download as a self-contained Docker image or a .jar file that can run on Microsoft Windows, Linux, macOS, and other platforms that support Java.

這樣在 Continuous Integration (CI) 的過程裡面也可以拉起 service 測試...

Amazon DynamoDB 的 Global Tables 推到東京了...

DynamoDBGlobal Tables 可以把 DynamoDB 複製到其他區域,讓各地存取自己的資料:

剛剛看到 AWS 宣佈這個功能展到 ap-northeast-1 (東京) 了:「Amazon DynamoDB Global Tables Now Available in Three Additional Asia Pacific Regions」。

Global tables is now available in the Asia Pacific (Tokyo), Asia Pacific (Seoul), and Asia Pacific (Sydney) Regions.

這樣測起來就更接近實際的情況了...