3 ms·
That's an awfully big claim. Under what conditions does it do well? What does it do badly? Where would I consider using this instead of Redis?
by blowski 10y ago
That's an awfully big claim. Under what conditions does it do well? What does it do badly? Where would I consider using this instead of Redis?
- nordsieck 10y ago"Do work only once, then use centralized caching and cache updating to skip ever doing work again." It looks like their benchmarks are particularly friendly to their cache size.
- marknadal 10y agoRedis is quite an awesome database, these claims here aren't to belittle Redis (it is one of the fastest out there!). Check out there performance (and make note of theirs, and mine, warnings that benchmark tests are not the end game) blog: https://redis.io/topics/benchmarks https://redis.io/topics/benchmarks . The biggest difference is that you still have to speak to Redis over the wire within a single machine, where Redis has it cached and replies. The (terrible terrible?) choice of JavaScript gets around this, once cached, it is directly in the app logic's memory - so you don't even have to perform any request. And that is where you get the speed gain. Summary: GUN's caching is closer to the end result you are measuring, therefore it is faster. Not magical algorithms. - What does GUN do badly? Banking. Anything relating to strong consistency. GUN is an AP system which means you really shouldn't use it for anythign involving accounting, money, etc. - read more about that here: https://github.com/amark/gun/wiki/CAP-Theorem https://github.com/amark/gun/wiki/CAP-Theorem Where should you use it instead of Redis? When you want realtime updates or graph data. There is a 10 minute guide on how to use graphs from a key/value, table or relational, or document oriented way here: https://github.com/amark/gun/wiki/graphs https://github.com/amark/gun/wiki/graphs .
- deleted 10y ago[deleted]