Ribbon filter

RocksDB 的 blog 上看到「Ribbon Filter」這個,主要是 RocksDB 從 6.15 開始支援 Ribbon filter,取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量:

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到,Facebook 之前也有提到 Ribbon filter:「Ribbon filter: Practically smaller than Bloom and Xor」,在 Hacker News 上有對應的討論可以翻:「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較,先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體,算是特化的版本...

Instagram 解決 Cassandra 效能問題的方法

在解決 Cassandra 效能問題中大概就 ScyllaDB 特別有名,用 C++ 重寫一次使得效能大幅改善。而 Instagram 的人則是把底層的資料結構換掉,改用 RocksDB (這公司真的很愛自家的 RocksDB...):「Open-sourcing a 10x reduction in Apache Cassandra tail latency」。

主要原因是他們發現 Cassandra 在處理資料的部份會有 JVM 的 GC 問題,而且是導致 Cassandra 效能差的主要原因:

Apache Cassandra is a distributed database with it’s own LSM tree-based storage engine written in Java. We found that the components in the storage engine, like memtable, compaction, read/write path, etc., created a lot of objects in the Java heap and generated a lot of overhead to JVM.

然後在換完後測試可以看到效能大幅提昇,也可以看到 GC 的延遲大幅降低:

In one of our production clusters, the P99 read latency dropped from 60ms to 20ms. We also observed that the GC stalls on that cluster dropped from 2.5% to 0.3%, which was a 10X reduction!

比較一下這兩者的差異:在 ScyllaDB 是全部都用 C++ 改寫 (資料結構不換),這樣就直接解決掉 JVM 的 GC 問題。在 Rocksandra 則是在 profiling 後挑重點換掉 (這邊看起來是處理資料的 code,直接換成 RocksDB),另外順便把一些界面抽象化... 兩個不一樣的解法,都解決了 JVM 的 GC 問題。

Apache Foundation 宣佈禁止使用 Facebook BSD+Patents 的軟體

在「RocksDB Integrations」這邊討論到 RocksDBFacebook 所使用的 Facebook BSD+Patents License。

不過因為 RocksDB 最近在換 license (從 Facebook BSD+Patents 換到 Apache License, Version 2.0),移除了 PATENTS 內的限制,需要看 PATENTS 的舊檔案可以在 PATENTS 這邊看到。

Chris Mattmann 正式發出決議禁用 Facebook BSD+Patents License。(參考最後)

另外也提到了 Facebook 是故意埋下這些限制:

Note also Roy's comment that he has discussed the matter with FB's counsel and the word is that the FB license is intentionally incompatible. It is hard to make the argument that it is compatible after hearing that. Pragmatically speaking, regardless of any semantic shaving being done, having a statement like that from the source of the license is very daunting. If they think it is incompatible, we need to not try to wheedle and convince ourselves it is not.

這個 license 之後應該會有更多挑戰...


As some of you may know, recently the Facebook BSD+patents license has been
moved to Category X (https://www.apache.org/legal/resolved#category-x).
Please see LEGAL-303 [1] for a discussion of this. The license is also referred
to as the ROCKSDB license, even though Facebook BSD+patents is its more
industry standard name.

This has impacted some projects, to date based on LEGAL-303
and the detective work of Todd Lipcon:

Samza, Flink, Marmotta, Kafka and Bahir

(perhaps more)

Please take notice of the following policy:

o No new project, sub-project or codebase, which has not
  used Facebook BSD+patents licensed jars (or similar), are allowed to use
  them. In other words, if you haven't been using them, you
  aren't allowed to start. It is Cat-X.

o If you have been using it, and have done so in a *release*,
  you have a temporary exclusion from the Cat-X classification thru
  August 31, 2017. At that point in time, ANY and ALL usage
  of these Facebook BSD+patents licensed artifacts are DISALLOWED. You must
  either find a suitably licensed replacement, or do without.
  There will be NO exceptions.

o Any situation not covered by the above is an implicit
  DISALLOWAL of usage.

Also please note that in the 2nd situation (where a temporary
exclusion has been granted), you MUST ensure that NOTICE explicitly
notifies the end-user that a Facebook BSD+patents licensed artifact exists. They
may not be aware of it up to now, and that MUST be addressed.

If there are any questions, please ask on the legal-discuss@a.o


Chris Mattmann
VP Legal Affairs

[1] https://issues.apache.org/jira/browse/LEGAL-303

用 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.

Percona 宣佈支援 MyRocks (MySQL 上的 RocksDB engine)

RocksDBFacebookGoogle 放出的 LevelDB 改出來,然後被更多人接受並且投注資源的 library... (看兩邊的 GitHub 應該就會有感覺了)

而 Facebook 的人在改進後又花了不少力氣 porting 到 MySQL 上...

之前 Twitter 上就有看到不少消息,這次算是在 Percona 官方的 blog 上正式公佈要支援 MyRocks 的消息:「Announcing MyRocks in Percona Server for MySQL」。

依照目前的計畫次在明年 2017 的 Q1 放出 experimental build,依照 Percona 的品質慣例,應該是可以拿來在測試環境下跑的順順的 (在還沒有 heavy loading 的前提下):

We will provide the experimental builds of MyRocks in Percona Server in Q1 2017, and we encourage you to start testing and experimenting so we can quickly release a solid GA version.

文章下面的 comment 剛好有人提到 Percona 另外一個產品線 TokuDB,這兩個產品線重複的問題:

MyRocks seems pretty similar to TokuDB. They are both write-optimized. MyRocks uses LSM tree while TokuDB uses fractal tree.

How do the 2 compare? Which one would you recommend using?

之前被 Percona 買下的 TokuDB 跟 Facebook 所發展出來的 MyRocks 的產品重複性頗高 (都是為了寫入的部分最佳化)。應該還是因為 fractal treeLSM tree 成熟度造成的效能差異還是太明顯吧 (當然另外也跟後面公司投入的資源有關),讓 Percona 決定還是要支援 MyRocks,而不是全力推動自家買下的 TokuDB... (唔,變成阿斗了?)

不知道成熟後有沒有機會變成 InnoDB replacement...

Mark Callaghan 講最近的 MySQL 的行銷活動...

Mark Callaghan 這篇倒是沒提到什麼技術的東西,主要是講最近 MySQL 的兩大 conference,一個是 OracleOracle Open World,另外一個是 PerconaPercona Live Amsterdam 2016,然後用了 benchmarketing 這個酸酸的詞 XDDD:「Peak benchmarketing season for MySQL」。


My joke is that each of these makes a different group happy: performance -> marketing, usability -> developers, manageability -> operations, availability -> end users, efficiency -> management.

另外提到了 RocksDB 建出來的 MyRocks 在 memory fit 時可能會比 InnoDB 還要好:

One last disclaimer. If you care about read-mostly/in-memory workloads then InnoDB is probably an excellent choice. MyRocks can still be faster than InnoDB for in-memory workloads. That is more likely when the bottleneck for InnoDB is page write-back performance. So write-heavy/in-memory can still be a winner for MyRocks.


MySQL 上 InnoDB 與 RocksDB 的差異

Mark Callaghan 在「MyRocks vs InnoDB with Linkbench over 7 days」這邊分析了 MySQL 上的兩個 engine 的差異,總結是大獲全勝:

  • InnoDB writes between 8X and 14X more data to SSD per transaction than RocksDB
  • RocksDB sustains about 1.5X more QPS
  • Compressed/uncompressed InnoDB uses 2X/3X more SSD space than RocksDB

但 InnoDB 的 engine 是 2000 年的設計 (16 年前),MyRocks 的 engine (RocksDB) 則是 2013 年的設計,不屬於同一個世代。

相較於與 InnoDB 對打,我更想看到的是與 TokuDB (2012 年的設計) 對打的結果。

兩個新的 engine 都有針對 SSD 的特性發展,可以看出資料結構與寫入的方式就很不一樣,而且一開始就是在多 CPU 多核環境下開發,相較於 InnoDB 是一路改的包袱來的輕鬆許多。

Percona 正式推出相容於 MongoDB 的產品「Percona Server for MongoDB」

Percona 正式推出與 MongoDB 相容的產品 Percona Server for MongoDB:「Percona Delivers Free, Open Source Percona Server for MongoDB」。

挑重點講,其實最重要的是 data engine 多了 Percona 自家的 PerconaFT 以及 FacebookRocksDB

Percona Server for MongoDB offers all the features of MongoDB 3.0 Community Edition, along with two additional storage engine options – PerconaFT and Facebook’s RocksDB

PerconaFT 是基於被併購的 Tokutek 所研發的 TokuDB (Fractal tree index) 而誕生的產品,在效能上有相當的優勢...

如果有機會的話來研究看看吧 :o

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 盛行的關係又重新在檢視...

InnoDB 的 checkpoint 問題,以及 RocksDB...

Percona 的「InnoDB checkpoint strikes back」這篇提到了 InnoDB 的 checkpoint 問題一直困擾著 MySQL 使用者,但其中讓我注意到的是,文中提到了 RocksDB 沒有這個困擾:

Interestingly enough, RocksDB, because it has a different architecture (I may write on it in future, but for now I will point to RocksDB Wiki), does not have this problem with checkpoints (it however has its own background activity, like level compactions and tombstone maintenance, but it is a different topic).

我記得 Facebook 的人有用 RocksDB 掛到 MySQL 上:「RocksDB Storage Engine for MySQL」,會整合到 WebScaleSQL 裡嗎?還是單純拋出來看看?:o