storage

Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站

在「Chrome exempts Google sites from user site data settings」這邊看到的新聞，引用的網頁是「Chrome exempts Google sites from user site data settings」，然後這篇也有上到 Hacker News Daily 上，所以 Hacker News 上的討論也蠻熱鬧的：「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。

作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試，發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」，只有 cookie 會清掉，但 database storage、local storage 與 service workers 都不會被清掉：

然後 Brave 那邊前陣子時做完 Sync v2 了，又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分：「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。

PostgreSQL 13 的 B-Tree Deduplication

Hacker News 上看到「Lessons Learned from Running Postgres 13: Better Performance, Monitoring & More」這篇文章，其中有提到 PostgreSQL 13 因為 B-Tree 支援 deduplication，所以有機會縮小不少空間。

搜了一下源頭是「Add deduplication to nbtree.」這個 git commit，而 PostgreSQL 官方的說明則是在「63.4.2. Deduplication」這邊可以看到。

另外值得一提的是，這個功能在 CREATE INDEX 這頁可以看到在 PostgreSQL 13 預設會打開使用。

依照說明，看起來本來的機制是當 B-Tree index 內的 key 相同時，像是 key1 = key2 = key3 這樣，他會存 {key1, ptr1}、{key2, ptr2} 與 {key3, ptr3}。

在新的架構下開啟 deduplication 後就會變成類似 {key1, [ptr1, ptr2, ptr3]} 這樣的結構。可以看出來在 key 重複的資料很多的時候，可以省下大量空間 (以術語來說的話，就是 cardinality 偏低的時候)。

這樣看起來可以降低不少壓力...

Amazon EBS 推出新的 io2 類型

Amazon EBS 保障 IO 效能的版本 Provisioned IOPS io1 進化了，推出了 Provisioned IOPS io2：「New EBS Volume Type (io2) – 100x Higher Durability and 10x More IOPS/GiB」。

目前先看了一下美國與新加坡的價錢，應該都還是一樣，看起來這次主要是功能性上的進步，有兩個比較顯著的改變。

第一個是每 GB 可以租用的 IOPS 數量上升了，io1 是 50 IOPS，在 io2 給到 500 IOPS；不過最大值不變，都還是 64k IOPS。這個看起來對於追求 IOPS 的人彈性增加不少，不過算了一下成本差距應該是還好，以最大的 64k IOPS 來算，光 IOPS 的費用就要 USD$4160/month，而最低的空間租量上，io1 租 1280 GB (USD$160/month) 與 io2 租 128 GB (USD$16/month) 在這個部分只能算零頭了...

第二個是持久性 (durability)，從 io1 的 99.9% 到 io2 變成 99.999% 了，這邊應該主要是受益於這十年 SSD 技術的進步。我猜本來的 io1 其實也拉高不少，只是 SLA 合約上沒有增加而已...

應該還是會守在 gp2 上，便宜大碗，不過效能的保證少了些，對於一般性的應用來說應該是夠用。

Backblaze 的 2020Q2 硬碟報告

在「Backblaze Hard Drive Stats Q2 2020」這邊又有資料可以看啦，主要是這張表：

比較讓我注意到的是，其中有個一千台的 HUH728080ALE600，AFR 居然是 0.00%，仔細看算了一下發現應該是弄來一批貨，上線約三個月 (91 天)，而目前還沒有壞掉而已...

不過 HUH728080ALE600 這個料號很有趣啊，在搜尋的時候發現 Ptt 上 2018 年的文章「Re: [請益] 關於HUH728080ALE604 這顆8t硬碟」這邊有提到這個號碼，裡面有猜測這個料號的來源：

查了一下發現有趣的事實
國外資料都指出,OEM的原廠HGST沒有給予保固
且驗證序號會是無效的序號
但中國地區驗證 OEM序號卻是有效
所以合理懷疑HGST將生產過剩的 OEM產品轉到中國銷售?
並將這些 OEM序號登錄至HGST資料庫內
當然這些標籤都是貼HGST的, 貼DELL或HP標的都是查無有效序號
而且這些都是保五年, 保固低於五年可能就是有問題的
HUH728080ALE600 是目前有看到在中國銷售的
當然這都是沒有外盒包裝

不知道 Backblaze 是怎麼弄到這批貨的...

不過就算不管這批貨，HGST 整體上看起來還是很不錯，不過現在掛 HGST 的應該都是庫存了。

MariaDB 的 S3 Engine 效能測試

Percona 對 MariaDB 在 10.5 (目前的最新穩定版) 裡出的 S3 Engine 給出了簡單的測試報告：「MariaDB S3 Engine: Implementation and Benchmarking」。

這個 engine 顧名思義就是把資料丟到 Amazon S3 上，目前是 alpha 版本，預設是不會載入的，需要開 alpha flag 才能用：

The S3 engine is READ_ONLY so you can’t perform any write operations ( INSERT/UPDATE/DELETE ), but you can change the table structure.

另外這是從 Aria 改出來的 read-only engine，而 Aria 是從 MyISAM 改出來的：

The S3 storage engine is based on the Aria code and the main feature is that you can directly move your table from a local device to S3 using ALTER.

測出來發現在 read-only 的情境下，COUNT(*) 超快，看起來就是跟 MyISAM 體系有關，直接撈 MyISAM 內的資料，所以本地要 18 秒，但放到 S3 反而秒殺 XDDD

整體看起來還不錯？算是一種 Data warehouse 的方案，主要是要用到 row-based format 儲存的優點，遇到一些冷資料可以這樣玩。

從「Using the S3 Storage Engine」這邊的設定方式看到 s3_host_name，看起來有機會接其他家的 S3 API，或是本地的 Storage。

話說 Aria 這個引擎當初最主要的重點就在 crash-safe，在有了 crash-safe 之後，DRBD 這種 block-level replication 機制就可以硬幹上去，後來主力就在擴充其他型態了，像是 GIS 與 virtual column 的功能，不過這些功能本家在 InnoDB 上好像也都陸陸續續跟上來了，單純的 Aria engine 好像還好...

FreeBSD 12.2 在 AWS 的 Amazon EFS 整合 (autofs)

Colin Percival 提到了 FreeBSD 12.2 上 autofs 會整合 Amazon EFS，讓掛載進來變得更方便：「Some new FreeBSD/EC2 features: EFS automount and ebsnvme-id」。

用法是先設定 autofs，然後啟用 autofs：

# echo '/efs -efs' > /etc/auto_master 
# sysrc autofs_enable="YES"

然後重開機後就可以直接切到 /efs/FSID 把 EFS 掛起來了：

Having done this, any access to the path /efs/FSID (e.g., /efs/fs-01234567) will automatically and transparently mount that filesystem.

另外加上原來對 EBS 與 ephemeral disk 的支援，這樣 storage 的部份算是該有的都有了：

Using the tool and some devd magic, FreeBSD now maintains a tree under /dev/aws/disk containing the symlinks of the forms
/dev/aws/disk/ebs/vol-0123456789abcdef
/dev/aws/disk/linuxname/sdh
/dev/aws/disk/ephemeral/SERIALNO

Backblaze B2 支援相容 Amazon S3 的 API

Backblaze 宣佈支援相容 Amazon S3 的 API：「Backblaze B2 Cloud Storage Now Has S3 Compatible APIs」。

Amazon S3 的 API 算是 object storage 這個領域的 de facto standard 了，支援 Amazon S3 相容層可以讓現有的工具直接套用上去。

很多 client 軟體都藉著設定 API endpoint 的方式來支援 (通常預設會是 Amazon S3 的 s3.amazonaws.com)，這次的 endpoint 可以從 B2 的文件「S3 Compatible API」裡看到：

The format for endpoints for the Backblaze S3 Compatible API:
https://s3.<region>.backblazeb2.com
The Backblaze S3 Compatible API endpoints only accept connections over HTTPS. Non-secure connections will be rejected. The AWS SDKs and most integrations only require an Endpoint URL like the above (without the bucket name included).

另外也支援使用 bucket name 的形式操作：

If making the HTTP calls directly, the Backblaze S3 Compatible API supports specifying the bucket name in the hostname of the URL or in the path section of the URL. Both URLs below are valid examples of an endpoint calling a bucket:
https://bucketname.s3.us-west-001.backblazeb2.com
https://s3.us-west-001.backblazeb2.com/bucketname

B2 的另外一個優勢是 2018 的時候就跟 Cloudflare 合作 (參考「Backblaze 與 Cloudflare 合作，免除傳輸費用」)，從 B2 到 Cloudflare 的流量是不收費的，再加上 Cloudflare 的流量也可以是免費的，組合起來就變成一個很便宜的方案 (只有 B2 的 storage cost)。

Cloudflare 的另外一個策略：不熱門的資料只放到記憶體內

前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...

Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...

EBS io1 推出可以同時掛到多台的選項

EBS 的 io1 推出了可以同時掛到 16 台 EC2 instance 的選項：「New – Multi-Attach for Provisioned IOPS (io1) Amazon EBS Volumes」。

先看支援的區域，傳統主力區域 (us-east-1 與 eu-west-1) 都支援了，而亞洲區這邊反倒是南韓先支援了：

Multi-Attach for Provisioned IOPS (io1) volumes on Amazon Elastic Block Store (EBS) is available today at no extra charge to customers in the US East (N. Virginia & Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Seoul) regions.

其中常用的目的是 HA：

Multi-Attach capability makes it easier to achieve higher availability for applications that provide write ordering to maintain storage consistency.

Heartbeat 類的應用應該可以用上這個東西，不過本來就可以透過 command line API 做到 detach & attach，用這個只是少了一個動作...

第二個想到的是，在實體機房的環境下，有些 filesystem (在「Shared-disk file systems」裡面可以翻到一些) 可以同時掛同一個 block storage (通常是透過 SAN)，現在在 AWS 上面也可以這樣搞了。

不過 io1 記得不便宜啊...

Amazon Elasticsearch Service 可以利用 S3 當作二級儲存空間了

Amazon Elasticsearch Service 的新功能，使用 Amazon S3 當作第二級儲存空間 (UltraWarm)：「Announcing UltraWarm (Preview) for Amazon Elasticsearch Service」。

UltraWarm 需要不同的機器 (跑不同版本？)，機器的規格 (vCPU 與記憶體的比率) 接近 Memory Optimized 的版本，但是貴了不少，所以需要夠大的資料量才會打平回來...

拿 us-east-1 來看，SSD EBS 的空間成本就是 USD$0.135/GB，而傳統磁性硬碟是 USD$0.067/GB (不知道收不收 I/O 費用？)，但 storage 的價錢是 USD$0.024/GB。這邊值得一提的是 Amazon S3 是 USD$0.023/GB，看起來是直接包括了 API 的呼叫費用？