編者按：NoSQL發展到今天雖然在技術和生態上已經非常成熟,但是并沒有停止演化,尤其是在一切都容器化、微服務化的大配景下,很多NoSQL產品也在擁抱Docker,在硬件和系統技術棧上,新技術也是層出不窮,如用戶態TCP/IP協議棧、DPDK、RDMA等,這些技術和NoSQL結合之后會擦出哪些火花呢?本文就容器化的典型例子AeroSpike和技術全面領先的ScyllaDB做大概介紹.

在新技術層出不窮的配景下,NoSQL也在努力求變,今年大會有幾個新的演變方向,分別是：

容器化：將NoSQL產品與Docker相結合,然后收獲容器的諸多益處如運維簡單、開發更加規范、封裝和隔離更為徹底,其中的主要難點是容器更適合stateless的服務,而NoSQL是帶數據的,如何做到stateless是個很大的挑戰,而且NoSQL對時延的要求很高,容器帶來的損耗也是必要考慮的一個問題.

軟硬一體優化：將 網卡->CPU->TCP/IP->工作線程->文件系統->IO存儲 這一整條鏈路的每個環節都做極致的優化,該優化的大配景是NoSQL每次操作都是500us-1ms級別,但是用于業務數據處理的時間可能只有10us左右,整個鏈路的成本已經遠遠超過了數據處理的成本,所以下一步的優化的方向只能從鏈路著手,在網卡層面利用RDMA技術,在CPU層面采用多核+線程親和性+NUMA等特性,在TCP/IP層面采用DPDK+用戶態協議棧技術,在工作線程層面采用shared nothing的無鎖架構,在文件系統層面采用一些比較新的文件系統如XFS,有的NoSQL產品甚至bypass了文件系統,直接操作設備,存儲方面采用NVME或者SSD.

云化：本身不再持有很重的IDC資產,直接根據客戶需求在云上靈活部署和彈性伸縮,輕資產的模式讓本身專注于技術和業務創新.

NewSQL化：開始關注ACID、CAP,不斷向傳統數據庫的特性靠攏,與傳統數據庫之間的共同點也會越來越多,究竟大家面臨的分布式問題都是一致的.

AeroSpike作為高性能的NoSQL服務,已經有近3年的歷史.NoSQL領域產品眾多、濫觴成河,AeroSpike絕對算其中一朵奇葩,在很久之前就進行了很多前沿性的探索,比如在存儲上采用混合架構,采用RAM+SSD的架構,其中索引存儲在RAM中,數據存儲在SSD中,并且是直接拜訪SSD,bypass了文件系統,然后又針對多核處理器的體系架構特點做了優化,因此能帶來性能的極致優化,聲稱比友商高出10倍以上(當然我沒有親測過:-),而且在很久之前AeroSpike就實現了集群的分片、自動負載均衡、多數據中心同步等高級功能,這是目前很多NoSQL產品還在努力struggle的特性.

AeroSpike容器化遇到的挑戰有：

1,數據冗余：要求至少大于1個副本,容器允許隨時失效

2,數據庫集群的自治與服務發現：允許容器節點隨時加入和退出

3,數據庫自我修復：允許容器節點隨時加入和退出

4,應用層感知數據庫集群：必要有個服務發現機制

5,對原有架構挑戰：原來基于物理機的架構都需要調整,不止是簡單的換個皮罷了,從復雜度、可維護性、持久化、一致性、可擴展性、成本、性能等維度都面臨著新的挑戰；原有的部署和運維架構也受到沖擊；原有的很多優化方法也受到容器的挑戰；

6,哲學層面：容器是被設計來用于辦理封裝、隔離、部署問題的,數據庫是被設計用于持久化、可擴展、自治自修復的,這兩種設計如何match到一起也是個挑戰

針對上述挑戰,AeroSpike的解法是：

1,數據冗余：數據是多副本的,而且副本數量可以配置

2,集群自治與服務發現：集群所有節點share nothing,都是對等的,采用Docker Swarm方案

3,數據庫自我修復和負載均衡：采用hash分片,而且設計了RIPEMD-160算法來保證高效的分片

4,應用層感知數據庫集群：采用Smart Client來做集群的自動感知

5,對原有架構挑戰：主要是對數據如何存放的挑戰,數據和容器放在一起雖然也能保證隨時加入和退出,但是不如把數據徹底剝離到宿主機或者云上的共享存儲如EBS中更優雅,而且更近一步是否可以剝離出單獨的一種容器叫做Data Container,只用來管理數據,策略可以做得更復雜,比如在銷毀的時候可以做一部分業務邏輯在里面.還有一個更大的挑戰是性能問題,在本次介紹中主講人并沒有給出徹底的辦理方案,應該是還在優化中

6,哲學層面：總結一下還是數據庫去適應容器的特點,把數據庫做成了一個無狀態、可隨時加入退出、能夠做到自組織自發現自修復的系統,使數據庫表示起來也像個“容器”

最后AeroSpike列出了容器化帶來的收益,好比：開發和生產環境能更統一,運維更加簡單,scale up和scale down做起來比之前更容易一些,等等.

接下來ScyllaDB的CTO分享了ScyllaDB在極致性能優化上的實踐和經驗總結,ScyllaDB是一個兼容Cassandra協議的分布式NoSQL數據庫,在相同的硬件條件下能比原始版本的Cassandra性能提升10倍左右,使用C++14編寫,純異步,整個編程框架是Seastar,可以理解ScyllaDB是在Seastar框架基礎上的Cassandra協議實現.

ScyllaDB設計理念/High levels是：

1,更有效率：相同時間內干更多的事情

2,釋放整機能力：榨干整機每個部件的能力

3,更可控：控制何時何處使用計算能力

面臨的問題是：

1,太多的微操作：盡量讓協同本錢變得更低

2,太多通信行為：本機內、與其他機器、與disk通信

而且在計算機的最底層便是一個異步的架構,如Intel CPU的流水和指令執行過程便是一個異步過程,在有了上述抽象之后ScyllaDB的設計架構為：

1,每個CPU Core都有一個綁定的線程,可以做到永遠不會阻塞

2,網絡操作是異步的

3,文件I/O是異步的

4,每個核上都是異步的

在傳統的架構中,系統中有多個線程,每個線程都有自己的堆棧和上下文,線程切換造成的開銷和CPU cacheline的污染非常嚴重,在微操作頻繁的NoSQL數據庫中,這部分切換帶來的開銷其實是非常大的,Seastar框架是每個core一個native thread,然后每個thread中用Task和Promise來抽象工作任務,Task是一個c++ lambda表達式,promise是用來保留計算結果的指針.

在做性能優化時有一個基本的公式是：

Concurrency = Throughput*Latency

這么看起來不大好理解,但是變形之后就比擬好理解了,如：

Throughput = Concurrency/Latency 所以當追求吞吐量時,在必定延遲下需要并發盡量大

Latency = Concurrency/Throughput 所以當追求延遲時,在必定的吞吐下需要并發度盡量低

為了壓榨機器的性能,我們一般要求機器的每個資源能夠有很好的并行性

在做資源調度時,Seastar拋棄了操作系統的各種調度器,改由本身全面接管,比如當做I/O時,Seastar禁用了Linux的I/O調度器,在Seastar看來系統調度器只能看到產生I/O的線程的優先級,無法看到整體的優先級,而且系統調度器會有很多額外的reorder和merge操作,而且Seastar的I/O調度器還能感知到一個最佳的并行度,當并行度增加但是吞吐并不同比增加時沒有必要再增加并發.對于文件的緩存直接復用Linux的page cache,因為做得已經足夠好.下圖是ScyllaDB中的調度模型：

Seastar對內存分配也做了很多優化,主體思想就是將必要的內存提前分配出來,盡量不要走到系統的malloc/free,為了降低碎片也做了很多分配策略.

最終提到了對于RDMA+DPDK+User Space TCP/IP的使用,這也是一個很大課題,以后另開文章詳細剖解,主講人認為目前還不夠成熟,最好不要用于生產環境,另外ScyllaDB還從query編譯優化(將查詢直接編譯成代碼)等角度做了優化.

從上述這兩個例子中我們大概勾勒出一個未來的NoSQL產品大體是這個樣子的：

1,集群化,多副本,每個副本可以隨時失效,可彈性伸縮,節點可以隨時加入和退出

2,可以與容器完美結合,降低開發、部署、運維本錢

3,將在內核態的計算完全轉移到用戶態并做極致優化,如對傳統線程的lambda抽象、自主可控的調度器、bypass文件系統直接操作裸設備、使用用戶態協議棧來大幅削減網絡鏈路本錢等

4,在功能上逐步向傳統數據庫看齊,如支持事務、支持ACID等特性,催生出NewSQL

5,能夠便利云化以觸達客戶

這個世界變化太快,一不小心就會被狠狠擯棄,是每一個碼農的幸運也是不幸,痛并快樂著,引用主講人的最后一句話“While having a lot of fun”.