標籤：

如何評價360開源的pika項目？

01-01

碼畜一隻~之前一直在用redis，現在內存越用越大，想轉redis cluster怕成本太高，最近老大讓調研一下，排除那些近一年都沒有commit和issue的，現在只剩下ssdb和360開源的pika，我看github上兩邊項目都有更新，不過具體性能和社區怎麼樣就不知道了，有哪位用過的或者了解的前輩幫忙回答下?

作為 Qihoo360/pika 團隊的主要負責人 我還是來回答一下這個問題

Pika 主要的定位目標並不是取代redis, 而是redis 的一個補充. 是在使用redis 容量過大的場景下面的一個解決方案.

Pika 目前在360 公司內部有1200+ 的實例在運行, 公司目前的大部分業務80%以上業務都在使用, 無線瀏覽器, 花椒, 雲盤, 信息流等等, 在公司外部也有大量的使用, 具體可以看 user list: Qihoo360/pika 當然這只是一部分的使用用戶.

至於對比ssdb. Pika 從性能和運維上都比它更有優勢一些, 目前在360公司內部, 業務方已經把所有ssdb 實例都遷移到pika ^-^. 在 Pika 的用戶群裡面有挺多從 ssdb 遷移到 Pika 的案例.

至於我自己作為一個碼農, 我最關心的還是代碼質量, 這個大家可以打開開源項目, 看一下裡面具體的代碼就知道了. 我們對代碼質量的要求還是很高的.

然後就是pika 就像 @姚維 說的, 我們這個團隊對 rocksdb 還是了解很深入的, 還有就是Pika 從上到下都是我們自己實現的, 所以出現問題我們也排查的很快.

最好還是廣告一下: 我們是360 基礎架構組, 一直在招人, 團隊還有 Qihoo360/zeppelin Qihoo360/floyd 等等這些開源項目. 感興趣想加入我們的私信就行.

開發

我是17年7月畢業之後來正式參與Pika項目的, 大四在學校的時候偶然的機會看到Pika項目，在issue上看到了幾個TODO, 寫完了之後提了PR, 其中支持Redis協議GEO的部分提交之後, 整個PR幾百行, 社區的開發者還是幫我認真了review了代碼最後merge了. 整個社區還是很活躍的, 因為大部分都是國內用戶, 有什麼問題就直接和開發者在QQ群里交流.後來就一直關注這個項目，提交代碼. 整個過程還是有很多收穫的，幫助我從一個很小的部分切入之後真正的參與了開源項目. 在和團隊遠程依靠Github結對編程幾個月之後，我就加入了Pika.

開源

因為是全職做開源, 工作的及時反饋感還是非常強烈的,畢竟有人給你付工資讓你做開源。Pika也不屬於玩票性質或者完全為了KPI而生的項目,整個項目兩年來從沒有間斷開發, 目前也有很多用戶在使用，在QQ群和Github還是有大量用戶反饋.

如果有同學想參與進來，特別是在還在上學的同學希望參與開源項目,可以看我們的Github上的issues，有一些TODO歡迎大家參與進來, 假如有想參與某個feature但無從下手的同學甚至可以郵件我.

AQ

使用

具體使用還是建議在自己的環境上進行完整的測試

編譯

這是所有C++項目的歷史包袱，我們也在竭力解決

多數據結構

用了鎖，具體實現可以看代碼

Benchmark

多線程是Pika的優勢

pika是前同事寫的。基於rocksdb上面兼容了redis的協議，ssdb 是基於 leveldb，rocksdb對於 leveldb 有很多的改進。並且 pika 團隊的人對於 rocksdb 玩的還是挺溜的。pika 在360跟很多公司應該都已經用的很歡了。

所以推薦你看看。

上面亂噴的受不了了。。

針對上面各種質疑

使用rocksdb實現redis數據結構複雜度高是必然，但是大部分時間複雜度是和redis一致的，當然速度要慢，O(N)對於磁碟和內存，差距肯定存在。

當然你覺得你可以做得更好show me you code

有人提到20個worker，rocksdb都是磁碟操作，block的api，不使用多線程你寫一個看看？畢竟redis數據操作全內存，單個io線程完成大部分的事情

page cache + block cache + ssd為rocksdb提供了可以滿足海量數據讀寫的需求，有多少人redis tps維持10w/s的？當然如果你的redis集群沒有超過50g(舉個例子)建議就不要考慮遷移到基於磁碟的存儲上。

pika或者類似的產品不是萬金油，需要放在合適的場景上，很多人其實接觸不到上百G的redis集群根本不能理解這種方案的存在的意義。

pika並不完美，集群，穩定性，api兼容程度，但是希望他們能走的更遠。雖然我是個360黑，但是對pika團隊真的很敬佩，我記得我在研究rocksdb時候看到過他們成員寫的博客，真的很棒，可以說是國內研究資料中最深入的了。

利益相關:

本人與pika無交集，非pika使用者，長期潛水pika用戶群。

研究過pika和nemo

深入研究過ssdb

聽同事說知乎有關於pika的問題，不怎麼玩知乎的我也忍不住上來答兩句，畢竟參與了pika從無到有，直至如今的全部開發過程，雖距完美二字相差甚遠，但對其還是有很多感情在裡面。

利益相關：pika開發人員， 本人github賬號、博客地址

pika最早其實是個寫著玩的項目，當時領導@陳宗志 讓我基於rocksdb封裝一個支持多數據結構的庫nemo，我完成了簡單的幾個hash介面支持，就嘗試參考著陳宗志同學Github上一個自己寫著玩的名叫pika的c++ server代碼，連名字都沒改，在nemo上包一層網路邏輯，實現redis協議解析，寫成服務。剛開始寫沒多久，得知pika正式立項，與DBA組一起合作，我們開發，他們運維。隨後就是nemo和pika的緊張開發階段，最開始就我自己寫，畢竟也沒什麼經驗，踩了無數坑，後來和安安同學一起，在15年第四季度基情擼碼，終於在DBA同事的給力配合下，pika1.0版本年底在公司內部順利上線。

有了線上基本可用的版本之後，16年初，pika加入了更多的開發同事（康神，店長，葯匣子...）我們開始著手對1.0版本進行優化，好一頓折騰後，索性直接跳到2.0版本並且在Github上開源（原諒我們這麼簡單粗暴的版本跳躍...），建立了pika技術交流群（QQ群號: 294254078），然後就有了pika社區後來發生的一切，在社區許多同學的熱情pr、issue下，pika不斷成長，十幾個版本的迭代優化，fix，如今到了版本2.2.6。

回憶殺結束，現在基於前面的回答，我簡單總結和回復下：

  1. 首先匿名噴子和那些用都沒用直接上來強行裝逼人，忽略，借用 @Timothy Zhang 的回答：「你覺得你可以做得更好show me you code」
  2. pika的定位不是為了取代redis（也做不到，畢竟一個內存，一個磁碟），只是作為一個補充，對在數據量巨大（相對內存而言）的場景下仍想使用redis的人，提供一種選擇，所以我們對redis近百個命令進行了實現，雖然用kv介面封裝list的做法顯得很「蠢」，性能較內存list也不夠高（類似pika的一些同類開源項目在這裡乾脆選擇不做list，直接做成array或者queue），但畢竟與redis介面兼容，給合適的用戶從redis遷移到pika降低成本
  3. pika雖然在不斷進步，但直到今天，仍然有不少缺點：
  • nemo實現的比較早，一些實現邏輯和代碼今天看來有些不合理，有想通過閱讀nemo代碼學習c++編程的人可以暫時停了，我這有更好的代碼給你參考，除了leveldb、rocksdb這些明星項目，我們組內自己實現的c++ 網路庫pink和raft實現floyd也都是不錯的選擇，後續我們會對nemo進行重構，優化更多實現和多數據結構的性能
  • pika距2.0版本也差不多1年半了，同樣無論代碼和個別邏輯現在看來都有一些瑕疵，但目前穩定的情況下，我們暫時先以新功能開發為主，後續同樣會進行優化改進，感興趣的同學可以看看代碼，歡迎pr
  • 等等等等

缺點說了，稍稍誇幾句，也給猶豫題主和其他同學寬寬心，pika在我們公司內部已經上線1000多個實例，已將公司內部其他同類競品全部替換，支持N多業務線，整體日訪問量近千億。另外，身為一線pika開發和bugfix人員的我，表示已經很久沒有收到DBA同事反饋的線上問題，所以不用擔心太多，先用用試試呢？不過個人建議在上線前最好根據你們的實際使用場景進行詳細測試，我們的線上pika沒問題也不能代表它100%適合你^^，測試有什麼問題歡迎issue反饋

最後，還是要感謝pika這個項目，讓我在開發的同時得到技能的成長並找到了自己的興趣點：存儲引擎，看了包括rocksdb、leveldb、kyotocabinet、lmdb等在內的許多引擎源碼，收穫很大，將部分內容整理寫在博客中，也歡迎大家批評、交流。

好了，說了這麼多，自己在知乎的處女回答也差不多結束了。

PS：我們組內還有許多其他好的項目，如海量分散式存儲zeppelin等等，歡迎感興趣的同事加入我們，一起搞事情。簡歷發：chenzongzhi@360.cn

關注這個項目很久了，說一下問題

  1. 代碼質量堪憂，冗餘度很大，想重構或者加點功能都無從下手
  2. 不支持超大的元素集，list或者zset的時間複雜度是O(N)的，曾經測過50K的list，lindex中間的元素會把整個線程卡4s
  3. 官方的benchmark拿開了20個worker線程的pika和redis做對比，有點尷尬
  4. 依賴一堆庫，編譯相當麻煩
  5. 線上經常出問題

總結下，業務小就不要碰了，在數據量很大，而且冷熱數據區分明顯的場景下可以試著用下，前提是團隊里要有能hold這個項目的人

==============

補充一下

  1. 我自己實現了O(logN)的list，代碼就不放了免得被人肉，我覺得實現並不難，在線上跑到成熟期的目前可能只有pika和ssdb @Timothy Zhang @宋昭
  2. 多線程的意思是說pika性能不如redis，所以官方放那個benchmark的結論有點不合適？

    ```Pika 的單線程的性能肯定不如 Redis，Pika 是多線程的結構，因此在線程數比較多的情況下，某些數據結構的性能可以優於 Redis。```
  3. 我們公司確實上了一些pika，出了一些事情，使用的場景不一樣，難免會遇到一些不一樣的問題
  4. 我也是在客觀的回答這個問題，亂噴倒不至於把，最後pika是個大公司的開源項目，也是為社區做貢獻，希望pika越來越好

線上三個場景在使用，供你參考：

  1. 用來緩存storm job加工後的大量中間數據。
  2. 存儲一些導購短文，讀操作為主。
  3. 聚合信息的只讀展示，用於取代堆外緩存。

場景1,2運行的比較平穩。3在測試中，超過50k的key查詢略慢。

場景2生產環境訪問量qps 5000

場景3生產環境峰值訪問量qps 30萬

Pika的社區經營、推廣我覺得都是做得不錯的，在360公司層面得到的支持也比較大，另外Pika團隊對於Rocksdb的研究也相當深入。這些都是值得學習和致敬的地方。

不過，可能是由於歷史原因吧，Pika存在著一些不可忽視的缺點，我們大概一年前實際調研pika時，發現它存在一些問題，以下列舉幾點，希望它能不斷完善吧。

  1. API層(nemo)的代碼質量較差，API的原子性保證、並發性存在問題。
  2. 數據存儲格式設計得比較粗糙。 比如每個key佔用的空間固定為256位元組，比較浪費。另外由於存儲格式的設計問題，一些功能的實現需要在Rocksdb層面做改造來實現。
  3. 對Rocksdb的代碼進行了改造，侵入較大，如果官方Rocksdb有bug或者需要對Rocksdb做升級，會比較麻煩。
  4. 與Redis API的兼容性問題，很多細節行為與Redis存在差異。這對於從原生Redis遷移而來的業務是很不利的，很容易因為API行為改變而掉坑裡了。

順帶廣告下，我們團隊也剛開源了一個類redis存儲swapdb(JRHZRD/swapdb)，前面 @Timothy Zhang也是核心開發者之一。該存儲主要實現了KV數據在內存與SSD中的混合存儲及數據交換，項目目標是在保證緩存訪問性能的前提下，大幅度降低緩存系統內存使用量和機器成本(當前主流DDR3內存和主流SATA SSD的單位成本價格差距大概在20倍左右)。預計可以將緩存機器總成本降低幾倍以上。

省錢

如果不是使用強一致性協議，那麼用rocksdb的keyvalue基礎上建立的list，map，zset等結構是不可靠（亂序，大小，值不一致都可能）。而且也沒有對帳服務，建議學習一下就好，不建議線上用。

去看一下360的發家史，看看有多少流氓事件。

每一家「公司」有每一家「公司」的「基因」。

當然不能一杆子打翻一船人，其中許多員工都是優秀傑出的，但這與「公司」表現出的行為，沒有任何關係。

就好像南京大屠殺時，日本本土的醫院裡，醫生一樣兢兢業業地在給日本老百姓看病，護士一樣在給日本產婦接生，生下來的日本寶寶當然很可愛。

但又怎麼樣？不會影響日軍的侵略行為。

評價一個軟體，當然要看事實，看數據，不能扣帽子。

是不是願意花時間去評估？

每個人都有自己不同的看法。

每一款開源軟體，向來都是有許多替代品的。

公司內部應用並不多 GitHub fork stars刷的太水 本身亮點很少

推薦閱讀：

※scrapy-redis 和 scrapy 有什麼區別？
※隊列是什麼意思？

TAG:資料庫 | Redis | NoSQL | 開源 |