eBay 提供的 TSV 工具組

Hacker News Daily 上看到的,eBay 提供了操作 TSV 的工具組:「eBay/tsv-utils」。

看到了兩個比較少見的東西,第一個是軟體授權是 permissive license (Boost Software License),第二個是使用的程式語言是 D...

TSV 的確是比 CSV 好用不少,只是會用的單位好像有限...

資料裡還蠻常見出現 , 的情況 (得用 double quote 包起來,但是再遇到 double quote 的時候就用 double double quote...),但比較少遇到會有 tab 出現...

新創的 Stock Options 風險與價值

看到 TLDR Stock Options 這個站,印象中這個站已經存在一陣子了 (以前有看過的印象,但沒寫下來?),不知道後續資料有沒有更新...

這個站把輸入的資料大幅簡化 (只需要寫比重與現在在哪一輪),然後給兩個數字,一個是你可以預期公司成功 exit 的比率,另外一個是你預期會拿到的金錢。

這是大幅簡化的數字 (沒有區分領域與地域),不過如果對 stock options 沒有概念的話可以抓個感覺。

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 的基本功能都可以直接在上面跑了... 而搜尋靠外部服務,圖片與影音也可以靠外部空間協助?

Vultr 開始要收台灣的稅了...

這幾天收到 Vultr 的通知信,要收 5% 的稅了:

Dear Valued Client,

Vultr.com will start collecting a Value Added Tax (also known as VAT) for services provided after 2018 June 01 in order to comply with new Taiwan regulations. Beginning on 2018 July 1, your invoices will include an additional tax charge of 5% for customers who purchase electronic services in Taiwan. The tax is applied to comply with new Taiwan VAT legislation requiring non-residents who are providing "remote services" to begin collecting Taiwanese VAT on these services when they are provided to Taiwanese residents or persons who are not registered for VAT.

Affected customers need to submit their VAT ID to Vultr. If you don’t provide a business VAT ID, your account charges might increase.

If you have any questions about this upcoming change, please contact our support team today. Thank you again for being a customer!

The Vultr.com Team

從 2018 七月開始收...

Percona 比較 MySQL 與 MariaDB 預設值的差異

Percona 的人花了些時間整理 MySQL 5.7 與 MariaDB 10.2 在預設值上的差異:「MySQL and MariaDB Default Configuration Differences」。

整體可以感覺到 MariaDB 10.2 相較於 MySQL 5.7 還是頗偏 MyISAM 的設計,可能跟 Monty (Michael Widenius) 的偏好有關吧... 不過技術面上來說,MariaDB 10.2 是基於 5.5 分支出來一路改出來的,當時的 InnoDB 跟現在的版本比起來的確沒那麼強...

不過這畢竟只是預設值,看過留個印象就好...

官方支援 DynamoDB 的 Auto Scaling 了

DynamoDB 可以透過 console 或是 API 調整 R/W 的 capacity,但一直都沒有全自動的機制這件事情為人詬病頗久。

以前都是自己用 AWS Lambda 或是其他架構判斷調整,現在官方直接提供了:「New – Auto Scaling for Amazon DynamoDB」。

終於啊...

關於圍棋貼目的問題...

前陣子 AlphaGo 大獲全勝後放出了五十盤自戰棋譜 (兩台 AlphaGo 自己下),其實有件事情有點出乎大家意料,而在圍棋界被一直討論。就是在這五十盤裡,黑棋與白棋的勝率比是 12:38 (中國規則,黑棋貼 7.5 目的情況),明顯白棋有強大的優勢。

這個 7.5 目指的是,由於黑棋先下 (先手優勢),所以圍的地會比較多,為了彌補白棋後下的這個缺點,一般都會設計「貼目」這個規則。

交大資工的 CGI 團隊在上個月月底發了一篇論文 (參考「CGOS Whole Period Ratings for 19x19 Board」這邊的記錄,在有參加 CGOS 的團隊裡只輸新版的 Zen),討論 value network 的新想法:「Multi-Labelled Value Networks for Computer Go」。

他們對貼目的數量做了分析:

For the training data, we label on output 𝑣𝑘 as follows. For each self-play game, first calculate territory difference 𝑛 at the end of the game. Then, based on the Chinese rule, label 1 (win) on 𝑣𝑘 for all 𝑘 < 𝑛, and -1 (lose) for all 𝑘 > 𝑛. (Note that the draw case 𝑘 = 𝑛 is ignored in this paper since the komi is not an integer normally.) For example, if black occupies 7 more points of territory than white, the 𝑘-komi game is considered a win for all 𝑘 < 7, and a loss for all 𝑘 > 7. Thus, in this case, a 7.5-komi game is a loss, and a 6.5-komi or 0.5-komi game is a win.

這個研究完全顛覆了目前職業棋手一般的理解。目前的理解是,貼 5.5 目是黑棋優勢,貼 7.5 目是白棋優勢 (所謂的大貼目時代)。

接下來應該會有更多的研究出來,圍棋界會不會反思貼目規則呢...

用 Go 寫的 Badger

Dgraph 在推銷自家發展出來的 Badger:「Introducing Badger: A fast key-value store written natively in Go」。

標靶是 RocksDB,號稱比 RocksDB 快好幾倍:

Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.

不過我覺得有些重要的功能在 Badger 不提供,這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction,而 Badger 則是直接講明他們不打算支援 Transaction:

Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.

Berkeley DB 的介紹

在滿滿都是 NoSQL 的世代中,意外在「Berkeley DB: Architecture」這邊看到 Berkeley DB 的介紹...

2006 年 Berkeley DB 的公司 SleepycatOracle 收購。在收購後 Oracle 改變了 open source 授權部份,從之前的 Sleepycat License 改成了 AGPLv3

Berkeley DB 算是早期功能很完整的 database library,由於 page level locking、crash-safe 加上有 transaction,也曾經被 MySQL 拿去當作 engine,不過在 MySQL 5.1 被拔掉:「14.5 The BDB (BerkeleyDB) Storage Engine」。

文章裡講了很多底層設計上的想法 (而非單純只說明「做了什麼」),以四個面向來討論。Buffer、Lock、Log 以及 Transaction,並且圍繞著 ACID 需求討論。

算是懷念的考古文?Google 弄出來的 LevelDBFacebook 接著改善的 RocksDB 的走向也不太一樣了,現在大家對 ACID 需求因為 NoSQL 盛行的關係又重新在檢視...

真正的 Redis Cluster

也是積了很久的文章,Redis 的其中一位老大 Salvatore Sanfilippo 在第一個公開 Redis Cluster 功能的 3.0.0-rc1 版寫下了 Redis Cluster 的發展過程:「Redis cluster, no longer vaporware.」。

MySQL InnoDB 可以保證極強的 ACID 特性,配合 DRBD 這類的 HA 架構,可以保證 server 回了成功後一定不會掉資料。

memcached 則是 Shared nothing architecture,當初設計就是拿來當 cache,資料隨便掉沒關係。

兩者中間還是有很大的空間,而 Redis Cluster 的出現有機會入場看看情況了,不知道能不能在 InnoDB 與 memcached 中間找到適合的點立足。