DynamoDB 可以透過 console 或是 API 調整 R/W 的 capacity，但一直都沒有全自動的機制這件事情為人詬病頗久。
以前都是自己用 AWS Lambda 或是其他架構判斷調整，現在官方直接提供了：「New – Auto Scaling for Amazon DynamoDB」。
終於啊...
官方支援 DynamoDB 的 Auto Scaling 了
Tag: value
關於圍棋貼目的問題...
前陣子 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 的公司 Sleepycat 被 Oracle 收購。在收購後 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 弄出來的 LevelDB 與 Facebook 接著改善的 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 中間找到適合的點立足。
PostgreSQL 對 NoSQL 的看法...
二月的時候 PostgreSQL 的人在 FOSDEM PGDay 2013 上發表了對 NoSQL 的看法 (PDF 投影片)：「PostgreSQL as a Schemaless Database.」。
先說明，這投影片相當酸 XD
不過這份投影片說明了大多數人的問題：
- 其實大多用 NoSQL 的人不知道在用什麼...
- 就算你知道你在用什麼，你用得很爽的功能其實在「傳統的」「SQL 架構」下效能通常都會更好...
另外我建議可以看看維基百科上的 Entity-attribute-value model，大多數你想用 NoSQL 的情況在這個 case 下就可以解決，而且效能相當好。