Home » Posts tagged "value"

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 跟現在的版本比起來的確沒那麼強...

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

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

前陣子 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 中間找到適合的點立足。

PostgreSQL 對 NoSQL 的看法...

二月的時候 PostgreSQL 的人在 FOSDEM PGDay 2013 上發表了對 NoSQL 的看法 (PDF 投影片):「PostgreSQL as a Schemaless Database.」。

先說明,這投影片相當酸 XD

不過這份投影片說明了大多數人的問題:

  • 其實大多用 NoSQL 的人不知道在用什麼...
  • 就算你知道你在用什麼,你用得很爽的功能其實在「傳統的」「SQL 架構」下效能通常都會更好...

另外我建議可以看看維基百科上的 Entity-attribute-value model,大多數你想用 NoSQL 的情況在這個 case 下就可以解決,而且效能相當好。

Archives