Tag: cassandra

Apple 使用 Cassandra 的量

Hacker News Daily 上看到的：「Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB (twitter.com/erickramirezau)。原文在 Twitter 上：

有些數字有點對不太起來，裡面提到 300K nodes + millions of QPS，但通常讀寫都算 QPS，這樣聽起來很少？所以有種可能這邊是只有算 read 的部份...

另外照片裡面提到 Over two petabytes per cluster，但有 thousands of clusters，最後卻只有 Hundreds of petabytes of data，完全對不上，就算當作平均值來算也對不上，只能猜測是最大的 cluster 而不是 per cluster。

裡面矛盾的地方太多，所以這些數字基本上沒有參考價值，現在能讀出來的只知道 Apple 有在用 Cassandra，然後不是少少幾台 PoC 等級的使用。

ClickHouse 自家做的 benchmark 比較

在「Show HN: A benchmark for analytical databases (Snowflake, Druid, Redshift) (clickhouse.com)」這邊看到 ClickHouse 自家做的 benchmark 比較，網站在「ClickBench — a Benchmark For Analytical DBMS」這邊。

這種 benchmark 基本上是拿來當作清單來看，另外 Hacker News 上的討論一定得看，尤其是沒被列上 benchmark 的...

講到 ClickHouse，先前是有朋友跑來說他有個需求是需要跑分析，但遇到用 PostgreSQL 時發現寫入速度不夠快的問題，看看有沒有什麼方法可以解。問了多一點以後發現他的需求是 OLAP 類而不是 OLTP 類，就先跟他講要去找 OLAP engine 來解決。

然後就聊到維基百科上「Comparison of OLAP servers」這個條目，裡面列出來的 open source 軟體是不少，但 Apache 家基本上大家都知道是回收場，裡面就剩下 ClickHouse 比較常在 Hacker News 以及其他地方被提到，但我有跟他講我連玩都沒玩過，我們家自己反而是用 Cassandra 與 Trino 搭出來的，當時沒有花太多時間研究市場上的方案，就挑了一個自己熟悉的方案趕快先解決。

但過了兩天後他就說用 ClickHouse 解決了，反而讓我對 ClickHouse 有興趣起來，反正記憶體當時裝了一堆沒用到。

拉了一下「Summary of the 1.1 Billion Taxi Rides Benchmarks」這邊的資料看，這個作者常常會測各種資料庫，算是一個可以參考的資料來源，可以看到 2019 年測的「1.1 Billion Taxi Rides: 108-core ClickHouse Cluster」其實就相當不錯了？

基本上先照「Usage Recommendations」這邊看一輪，基本的要求不低，但剛好機器是 32GB RAM：

If your system has less than 16 GB of RAM, you may experience various memory exceptions because default settings do not match this amount of memory. The recommended amount of RAM is 32 GB or more. You can use ClickHouse in a system with a small amount of RAM, even with 2 GB of RAM, but it requires additional tuning and can ingest at a low rate.

如果要跑 cluster 模式的話會需要 ZooKeeper 或是替代品 ClickHouse Keeper。

然後除了使用官方的 clickhouse-client 連線以外，也可以用 MySQL 或是 PostgreSQL 的 client 連，裡面操作其實蠻簡單的，好像值得投資看看？

Cassandra 也被 AWS 包成服務了

也是剛剛發表的服務 (所以在 Twitter 上看到)，把 Apache Cassandra 包成服務，叫做 Amazon Managed Apache Cassandra Service：「New – Amazon Managed Apache Cassandra Service (MCS)」。

而且是個 serverless 服務，直接用服務，不需要管理機器：

Amazon MCS is serverless, so you pay for only the resources you use and the service automatically scales tables up and down in response to application traffic.

從計費的方式也可以看出來這點，是對 Write request units、Read request units 與 Storage 收費，沒有看到機器的費用。

不過稍微算了一下不算便宜，如果沒有用到 Cassandra 的特性的話，比 DynamoDB 貴一些？

目前是 open preview 狀態，是個可以用但是不掛保證的意思：

Amazon MCS is available today in open preview in US East (N. Virginia), US East (Ohio), Europe (Stockholm), Asia Pacific (Singapore), Asia Pacific (Tokyo).

算是多個選擇可以玩...

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 問題。

Netflix 在 Time Series Data Storage 上的努力...

在「Scaling Time Series Data Storage — Part I」這篇看到 Netflix 在 Time Series Data Storage 上所做的努力...

因為應用在寫多讀少的場景，所以選擇使用 Cassandra，遇到瓶頸後把常寫入的與不太會改變的拆開儲存，並且用不同方式最佳化。包括了 cache 與 compression 都拿出來用了...

不知道他們內部有沒有評估 ScyllaDB 的想法...

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

ScyllaDB 2.0 要引入 Cassandra 3.0+ 的 Materialized View

最近 ScyllaDB 的網站改版了... (有種不習慣的感覺)

ScyllaDB 2.0 打算要引入 Materialized View (出自 Apache Cassandra 3.0+)：「Materialized Views preview in Scylla 2.0」。

一般 Materialized View 的實做方式是另外存一份，所以你可以在上面加 Index 之類的設定讓存取速度變快...

不過 Cassandra 不是本來就以讀慢寫快為優勢嗎，要速度可以考慮用 cache 疊出來，或是其他方式，當初 Cassandra 會開發這個功能就有點... XDDD

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

在「RocksDB Integrations」這邊討論到 RocksDB 裡 Facebook 所使用的 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 之後應該會有更多挑戰...

Hi,

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

Thanks.

Cheers,
Chris Mattmann
VP Legal Affairs

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

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。

ScyllaDB 1.7 支援 Counters 了

在「Scylla release: version 1.7」這邊看到 ScyllaDB 支援 Counters 的消息了 (雖然剛出來，掛著 Experimental 的消息)：

Scylla now supports Counters as a native type. A counter column is a column whose value is a 64-bit signed integer and on which two operations are supported: incrementing and decrementing.

這其實是 Cassandra 其中一個強項，針對 counter 這種應用特化的資料型態。