為什麼建立比Redis更快的KeyDB？就是玩兒！ - Sully

banq發表於2021-04-28
Redis

離開微軟後，我想開始一些新的事情。一個想法是搜尋引擎，您可以在其中使用正規表示式來搜尋我使用Redis構建的Internet。但是，我不明白為什麼它只使用我的八個CPU核心之一。我很生氣，因為它只使用了機器的一小部分，所以我花了一個月的時間新增多執行緒，然後寫了一篇部落格文章說：Redis應該是多執行緒的”。
我對該帖子的反饋感到非常驚訝。在Hacker News上反應很大，但是Redis認為那太複雜了。
我的想法僅僅是，如果他們不這樣做，那我們就可以做到。因此，我們做到了–我們將KeyDB設定為我​​們認為應該擁有的資料庫。
當時我們並不想成立一家資料庫公司，這只是一個興趣產物。但是各方面反應的確讓我們感到驚訝。我認為在這裡有很大的需求，而Redis出於某種原因決定不提供服務。如果他們不會，那麼我們會。
以這種方式開始提出了一些挑戰。投資者真的不知道該如何看待我們。投資方YC在這次面談中的主要關注點是我們是否真正在構建與Redis不同的東西。我很感激他們和我們抓住了機會。
Redis是一個很好的基礎，它的創始人Salvatore Sanfilippo在構建它方面做得非常出色，但是我們希望將其帶往另一個方向。他想要簡單性，我們卻想要效能。
Redis通常用作快取，因此我們認為專注於效能是最有意義的。Redis隨後使用I / O執行緒稍微改變了方向，但是我們在KeyDB上的方法獲得了更好的效能。
我們還花費大量時間來確保我們始終與Redis相容。例如，Redis具有一定的一致性保證：如果執行此查詢，則將得到此結果。這對使用者來說很重要，因為他們不想切換到其他資料庫，那會遇到只在某些時間出現的細微錯誤。
隨著我們做更多的工作來改善多執行緒的能力，例如我們已經完成了從全域性鎖轉向非同步的工作，我們將保持這種相容性。我們絕不會（出於效能的考慮）放鬆這些保證，我們始終保持這種相容性。
我們使用的是現代C ++，而不是舊的C ++ 98，這是一種不好的語言，而現代C ++很好，因為它是C的超集，而Redis仍然是C。如果我們需要從中繼承任何程式碼，我們仍然可以這樣做，但是其中具有額外的功能也很不錯。
當您想跨不同的CPU核擴充套件時，由於全域性鎖定，瓶頸開始蔓延。我們一直在進行更多的無鎖程式設計，以嘗試改善這種情況。
在技​​術層面上這是非常困難的，但是最具挑戰性的事情實際上是在業務方面。但是當您開始為此收費時，期望值就會上升。作為一個開源專案，您可以相當成功，但是，如果您想開始嘗試出售產品，則需要更加有條理。那是一個很大的學習曲線。
效能測試方面：您可以並行或一次傳送多個命令。如果使用這種方法，Redis可以得到相當不錯的數字，問題在於，大多數客戶應用程式的工作方式並非如此。在大多數情況下，傳送查詢會等待結果，然後進行一些處理，然後可能會傳送另一個查詢。我們總是以這種方式進行測試。
開源KeyDB是Redis的多執行緒高效能分支，KeyDB開源號稱是世界上最快的記憶體資料庫，當然比Redis更快。
 

駭客新聞網友討論
真正的問題是Redis Cluster協議，該協議將所有智慧裝置推送到客戶端。這意味著每個客戶端實現的行為都不同，失敗也不同。我鼓勵Redis使用者使用Envoy代理作為Redis客戶端（即使用vanilla客戶端，並使用Envoy作為叢集客戶端）。您將獲得Redis Cluster的所有HA和實用性，但是麻煩就少了。另外，強烈鼓勵人們看看Elasticache，它也真的很好。
 
大約9年前，我分叉Redis建立了Thredis。有關如何實施的一些說明：

https://github.com/grisha/thredis/blob/master/README-THREDIS
然後，我向其中新增了SQLite，更多詳細資訊在這裡：http://thredis.org，儘管我確實在一個實際的專案中使用了一段時間，但大部分都是為了玩兒。
 
出於某些相同的原因，我們編寫了Redis的Erlang版本（https://github.com/cbd/edis）-多執行緒以有趣的方式更改了某些縮放語義。它主要是為了娛樂，但最終以一些簡單的REDIS協議實現前端出現在一些實際專案中，在後端可以用實現者想要的任何東西代替後端。
 
我們團隊中的某個人對KeyDB進行了研究，對於我們的工作量（每個查詢很多MGET），它並沒有比Redis好得多。但是，我們仍然可以繼續使用它，因為我們的GCP Memorystore例項幾乎始終處於100％CPU的狀態。我們尚未評估Redis6。

雖然KeyDB是多執行緒，但是我們可以以叢集方式在每個核心上執行的一個Redis呢？在8核CPU上執行8個Redis？以您有9個節點的Redis叢集的場景為例：使用KeyDB，您可以透過3個執行緒將其縮減到3個節點，同時獲得相同的吞吐量。這減少了維護負擔，同時還減少了等待時間。如果使用Redis叢集，每次訪問單獨的分片時，連線到不同的群集伺服器都會產生開銷。KeyDB提供更好的優點是：可以完全避免群集。對於許多人來說，這是KeyDB的最大贏家。
 
這是否意味著在單核或低端環境中，最好使用Redis。我認為消除多核複雜性將是有益的。目前，單執行緒KeyDB的速度要慢幾個百分點。
 
KeyDB以“ DB”這樣的名稱來表示它可能支援永續性，KeyDB具有FLASH功能，可為我們提供基礎永續性，您不再需要RDB或AOF。KeyDB的長期目標是讓您在一個資料庫中的記憶體和磁碟之間平衡資料集。將來，我認為快取將只是功能更全的資料庫的功能，而這正是我們使用KeyDB的方向。
 



 

相關文章