Tag: json

用 Fly.io 跑 RSS-Bridge，再把現有的 twitter2facebook 與 twitter2plurk 改寫

Twitter 把我本來 read-only 的兩個應用程式停用掉了，加上這陣子的新聞，就改用其他方式來處理。

用的是先前在「用 RSS-Bridge 接服務」提到的 RSS-Bridge，可以將 Twitter 的資料轉成 JSON Feed。

其中 RSS-Bridge 是 PHP 寫的，剛好就拿先前在「在 Fly.io 上面跑 PHP」這邊提到的方法丟上 Fly.io，不需要自己架主機跑了。

然後把 twitter2facebook 與 twitter2plurk 這兩個專案裡面本來抓 Twitter API 的程式碼改成抓 JSON Feed。

先這樣子弄，之後再看看要不要搬...

SQL:2023 的新玩意

Hacker News 上看到「SQL: 2023 is finished: Here is what's new (eisentraut.org)」這篇題到了 SQL:2023 標準的新東西，對應的原文在「SQL:2023 is finished: Here is what's new」這邊。

「UNIQUE null treatment (F292)」讓你可以決定 NULL 到底要不要算 unique，剛好跟之前寫過的「PostgreSQL 15 將可以對透過 UNIQUE 限制 NULL 的唯一性了」要做的事情一樣。

「ORDER BY in grouped table (F868)」則是針對沒有出現在 SELECT 的欄位頁可以 ORDER BY，看了一下說明，主要是在 JOIN 的時候限制住了。很明顯的 workaround 是多加上這個欄位，但就代表會增加傳回的資料量。

「GREATEST and LEAST (T054)」這個因為 MIN() 與 MAX() 已經被 aggregate function 用掉了，所以只好另外取名。

「String padding functions (T055)」與「Multi-character TRIM functions (T056)」是熟悉的語法，各家都有對應的 function 可以做，但這次就放進標準化。

「Optional string types maximum length (T081)」是 VARCHAR 可以不用指定大小了，實務上應該是還好？

「Enhanced cycle mark values (T133)」這編提到的 recursive 真的是每次用每次忘，然後 cycle 這個功能就沒看懂了...

「ANY_VALUE (T626)」看起來可以隨機取出資料，搭配 GROUP BY '' 就不用拿 ORDER BY RAND() 這種髒髒的東西出來了？

「Non-decimal integer literals (T661)」與「Underscores in numeric literals (T662)」都是讓數字更好讀以及操作。

後面講了很多 JSON 功能，看起來是 SQL:2016 有先納入一些，但 SQL:2023 補的更完整了。

然後有 Graph 相關的標準也被定義進 SQL:2023，原文介紹的也不是很多，看起來是要跨足過來？

用 Perl 把 log 丟上 Slack

因為想在 Raspberry Pi 上面把一些 log 丟上 Slack，本來看到「Stream Any Log File to Slack Using curl」這篇，但發現裡面在把字串包進 JSON object 的方法太髒 (直接把 " 換成 ')，另外一方面是 Slack 已經在宣導不要用舊版的 Incoming Webhooks，所以決定用其他方式來處理。

選擇 Perl 主要是因為有一陣子沒有用 Perl 寫東西了，倒不是什麼特別的原因 (如果考慮到 Raspberry Pi 上資源有限的話，應該用 C 或是 Rust 或是 Go，但我的 Raspberry Pi 還沒忙到這種程度...)，所以決定用 Perl 來實做這個程式，把 log 檔案丟上 Slack：

這邊有些比較不太常見的選擇：

  • 不用 File::Tail 而反而是用 pipe 的方式取得 tail -F 的輸出，是因為 File::Tail 非常舊了 (2015)，實做上沒有用到 inotify 類的界面監控檔案的變化，反而是系統的 tail 有做。
  • 用 JSON::PP (pure perl 版本) 而不是 JSON 是因為 JSON::PP 在 Perl 5.14+ 後內建了，我沒有太在意效能，這也是上面放 use v5.14 的原因。
  • 這邊的 API 呼叫還是選擇了 WWW::Mechanize 是因為沒有內建的套件可以處理 HTTPS 連線 (可以參考 Perl core modules 這邊)，既然要另外安裝，就裝個支援度比較完整的 libwww-mechanize-perl 來用。

然後查了一下 // 的用法在 Perl 5.10+ 就支援了，好早...

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 都沒下...

jless：檢視 JSON 的工具

前幾天在「Show HN: Jless, a command-line JSON viewer (pauljuliusmartinez.github.io)」這邊看到用 Rust 寫的 jless 這個工具，官網有個動圖可以參考：

這樣方便不少，就不需要自己在對半天...

另外也剛好拿來練手，把 Rust 寫的套件包成 Ubuntu PPA：「PPA for jless」。

主要是 cargo vendor 這個指令可以把相依套件都抓下來放到 vendor/ 下面，然後設定 .cargo/config.toml 後就可以在本地端處理了，這對於 build farm 限制 internet 連線的情況會好用很多...

curl 的 command line 工具也要支援 JSON 格式了

Daniel Stenberg 在 curl 的 mailing list 上宣佈要支援 JSON 格式：「JSON support」，用法在「JSON awareness in the curl tool」在這邊可以看到，另外在 Hacker News 上的討論「The time might come when we add some JSON specific command line options (curl.se)」也可以翻翻。

討論裡面馬上有提到 HTTPie，這個套件基本上也算是標配了 (而且在各大 distribution 的 package 都有內建，直接裝就可以了)，可以看到主要是處理 POST 輸入時的 JSON 部份 (在 Content-Type: application/json 的情境下)，HTTP response 輸出的部份一般都還是用 jq 處理。

不過 curl 自己又定義了一套指定 JSON 內容的方式...

與 jq 互相配合的 jc

在 Simon Willison 的 blog 上看到的工具：「jc」，專案的網站：「JSON CLI output utility」。

可以把許多種輸出結果轉成 JSON 格式：

CLI tool and python library that converts the output of popular command-line tools and file-types to JSON or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.

所以就可以這樣用：

dig example.com | jc --dig

然後再丟給 jq：

dig example.com | jc --dig | jq -r '.[].answer[].data'

支援的格式不少，在「Parsers」這段可以看到。

在 Ubuntu 22.04 後可以直接透過系統的 apt 安裝：「Ubuntu – Details of package jc in jammy」，在那之前也可以透過 pip 裝起來用...

等 Ubuntu 22.04 出了以後應該會變成標配安裝...

Percona 連載到 PostgreSQL 存 JSON object 以及增加 Index 的方式了...

先前 Percona 的人在講 MySQL 存 JSON object 的方式，現在開始講在 PostgreSQL 裡存 JSON object，並且增加 index 的方式了：「Storing and Using JSON Within PostgreSQL Part One」。

這基本上就是不想用 MongoDB，但還是有需要極為彈性而選擇用 JSON object 的需求。

首先先先建立一個表格，這邊直接用 JSONB：

alice=# CREATE TABLE table1 (id SERIAL PRIMARY KEY, jb JSONB);

接著拿「A dataset of English plaintext jokes」這邊的 reddit_jokes.json 來玩，我先把 JSON 裡面的內容變成 JSON Lines 格式：

cat reddit_jokes.json | jq -c '.[]' > reddit_jokes.jsonl

然後 COPY 了十次，多一點資料，後面可以看效能：

alice=# COPY table1 (jb) FROM '/tmp/reddit_jokes.jsonl' CSV QUOTE e'\x01' DELIMITER e'\x02';
-- (repeat this command 10 times)

接著跑個 SELECT 看看速度，我跑了幾次大約都在 260ms 上下：

alice=# SELECT COUNT(*) FROM table1 WHERE (jb->>'score')::int = 10;
 count 
-------
 25510
(1 row)

Time: 264.023 ms

然後針對 score 生個數字的 index：

alice=# CREATE INDEX ON table1 (((jb->>'score')::int));
CREATE INDEX
Time: 1218.503 ms (00:01.219)

接著再跑 SELECT 下去，可以看到速度快超多：

alice=# SELECT COUNT(*) FROM table1 WHERE (jb->>'score')::int = 10;
 count 
-------
 25510
(1 row)

Time: 12.735 ms

另外也可以加 column：

alice=# ALTER TABLE table1 ADD COLUMN score INT GENERATED ALWAYS AS ((jb->>'score')::int) STORED;

然後可以看到速度也不快：

alice=# SELECT COUNT(*) FROM table1 WHERE score = 10;
 count 
-------
 25510
(1 row)

Time: 222.163 ms

幫他補 index：

alice=# CREATE INDEX ON table1 (score);

速度有變快，但不知道為什麼沒有 JSONB 的版本快：

alice=# SELECT COUNT(*) FROM table1 WHERE score = 10;
 count 
-------
 25510
(1 row)

Time: 81.346 ms

算是還蠻好用的，不過得學 JSON query 語法... (應該是還好)

AWS 推出 CloudWatch Metric Streams

AWS 推出了 CloudWatch Metric Streams，把 CloudWatch Metric 的資料往 Kinesis Data Firehose 裡面丟：「CloudWatch Metric Streams – Send AWS Metrics to Partners and to Your Apps in Real Time」。

其中一個賣點是即時性比用 API 去拉好很多：

In order to make it easier for AWS Partners and others to gain access to CloudWatch metrics faster and at scale, we are launching CloudWatch Metric Streams. Instead of polling (which can result in 5 to 10 minutes of latency), metrics are delivered to a Kinesis Data Firehose stream.

格式上可以是 JSON 或是 Open Telemetry：

When you set up a stream you choose between the binary Open Telemetry 0.7 format, and the human-readable JSON format.

另外一個賣點是價位，每千次 $0.003：

Pricing – You pay $0.003 for every 1000 metric updates, and for any charges associated with the Kinesis Data Firehose. To learn more, check out the pricing page.

另外算一下 Kinesis Data Firehose 的價錢，是以資料量的大小計費，不過最小計價單位是 5KB (一筆應該是不會到)，單價是 $0.029/GB (us-east-1) 或是 $0.037/GB (ap-southeast-1)，算了一下跟 CloudWatch Metrics Streams 比起來只是零頭...

之前如果要自己拉出來的話是透過 API call 抓，每 1000 次是 USD$0.01，這個方法相較起來便宜不少，不過數量多的時候還是一筆費用 (而且有不少 metrics 是一分鐘更新一次)。

如果只是要備份起來或是跑分析的話，也許先前用 API 拉的作法可能還是比較好？一個小時拉一次對於備份與分析應該都很夠了，而 alarm 的機制還是掛在 CloudWatch 上。

這次產品的定位看起來是要把 ecosystem 做起來：

We designed this feature with the goal of making it easier & more efficient for AWS Partners including Datadog, Dynatrace, New Relic, Splunk, and Sumo Logic to get access to metrics so that the partners can build even better tools.

檔案壓縮順序造成壓縮率的差異

Hacker News Daily 上看到「Why are tar.xz files 15x smaller when using Python's tar library compared to macOS tar?」這篇，作者問了為什麼他用 Python 的 tarfile 壓出來比起用 tar 壓出來小了 15 倍，檔案都是 JSON 檔壓成 XZ 格式：

I'm compressing ~1.3 GB folders each filled with 1440 JSON files and find that there's a 15-fold difference between using the tar command on macOS or Raspbian 10 (Buster) and using Python's built-in tarfile library.

看到 1440 個檔案應該會有直覺是一分鐘一個檔案，跑一天的量...

隔天他把原因找出來了，在裝了 GNU Tar 並且加上 --sort='name' 參數後，壓出來的大小就跟 Python 的 tarfile 差不多了：

Ok, I think I found the issue: BSD tar and GNU tar without any sort options put the files in the archive in an undefined order.

After installing GNU tar on my Mac with:

brew install gnu-tar

And then tarring the same folder, but with the --sort option:

gtar --sort='name' -cJf zsh-archive-sorted.tar.xz /Users/user/Desktop/temp/tar/2021-03-11

I get a .tar.xz archive of 1.5 MB, equal to the archive created by the Python library.

底層的原因是檔名與檔案內容有正相關的相似度 (因為裡面都是 sensor 資料)，依照檔名排序壓縮就等於把類似的 JSON 檔案放在一起壓，使得 xz 可以利用這點急遽拉高壓縮率：

My JSON files contain measurements from hundreds of sensors. Every minute I read out all sensors, but only a few of these sensors have a different value from minute to minute.

By sorting the files by name (which has the creation unixtime at the beginning of it), two subsequent files have very little different characters between them. Apparently this is very favourable for the compression efficiency.

遇到類似的情境可以當作 tuning 的一種，測試看看會不會變小很多...