OxideDB:另外一套用 PostgreSQL 為底的 MongoDB 相容層

看到 OxideDB 這個專案:

OxideDB is a translation layer that works as a MongoDB database server while using PostgreSQL's JSON capabilities as the underlying data store.

跟之前提到的 MangoDB 有些淵源 (參考「MangoDB:拿 PostgreSQL 當作後端的 MongoDB 相容層」),順便提一下 MangoDB 然後後來被要求改名為 FerretDB:「MangoDB 改名為 FerretDB (雪貂)」。

主要的差異在於 OxideDB 只以 PostgreSQL 為底層,另外是用 Rust 寫的:

The project was heavily inspired by FerretDB and is on its early days. The main difference is that there is no intention to support any database other than PostgreSQL (FerretDB is also supporting Tigris) and it's written in Rust, as opposed to Go.

看起來大家都拿 PostgreSQL 在搞事,但這個專案裡面好像沒搜到 GIN 這個關鍵字,不知道是不是連 index 都沒下...

在 Hacker News 上看到幾個 Key-Value Store 軟體

Hacker News 上看到「Redis vs. KeyDB vs. Dragonfly vs. Skytable」這篇,裡面介紹了四套 key-value store 軟體:

  • Redis:這個應該不太需要介紹...
  • KeyDBSnapchat 搞出來的 Redis clone,主要的賣點是 multi-threading。
  • Dragonfly:宣稱地球上最快,但作者跑不出來,下面的討論有人提到 Dragonfly 在更多的 CPU 資源效能就會更好。
  • Skytable:作者測出來最快的。

裡面看起來都蠻有趣的,可以追起來看看發展的情況,但如果真的要的用的話,應該還是先以 Redis 為主,穩定度以及功能還是重點...

PHP (以及 Laravel) 下使用 DynamoDB 的 ORM 工具

Twitter 上看到「Laravel DynamoDB Eloquent Models and Query Builder」這篇文章,裡面講「Laravel DynamoDB」這個套件,可以在 PHP (以及 Laravel) 下存取 DynamoDB

雖然套件提到了 Laravel,但文件裡面也有提到支援非 Laravel 的 PHP 環境下使用,單獨拿出來用也沒問題,比較重要的反倒是 DynamoDB 對各種 key 的概念。

如果是從零開始設計,但又不想要自己管資料庫,我會偏好先用 RDS 設計,無論是 MySQL 或是 PostgreSQL 的版本都行,畢竟 RDBMS 上面能做的事情比較多,對開發者比較友善,除非是第一天上線你就預期量會大到連 db.m5.24xlarge 都擋不住之類的情況...

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