KeyDB：使用 Multithreading 改善 Redis 的效能
source link: https://blog.gslin.org/archives/2023/05/22/11196/keydb%ef%bc%9a%e4%bd%bf%e7%94%a8-multithreading-%e6%94%b9%e5%96%84-redis-%e7%9a%84%e6%95%88%e8%83%bd/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
KeyDB：使用 Multithreading 改善 Redis 的效能
在 Hacker News 上看到有支援 Multithreading 的 Redis fork：「KeyDB – A Multithreaded Fork of Redis (keydb.dev)」，官網在「KeyDB - The Faster Redis Alternative」這邊。
不過這篇是要記錄從 Hacker News 看到的雷點，這樣以後自己再找資料的時候會比較容找到。
36022425 這篇是跳下去用發現不太行，最後在 application 端實作需要的 feature，後端還是用原廠的 Redis：
To counter what the other active business said, we tried using KeyDB for about 6 months and every fear you concern you stated came true. Numerous outages, obscure bugs, etc. Its not that the devs aren’t good, its just a complex problem and they went wide with a variety of enhancements. We changed client architecture to work better with tradition Redis. Combined with with recent Redis updates, its rock solid and back to being an after-thought rather than a pain point. Its only worth the high price if it solves problems without creating worse ones. I wish those guys luck but I wont try it again anytime soon.
* its been around 2 years since our last use as a paying customer. YMMV.
另外是在專案裡搜尋「is:open is:issue label:"Priority 1"」的結果可以看到不太妙，在 36021108 這邊有提到的問題：
Filed July, eventually marked priority 1 in early December, not a single comment or signs of fix on it since. That doesn't look good at all.
然後 36020184 有提到 Snap 買進去後沒有什麼在管 open source project 的部分了：
I think I'll stay far away from this thing anyway. Numerous show-stopper bug reports open and there hasn't been a substantial commit on the main branch in at least a few weeks, and possibly months. I'll be surprised if Snap is actually paying anybody to work on this.
Related
在 Hacker News 上看到幾個 Key-Value Store 軟體
在 Hacker News 上看到「Redis vs. KeyDB vs. Dragonfly vs. Skytable」這篇，裡面介紹了四套 key-value store 軟體： Redis：這個應該不太需要介紹... KeyDB：Snapchat 搞出來的 Redis clone，主要的賣點是 multi-threading。 Dragonfly：宣稱地球上最快，但作者跑不出來，下面的討論有人提到 Dragonfly 在更多的 CPU 資源效能就會更好。 Skytable：作者測出來最快的。 裡面看起來都蠻有趣的，可以追起來看看發展的情況，但如果真的要的用的話，應該還是先以 Redis 為主，穩定度以及功能還是重點...
June 19, 2022In "Computer"
Memcached 與 Redis 的比較
在「Memcached vs Redis - More Different Than You Would Expect」這邊看到對 Memcached 與 Redis 的分析。 這兩套軟體都很常被拿來用作 cache 機制，所以一般來說比較時就是比兩邊都有的東西 (如果你要 pub-sub 之類的東西，在這兩套裡面只有 Redis 有)。 最前面還是先講了對使用者 (開發者) 的差異，很明顯的是 Redis 對各種不同的資聊結構都有支援，這點可以從 Redis 被官方被稱作 Data Structures Server 就可以知道 (在「An introduction to Redis data types and abstractions」這篇可以看到)，而 Memcached 只支援了 key-value 架構。 不過如果是以 cache 來說，的確 key-value 架構就還蠻好用的。…
October 13, 2021In "Computer"
AWS 上的 Redis 服務支援 Global Replication
AWS 上的 Redis 服務 (Amazon ElastiCache) 推出了 Global Datastore，也就是跨區同步的功能：「Now Available: Amazon ElastiCache Global Datastore for Redis」。 技術上會分成 read endpoint 與 write endpoint (在最後面的操作可以看到 $US_WEST_1_CLUSTER_READWRITE 與 $US_WEST_2_CLUSTER_READONLY)，所以算是蠻常見的 primary-secondary 架構。 不過我基本上不太愛 Redis，能用 Memcached 解決的偏好用 Memcached 解。不過如果把 Redis 當作是一種雲端服務的話，倒是還可以接受...
March 18, 2020In "AWS"
Leave a Reply
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK