從 Cassandra 到 ScyllaDB 的轉移方式好像跟以前不太一樣了...

在「New Docs: Four Phases to Migrate from Apache Cassandra to Scylla」這邊看到 ScyllaDB 官方提供 Cassandra 轉移到 ScyllaDB 的說明,跟以前好像差蠻多的...

以前 ScyllaDB 可以直接加入到 Cassandra 的 cluster (一時間沒找到資料,但在「can not add node with cassandra ami · Issue #107 · scylladb/scylla-cluster-tests」可以看到當時的痕跡),現在給的方法是在資料庫不相容時的轉移方式 (像是從 MySQL 轉換到 PostgreSQL 這種),是暗示已經沒辦法這樣做了嗎?

不過從 GitHub 上的 wiki page 看起來,底層資料與 protocol 應該還是相容的,才能做直接複製資料的 offline migration:「Migrating Cassandra data to Scylla」。

也有可能這篇只是寫手隨意寫的文章,沒有把 ScyllaDB 的優勢展現出來...

About John Hammink
John Hammink is a writer and content creator at ScyllaDB. With more than 20 years in technology, he's also a touring/studio musician, digital artist and speaker.

在 MOPCON 2017 的 Unconference「MySQL to NoSQL & Search Engine」

把投影片傳到 Speaker Deck 上了:「MySQL to NoSQL & Search Engine」。

這是在介紹 noplay/python-mysql-replication 這個軟體,我在示範時用的 python script 有增加 blocking 參數讓他保持一直讀取 MySQL replication stream:

from pymysqlreplication import BinLogStreamReader

mysql_settings = {'host': '127.0.0.1', 'port': 3306, 'user': 'root', 'passwd': ''}

stream = BinLogStreamReader(connection_settings = mysql_settings, server_id=100, blocking=True)

for binlogevent in stream:
    binlogevent.dump()

stream.close()

利用這樣的工具可以做很多事情,像是當 post 表格更新時自動更新 search engine,並且清空 memcached 內的資料。這可以避免使用 library 時有可能會漏掉忘記做 (因為有些程式不用 library 處理),可靠度比較高。

另外一方面 replication protocol 本身就有考慮重連的問題,重新接上時是可以從上一次處理完的資料繼續處理 (只要不要隔太久),這讓寫應用的人不需要用太複雜的方式確保他不會漏掉。

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

Scylla 1.4 系列的發佈

ScyllaDB 最近發行了 Scylla 1.4 與 1.4.1:「Scylla release: version 1.4」與「Scylla release: version 1.4.1」,另外也整理出 Docker 版本:「Scylla on Docker」。

可以從 1.4 的公告裡面看到功能愈來愈完整了,在導入其他跟 Cassandra 配合的軟體應該會愈來愈順,而且就之前用 Presto 而去 Scylla 的 GitHub 上回報問題的經驗,Scylla 的人對於能夠生出可重製的 bug report 還蠻重視的,解決速度都還算合理...

另外提供 Docker image 也讓想要測試的人變方便...

Scylla 1.3

看到 Scylla 正式公告 1.3 版的消息了:「Scylla release: version 1.3」。

Scylla 是用 C++ 重寫 Java 版本的 Cassandra 所有東西 (包括資料結構與 Protocol),目標是做到可以完全相容替換現有 Cassandra Cluster。(號稱可以一台一台移除 Cassandra 的程式,裝上 Scylla 後就可以無痛換過去)

而 Scylla 另外一個重點是效能的提昇,官方宣稱在完整最佳化的情況下是 10x 以上的效能提昇,之前拿 AWS 實測 (沒有完整最佳化) 也可以看到 2x 到 4x 的數字,對於目前的 Cassandra 應用來說極為重要。

1.3 版最重要的功能就是對 Thrift 的支援:

Thrift support. Many Cassandra users are still using Thrift, and they can now continue doing so while benefiting from Scylla’s performance. Built on top of Scylla CQL internal implementation, Scylla Thrift provides similar throughput and latency to Scylla CQL. Users of projects like KairosDB and Titan can now migrate to Scylla while maintaining full protocol compatibility .

本來在 roadmap 上的計畫是用兩個版本支援 Thrift:(從 Google Cache 拉出來的,CSS 看起來有些問題,不過意思有到就好)

剛剛發現 1.4 的 roadmap 已經沒有列 Thrift 了:

這應該是暗示已經實作完了?透過 Thrift 界面跟 Cassandra 溝通的應用程式都可以使用 Scylla 了...

先前在「Facebook Presto · Issue #1139 · scylladb/scylla」這邊跟 ScyllaDB 的人花了不少時間,總算是給出一份 data set 可以讓他們重製 bug,也算是有代價了 XD

Ruby 上使用 DynamoDB 的函式庫:aws-record

AWS 正式發表了在 Ruby 上使用 DynamoDB 的 library:「Announcing General Availability of aws-record」。

GitHub 連結在「aws/aws-sdk-ruby-record」,而 Ruby Gems 的連結在「aws-record」。

這樣用起來更簡單了...

對 NoSQL 分析的大量說明與圖表

Twitter 上看到「NoSQL Databases: a Survey and Decision Guidance」這邊有夠長的,對於還不熟悉目前 NoSQL 常用到的理論技術的人,剛好可以拿來看一看...

對於熟悉的人來說,這些圖表整理的頗不錯:

不過 NoSQL 裡面頗多地雷,大家保持健康的心態用就是了 XDDD

維基百科的 User Agent 公開資料

Nuzzel 上看到的東西...

維基百科不掛 Google Analytics 之類的第三方服務,而是透過 Piwik 蒐集後自己分析:「Dashboards and Data Downloads for Wikimedia Projects」。

主要有兩個資料可以看,一個是「Browser Statistics」,另外一個是「Readers: Pageviews and Unique Devices」。

不過翻了一下,Piwik 好像還是沒有寫到 NoSQL 之類的方案,出自「How do I use another database like Postgresql, SQLite, Oracle? Will you support Nosql databases like Hadoop, Mongodb?」:

Piwik only works on Mysql, where all the development and testing is done. Supporting multiple databases is a long term objective for Piwik, but not our current focus.

不知道維基百科是怎麼 scale 的...

資料庫在 EC2 上選擇 Instance Type 的方向

ScyllaDBCassandra 的 C++ 相容版本,效能比起 Java 版本的好不少 (尤其是與 CPU 與記憶體有關的部份)。

ScyllaDB 的人上個月給了一份指南,主要是在講在 Amazon EC2 上怎麼選 instance type 跑 NoSQL (主要還是針對 ScyllaDB 的情境下分析)。不過道理是通的:「Choosing EC2 instances for NoSQL」。

不同於 Cassandra 比較容易吃到 CPU bound,ScyllaDB 比較容易吃到 i/o bound,所以 i/o 的效能對於選擇 instance type 重要許多。

後面也有提到 instance size 的問題 (八台 xlarge 還是一台 8xlarge),不過感覺沒有給很清楚的方向。一般來說,分散式資料庫之間溝通還是有不少成本在,另外文章裡也提到同一台實體機器的鄰居造成 i/o noise 的問題,看起來在經濟規模夠大的情況下,開到最大台才是王道啊?

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