5分鐘瞭解ScyllaDB

語言: CN / TW / HK

時間 2022-01-17 21:19:01 OPPO數智技術

1 概述

什麼是 Scylla？Scylla 官網上面的描述很好的回答了這個問題

The Real-Time Big Data Database

Scale-up performance of 1,000,000s of OPS per node, scale-out to hundreds of nodes and 99% latency of <1 msec

翻譯過來是 Scylla 是實時大資料資料庫，可以支援每個節點 1,000,000 OPS 的垂直擴充套件效能，水平可以擴充套件到數百個節點，99% 的訪問延遲可以低於 1 毫秒。Scylla 是效能優異的 NoSQL 寬列儲存資料庫，完全相容 Apache Cassandra 並提供了更低的延遲，其 shard-per-core 設計使其能夠以亞毫秒平均延遲每秒執行數百萬次操作。

壓測叢集：3 節點 CF=3 CL=1

圖片來源於網路

在 DB-Engines 的資料庫排名中，Scylla 表現了強大的活力，從 16 年開始排名迅速攀升，目前在寬表資料庫領域已經超過了 Bigtable 穩居第六名。

下面我們從幾個方面來介紹 Scylla 以及 Scylla 在 OPPO 的應用現狀。

2 Scylla 支援的特性

1）完全相容 Cassandra

Scylla 作為 Apache Cassandra 的替代品和完全支援的 Cassandra 遷移功能的替代品。Scylla 提供相同的 CQL 介面和查詢、相同的驅動程式，甚至相同的磁碟 SSTable 格式，但採用了用來消除 Cassandra 效能問題、限制和操作障礙的現代架構。

2）支援可調一致性

Scylla 通過為每個請求指定一個 Consistency Level (CL縮寫，一致性級別) 來決定成功寫入或讀取多少個副本才返回成功。

常用的 Consistency Level 有：

ANY – 寫入必須至少寫入叢集中的一個副本。該等級以最低的一致性提供最高的可用性。

QUORUM – 當大多數副本成功響應後，請求返回成功。如果 RF=3，則需要 2 個副本響應。可以使用公式 (n/2 +1) 計算 QUORUM ，其中n是複製因子。

ONE – 一個副本成功響應後，請求返回成功。跟ANY的區別是ANY寫入Hinted Handoff也算寫入成功。

LOCAL_ONE – 本地資料中心中至少有一個副本響應。

LOCAL_QUORUM – 本地資料中心的大多數副本做出響應。

EACH_QUORUM – （不支援讀取） – 必須寫入所有資料中心中的大多數副本。

ALL – 寫入必須寫入叢集中的所有副本，讀取等待所有副本的響應。以最高的一致性提供最低的可用性。

無論 Consistency Level 如何設定，寫請求總是傳送到所有的副本，副本個數由 Replication Factor（RF縮寫，複製因子）設定。一致性水平控制在一個客戶端什麼時候確認操作，而不是實際上有多少個副本被實際更新。在寫操作期間，協調器與副本進行通訊（副本的數量取決於複製因子）。當指定數量的副本確認寫入時，寫入成功。

圖片來源於網路

在上圖中，雙箭頭表示從客戶端進入協調器的寫操作請求和返回的確認。由於一致性級別為 1，因此協調器 V 只需要等待寫操作傳送到叢集中的一個節點 W 並獲得它的響應。

在讀取操作期間，協調器與剛好足夠的副本進行通訊以保證滿足所需的一致性級別。然後將資料返回給客戶端。

圖片來源於網路

Consistency Level 在 CQL 中可根據每個操作進行調整。這稱為 tunable consistency（可調一致性）。有時響應延遲更重要，因此有必要在每個查詢或操作級別調整設定用來覆蓋鍵空間甚至資料中心範圍的一致性設定。換句話說，Consistency Level 設定允許你在一致性與延遲的權衡中選擇一個點。

3）高可用

Scylla 是一個高可用的快速 NoSQL 資料庫。磁碟驅動器、節點、機架甚至整個資料中心都可能出現故障，你的應用程式不能失敗，它們始終線上。這是高可用性資料庫系統的目標。Scylla 通過一些機制實現零停機，包括機架和資料中心感知，以及多資料中心複製。

Scylla 叢集可以跨越位於任何地理空間的資料中心。Scylla 中的資料以最終一致的方式在資料中心之間自動同步，無需使用者建立任何型別的流或批處理來確保叢集同步。

4）支援 CQL 事件追蹤（CQL Tracing）

Tracing 是一種 Scylla 工具，旨在幫助除錯和分析伺服器中的內部流程。這種流程的一個例子是 CQL 請求處理。支援概率追蹤和慢查詢日誌。

5）支援物化檢視（MV）和全域性二級索引（GSI）

物化檢視作為 Scylla Open Source 3.0 中的生產就緒功能提供。

在引入物化檢視之前，需要通過不同的 key 查詢相同的資料，唯一方法是使用非規範化 —— 建立兩個完全獨立的表並在應用程式中同步它們。但是，以這種方式確保兩個或多個檢視中資料之間的任何級別的一致性都可能需要重複的程式碼以及複雜而低效的應用程式邏輯。

Scylla 的物化檢視功能將這種複雜性從應用程式移到伺服器中。由於到應用程式的往返次數較少，因此這種實現更快、更可靠。使用物化檢視，Scylla 自動維護單獨表的過程以支援對相同資料的不同查詢，並允許使用標準讀取路徑在每個檢視中快速查詢資料。

Scylla 在物化檢視的基礎上實現了全域性二級索引。

6）支援 Hinted Handoff

當寫入請求傳送到 Scylla 節點時，由於節點上的寫入負載過重、網路問題甚至硬體故障等原因而無響應時，Scylla 實現了 hinted handoff（提示移交）來確保可用性和一致性。

Scylla 為宕機節點儲存了一份寫入副本，並在節點重新啟動時進行重放。當節點宕機時，寫操作流程如下所示：

（1）協調器確定所有的副本節點；

（2）基於複製因子 (RF)，協調器嘗試寫入 RF 節點；

圖片來源於網路

（3）如果一個節點宕機，則確認只會從兩個節點返回：

圖片來源於網路

（4）如果一致性級別不需要來自所有副本的響應，則在這種情況下，協調器 V 將響應客戶端寫入成功。協調器將為丟失的節點編寫並存儲提示：

圖片來源於網路

（5）一旦宕機節點重新出現，協調器將重放該節點的提示。協調器收到寫入確認後，將刪除提示。

圖片來源於網路

7）輕量級事務(LWT)

4.0 特性。Scylla LWT 使用 Paxos 共識演算法提供更強的一致性保證。它們確保分散式資料庫上的請求在稱為 Compare and Set（比較和設定）的過程中以嚴格的線性化（序列）方法進行處理。它們也稱為 Conditional Updates（條件更新），因為它們可以在提交更新之前測試資料庫的現有值。這為單個鍵提供了原子一致性，允許在全域性基礎上按順序執行更新。它們還可用於批處理，以確保在提交批處理更新之前滿足所有條件。

8）支援變更資料捕獲 (CDC)

你可以通過 CDC 來跟蹤對資料庫中的基表所做的變更。對基表所做的更改儲存在可以由標準 CQL 查詢的單獨表中。CDC 通過可配置的生存時間 (TTL) 來確保它不會佔用過多的磁碟空間。

3 如何引入 Scylla

1）什麼樣的專案適合使用

TB 級別及以上大規模資料儲存，在低儲存成本的同時需要保證高效能讀寫
對長尾延遲敏感，可以接受最終一致性
大量寫操作，Scylla 是針對寫優化的系統，更適用於寫多讀少的場景
多地分佈，Scylla 原生支援多資料中心部署，跨資料中心同步，支援機房級容災
資料可以通過一個 Key 進行分割槽，該 Key 允許資料庫在多個節點上均勻分佈

2）什麼樣的專案不適合使用

表有多個訪問路徑，比如需要許多二級索引。
應用程式依賴於具有順序值的行，比如 MySQL 自動增量。
需要支援 ACID，對一致性敏感。
需要支援連線和聚合，Scylla 支援聚合函式，不過會對效能有損耗。
Scylla 不支援鎖，不支援開始/提交事務的語法。
Scylla 更新和刪除都是作為寫入的特殊情況來實現的，不支援原子更新（部分場景也可以使用 LWT，但是對效能有損耗）。

4 Scylla 在 OPPO 的使用現狀

1）專案背景

OPPO 業務使用了大量的 Redis 叢集作為業務層快取，業務部門對 Redis 協議十分了解。所以當 OPPO 在做自研持久型 KV 儲存 Parker 時，很自然選擇了 Redis 協議。隨著越來越多業務的接入，Redis 協議越來越難以支援業務的需求。當時推薦團體在尋求一個儲存系統，期望有以下功能：

TB 級別資料量
寫多讀少，讀 P99 低於 5ms
支援元素聚合運算
支援子 Key 級別過期（區別於 Redis 的 Key 級別過期）
支援跨機房容災

如果在 Parker 的基礎上新開發功能支援業務需求，有以下幾個風險

從 0 到 1 開發，工作量大且風險高，無法滿足業務快速上線的需求
需要擴充套件 Redis 協議支援新功能，而 Redis 協議本來只是為記憶體型 KV 儲存設計的，在上面做過度的修改會遇到很多限制

2）為什麼選擇 Scylla

在前期預研階段，我們放棄了改造 Redis 協議，並通過介面支援、成熟度、可維護性、使用語言、效能多方面對比，最終選擇了 Scylla。選擇 Scylla 可以帶來幾個好處

顯著的儲存成本下降，業務側提供的資料顯示，使用 Scylla 儲存成本可以下降到原來的 70%以上。不過該資料會根據業務形態的不同有所變化。
穩定的 P99 延遲。目前 Scylla 主要用於推薦的演算法特徵，具有寫入量大讀取請求量小的特點，在使用 Scylla 前如何在資料大量寫入時業務的讀取仍能保證穩定的低延遲是個難題。
簡單的運維。Scylla 大部分運維場景都有相應的文件並提供了 nodetool 來管理叢集，只需要根據運維文件的步驟執行即可，大部分運維操作對業務請求影響極小；Scylla 不依賴外部元件，採用 p2p 架構設計，沒有單點問題，大大減少了部署和維護的成本；Scylla 對外只提供了少量的配置，大部分儲存相關的引數會根據業務資料動態調整，大大減少了傳統 LSM 型資料庫調參的成本。

3）Scylla 寬表儲存平臺建設

Scylla 提供了叢集管理端程式，但是開源版本並沒有支援全部的功能，並且限制了叢集的規模。OPPO 自己重新實現了 Scylla 管控臺，支援：

叢集快速申請
節點上下線
叢集擴縮容
機房擴縮容
慢查詢日誌
資料備份還原
叢集銷燬
定時 Repair
叢集監控與告警

目前已經可以通過管控臺對Scylla叢集進行運維管理，並在慢查詢日誌和監控的幫助下協助業務定位不合理的使用，幫助業務更好地使用 Scylla。目前在 OPPO Scylla 的運維仍屬於前期摸索的階段，期待後續能有更多的業務接入，為公司創造更高的價值。

4）Scylla 最佳實踐

在 Scylla 產品化過程中遇到了一些問題，給大家分享一下

Scylla 對記憶體磁碟有一些要求，建議記憶體每個 lcore 16 GB 或 2GB（以較高者為準），磁碟建議使用本地盤 SSD，與記憶體的比例為 30 : 1。
Scylla 會盡可能地多地使用記憶體和 CPU 來提供更高的效能，需要使用 Scylla 提供的監控指標來判斷 Scylla 是否處於高負載。
Scylla 不支援服務端限速，如果寫入過快會導致讀請求延遲增大，遇到這種情況需要業務自行限速或者對叢集進行擴容。
如果寫入速度快於叢集處理速度會觸發 Scylla 限流機制導致寫請求延遲增大，異地多機房同步會加劇這種限流的發生。
SizeTieredCompactionStrategy 與 LeveledCompactionStrategy 進行對比，LeveledCompactionStrategy 讀效能遠高於 SizeTieredCompactionStrategy，但是如果有資料寫入讀延遲更容易受到影響，如果寫入比較頻繁，建議使用 SizeTieredCompactionStrategy
同一個 partition key 下的資料儘可能通過 batch 一次性批量寫入

5）Scylla 在業務的落地

目前Scylla在OPPO主要用於儲存推薦系統的演算法特徵，作為redis hash的低成本替代品。後續會從推薦、IoT、安全等維度持續推進Scylla的落地，敬請期待。

5 總結

Scylla 優異的效能表現主要依賴其抽象出來的非同步 IO 框架 Seastar，這方面網路上已經有很多文章進行了較為全面的介紹，本文不再贅述，感興趣的可以自行去了解。Scylla 的 Shared-nothing 設計和根據業務負載自動調整的特性令人印象深刻，期待越來越多的人可以加入到 Scylla 的探索中。

6 引用

http://www.Scylla.com/product/release-notes/

http://db-engines.com/en/ranking/wide+column+store/all

http://www.Scylla.com/product/technology/

http://www.Scylla.com/scylla-vs-cassandra/

http://university.Scylla.com/courses/scylla-essentials-overview/lessons/high-availability/topic/consistency-level/

http://www.Scylla.com/glossary/high-availability-database/

http://docs.Scylla.com/architecture/anti-entropy/hinted-handoff/

http://www.Scylla.com/open-source-nosql-database/4-x/

http://www.Scylla.com/open-source-nosql-database/3-x/

http://blog.pythian.com/cassandra-use-cases/

http://docs.scylladb.com/getting-started/system-requirements/

http://mp.weixin.qq.com/s/IXQE-hVIqOghkFsjvuiFNg

作者簡介

Morning Li OPPO 雲端計算中心高階後端工程師

負責中介軟體 KV 儲存的研發與維護

「其他文章」