編者按：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”。