KataGo 的分散式訓練計畫啟動了

KataGo 應該是目前 open source 領域裡面數一數二強的圍棋引擎,在去年就一直在開發可以讓大家參與的分散式訓練計畫,最近釋出了 v1.8.0 版,算是公開啟動了:「KataGo Distributed Training」,作者在「KataGo distributed training is open!」這邊也有大概寫一下。

基本上照著官方網站上面的說明做就可以了,可以下載 precompiled binary 或是自己編,自己編的時候注意不能直接拿 master branch 裡面編 (client hash 會不對),我自己目前是用 v1.8.0 這個版本編出來跑。

Reddit 上面的「KataGo's new run is open for public contributions!」也可以看到說明的圖片 (要注意圖上的 X 軸不是線性),算是接著本來的 g170 訓練下去,另外也標示了 ELFv2Leela Zero 大致上的強度:

目前看起來陸陸續續有人開始參與了...

另外在 CGOS 上面也可以看到 kata1 開頭的 bot 在跑,而且看起來會一直把新的 training 成果更新上去跑。

分散式系統的介紹

Hacker News Daily 上看到講分散式系統的整理:「An introduction to distributed systems」,作者 (我記得他應該是在 Stripe?) 之前因為需要研究資料庫的正確性而搞了不少事情,還開發了對應的測試框架。

這篇文章把相關的理論都列出來,變成一篇滿滿都是關鍵字的文章。這邊提到的 12 到 16 小時應該是對於已經有基礎的人上課的時間,如果平常沒有在碰的人,以及需要自己學習的人應該會長很多:

This outline accompanies a 12-16 hour overview class on distributed systems fundamentals.

短時間應該看不完,但可以每個週末看一個主題研究一下... 然後也不用想太多,很多時候用單機硬幹 (scale up) 可以爭取到時間回來讀這些東西 & 設計系統轉換。

TiDB 單機效能

TiDB 是一個支援分散式運算的資料庫,希望能夠完整地模擬 MySQL Protocol,而 Percona 試著測試 TiDB 在單機的效能,雖然測試的項目很簡單,但結果頗有趣的:「A Quick Look into TiDB Performance on a Single Server」。

Percona 觀察到的現象是 TiDB 對於單一 SQL query 支援多 CPU 運算 (MySQL 只會使用單 CPU),所以在高階的機器上,某些 SQL query 會快很多。而 OLAP 類型的 SQL query 也不錯,但常見的 OLTP 應用則慢不少:

Short version: TiDB supports parallel query execution for selects and can utilize many more CPU cores – MySQL is limited to a single CPU core for a single select query. For the higher-end hardware – ec2 instances in my case – TiDB can be 3-4 times faster for complex select queries (OLAP workload) which do not use, or benefit from, indexes. At the same time point selects and writes, especially inserts, can be 5x-10x slower. Again, please note that this test was on a single server, with a single TiKV process.

是個有趣的 drop-in...

Cloudflare 推出 IPFS Gateway

Cloudflare 推出了自己的 IPFS Gateway:「Cloudflare goes InterPlanetary - Introducing Cloudflare’s IPFS Gateway」。

IPFS 偏靜態性應用 (雖然官方一直很堅持說動態的資訊也可以在上面跑),這就很適合 CDN 架構拿出來用... Cloudflare 出手應該可以讓 IPFS 的門檻再降低一些。

相較於官方提供的 ipfs.io,Cloudflare 的應該會快不少... (畢竟是直接連到最近的機房)

MySQL 的 XA Transaction

Percona 的「How to Deal with XA Transactions Recovery」這篇提到 MySQLXA Transaction 的復原問題。

XA Transaction 主要拿來做分散式上的事物交易,在官方文件上就有提到對應的標準:

The MySQL XA implementation is based on the X/Open CAE document Distributed Transaction Processing: The XA Specification. This document is published by The Open Group and available at http://www.opengroup.org/public/pubs/catalog/c193.htm.

不過我覺得比較有趣的是這點,Percona 直接建議不要用 5.6 的 XA:

But there is a limitation in 5.6: you can only XA commit/rollback transactions that belong to your session. That means after a crash you are out of luck. To get rid of these you need to promote a slave or perform a logical dump and restore. The best plan is to avoid the use of XA transactions with 5.6.

不過翻了 bug report,Oracle 官方的 5.7 還是沒解決,看起來是 Percona 自己 patch 掉 XDDD

Percona XtraDB Cluster 解釋最近的版本為什麼可以再度提昇效能

Percona XtraDB Cluster 最近的一個版本宣稱效能大幅提昇,這篇試著解釋原因:「How We Made Percona XtraDB Cluster Scale」。

裡面提了三個情境,解釋了這些效能問題以及解法,進而帶出這次的效能提昇:

With these three main optimizations, and some small tweaks, we have tuned Percona XtraDB Cluster to scale better and made it fast enough for the growing demands of your applications. All of this is available with the recently released Percona XtraDB Cluster 5.7.17-29.20. Give it a try and watch your application scale in a multi-master environment, making Percona XtraDB Cluster the best fit for your HA workloads.

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue,難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue:「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做:

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題,就如同 Netflix 提到的:

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上:

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 RedisMemcached 的系統,可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」,也就是有可能會有多次的情況,用 Dyno Queues 系統的人必需要考慮進去:

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆,但實際看起來還是很厚重... 暫時還是不會用吧 :o

奇怪的 RFC:Naming Things with Hashes

看到「RFC 6920: Naming Things with Hashes」這個,看日期是 April 2013,就在想是不是四月一號發的... 但內容看起來還頗有用的,有種 distributed web 的味道?文件裡給的範例長這樣:

<html>
 <head>
   <title>ni: relative URI test</title>
   <base href="ni://example.com">
 </head>
 <body>
   <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
     and <a href="sha-256;UyaQV...">this other document</a>.
     and <a href="sha-256-128;...">this third document</a>.
   </p>
 </body>
</html>

目前是 Propsed Standard,所以是怎樣呢...

IPFS 分散式 Web 服務,以及 ipfspics 圖片儲存

IPFS (InterPlanetary File System),或是被稱作 The Permanent Web。

起因在於目前 HTTP (Web) 在設計時是 1990 年代的想法,許多威脅在當時並不明顯。而到了現在,來自攻擊者的威脅與政府監控的威脅使得必須在 HTTP (Web) 上架構許多 workaround。

最知名的 workaround 就是 HTTPS 以及對應的 CA 架構了,前者因為 HTTPS 協定本身高度複雜,實作的單位經常出錯而產生安全漏洞。而後者靠著大量的稽核檢查來避免出問題,不過畢竟還是 workaround,常常會有一堆「誤發」的狀況發生。

另外 HTTP 發展到現在其實是去中心化「Decenteralized」的架構,政府單位可以抓著其中幾個結點就可以大量監控,而 IPFS 想要做到真正的分散式「Distributed」:

前陣子 IPFS 在 GitHub 上放出了 prototype 讓大家玩:「ipfs implementation in go.」,而最近有人把這個點子實作成 image hosting:「ipfs.pics」(一樣是放在 GitHub 上),並且提供對應的網頁上傳介面:「Decentralized picture hosting in ipfs」。

我試著丟一張圖片上 ipfs.pics 後,得到的 hash 值是 QmRpNqK33gDDKdu8y6Wx5DQsuiJbsnwojNzH5nUwCpwoS9,也可以在 IPFS 看到這張圖:

來玩看看好了 :o