如何評價 ScyllaDB？

01-15

號稱用c++開發的cassandra的替代品，10倍於cassandra的性能。
開發人員背景很屌，是做kvm的那幫人。

scylladb 性能比cassandra有大幅提高得益於幾個方面：1）基於poll-mode 的網卡驅動實現了用戶態TCP/IP協議棧（使得協議棧處理能力隨著CPU數量線性擴展，Zero-Copy)；2）開發團隊具有豐富的開發底層軟體經驗(KVM團隊），並將這些經驗應用於資料庫軟體領域。

隨著硬體的發展，scylladb 使用硬體的方式將會得到更多的關注。

scylladb底層框架為seastar, 實現了一個高性能的非同步編程框架，實現了用戶態協議棧，實現了用戶態IO調度器。代碼可讀性好，注釋全面，可以作為C++愛好者學習的典範。

[硬廣時間]

在消耗了幾十個周末，閱讀分析seastar框架。然後用該框架實現了一個兼容redis協議的應用，名字叫做pedis。簡單壓測結果表明：在8核CPU，千兆單網卡的情況下，使用內核協議棧的情況下，pedis可以跑出100萬的QPS，平均RT 不到1ms。在打開用戶態TCP協議棧的情況下，同樣配置，QPS幾乎翻倍。

項目地址是：GitHub - fastio/pedis: NoSQL data store using the SEASTAR framework, compatible with Redis

這算是硬廣嗎~

基於dpdk實現了一個TCP協議棧, 把協議棧放在用戶態, 極大的減少了系統調用消耗. 網路性能提高10倍以上......

只想說, 開掛了

最近在使用scylla；其實默認情況下是不開dpdk，而且10倍於cassandra也是沒有啟動dpdk模式；最為開掛的是把event-driver做到了用戶態，就算什麼都不做它也會跑滿所有的cpu和內存，當然這是可以設置的；我經驗比較少，但是我leader說這可能是一個趨勢，因為普通的網路庫在10G或者更加高的網路帶寬下都跑不滿....用scylla本身，對它的寫的性能真的佩服五體投地，當然現在的beta各種不穩定，寫幾天掛幾天的感覺;

到底和語言有沒有關係呢，我覺得還是有的，起碼現在各種內存crash就超級符合C++的特性;

剛參加了QConSF會議，聽了它CTO的報告。

ScyllaDB是一個兼容Cassandra的NoSQL系統，它兼容Cassandra的數據模型和客戶端協議，可以直接替換Cassandra系統。ScyllaDB的買點是它的實現性能優化到非常極致，這篇報告是本次會議給我留下最深刻印象的一個，在相同硬體上，它的性能是Cassandra的10多倍（3台ScyllaDB可以提供30台Cassandra集群的吞吐量，而且響應延時更低），非常牛。後來一查，做報告的ScyllaDB的CTO兼創始人Avi Kivity原來是大名鼎鼎的KVM的作者，可以看這篇報道：http://t.cn/RvbcUsa。

優化目標：

? Efficiency：Make the most out of every cycle

? Utilization: Squeeze every cycle from the machine

? Control: Spend the cycles on what we want, when we want

這三條可以看出對高性能系統性能目標具有非凡的洞見。

Asynchrony, Everywhere：

? 每個core一個線程：線程不阻塞

? 非同步網路IO

? 非同步文件IO

? 非同步多核

線程和線程之間通過消息通訊，沒有內存的共享，沒有互斥鎖，也沒有原子操作。

基本的性能公式是：

Concurrency=Throughput * Latency

IO調度器

關閉了linux的IO scheduler，因為它是以線程為單位的，而ScyllaDB只有幾個線程。在用戶層實現了一個scheduler，給用戶請求和後台任務不同的優先順序，同時保證磁碟的並發度。磁碟的最佳並發度是如何獲得的呢？在系統安裝的時候，會自動運行一個benchmark，通過增加並發度找到吞吐量變的平緩的點。

Cache的設計

為什麼不使用內核的page cache？

? 只能以4K為粒度

? 線程安全的，對於ScyllaDB無鎖的架構是不必要的

? 同步的API：read, write, mmap

? 缺少直接控制cache的API

ScyllaDB採用自己實現的cache，並且不區分key cache, row cache, page cache等，而使用一個統一的cache。這樣的統一cache免去了調優cache的負擔。

Self tuning特性

和Cassandra一樣，ScyllaDB也是LSM-Tree的存儲數據結構。做OceanBase的都知道，調節compaction, 寫入速度（寫入太快需要把memtable存入磁碟），讀取之間的IO爭搶是一個很難的問題。ScyllaDB實現了一種自適應的調度策略應對這個問題。如上圖所示，對於CPU，SSD，網路資源都需要通過它的調度器。這個調度器結合當前寫入memtable的速度，compaction的需求，動態調節後台任務和讀寫請求的優先順序。

內存分配器

同樣，thread-per-core的設計，使得它不需要使用系統的內存分配器而是使用了自己實現的內存分配器，因為沒有線程安全的問題。另外，當內存不足的時候，需要從cache中擠占內存，和OceanBase一樣。即使如此，頻繁擠佔cache的內存還是容易造成內存碎片的問題，為此，他們做了一種專門分配器：

? cache中分配的對象類型很少

? 對於cache分配的內存，記錄分配的類型和引用位置

? 分配器可以在需要的時候移動內存塊，更新引用位置（權衡！）

用戶態TCP/IP協議（進行中）

理由還是一樣，因為thread-per-core的設計，內核龐大的TCP/IP協議棧的實現涉及大量的隊列和鎖的操作。他們使用DPDK直接驅動硬體，實現了自己的用戶態TCP/IP協議。

查詢處理（進行中）

? 使用LLVM-JIT編譯執行CQL(Cassandra Query Language)

? 在查詢中遷入schema信息和內部對象布局（行索引等）信息，避免執行過程中訪問schema

和OceanBase做的一樣！

隨想

ScyllaDB代碼開源，值得仔細研究一下。http://t.cn/Ryis2gB。

現在的穩定性還是坑

看好它在網路數據面帶來的好處. 旁路掉了內核厚重的協議棧實現, 用DPDK做二層轉發就能看出來, 這對於數據轉發麵的提升是巨大的, 現在有了用戶態協議棧, 連接跟蹤與狀態防火牆是不是也可以不再依賴內核了?

其實這根Java和資料庫沒什麼關係優化點也不該歸類在資料庫領域

在 io 不是瓶頸的時候，語言及演算法的優勢得到了很好的體現。