Doesn't Redis already address all of this?
Same question. How is this different from Redis?
GhostDB – A Fast Distributed Cache
21–30 of 37 posts
Re: GhostDB – A Fast Distributed Cache
#22Will love to dig deeper
Re: GhostDB – A Fast Distributed Cache
#23Earlier quoted context omitted.
> I've written a redis clone in Go a few years ago and the GC pauses when reaching a few GBs of utilization were awful. Probably managable with a good slab allocator.
Yeah, I've seen people do that but I've glanced the code, it's certainly not the case here.
We're aware of the issues this could cause and we will be looking into relieving GC pressure
Re: GhostDB – A Fast Distributed Cache
#24How does this compare to Anna, which makes similar claims (and seems to actually deliver), https://github.com/hydro-project/anna (up to date link)
I've never heard of this so I can't say.
Re: GhostDB – A Fast Distributed Cache
#25Congrats for getting it out there ! That is more than half the battle. I thing I would like to see also is more Redis-Clones. The redis-parts not the KV parts(lots of options here). I want some alternatives or speed improvements for "Unions" and other set based operations :). PS. GhostDB looks cool !
Adding support for sets is on our roadmap!
Re: GhostDB – A Fast Distributed Cache
#26> at any scale Would it be feasible to bundle GhostDB with an Electron app, and run it on end-user’s machine?
I don't know much about electron but if it allows you to bundle binaries and execute them then yes!
Re: GhostDB – A Fast Distributed Cache
#27Could anyone explain a use case for this? (Distributed KV store) Genuine question, thanks
In-memory data lookup
Relational and Non-relational database speedup
Managing spikes in web/mobile apps
Session-store
Token caching
Gaming - Player profiles & leaderboards
Web page caching
Global ID or counter generation
Fast access to any suitable data
Re: GhostDB – A Fast Distributed Cache
#28> in-memory, general purpose key-value caching > GhostDB can provide you with up to a 25x increase in data retrieval speeds when compared to databases such as MongoDB and MySQL. Isn't it insincere to say your tech is faster than a DBMS which works on a slower hardware.
Not associated with the OP, but I don't think so. It really does return your data 25x faster than a disk-based DBMS. The implied reduction in durability from being in-memory is clearly stated up front.
Re: GhostDB – A Fast Distributed Cache
#29Great project. I did not see an explanation on the architecture of a cluster. Is data replicated to all nodes, or is data only stored on a single node (sharded). What happens when a node in the cluster goes down? Does there have to be a consensus (odd number of nodes) for the cluster to be "healthy"?
Currently we follow the memcached model so there is no replication however, remember this is straight out of university were we had to limit scope considerably and were on a tight time constraint but we aim to add data replication, consensus etc.
Re: GhostDB – A Fast Distributed Cache
#30Great project. I did not see an explanation on the architecture of a cluster. Is data replicated to all nodes, or is data only stored on a single node (sharded). What happens when a node in the cluster goes down? Does there have to be a consensus (odd number of nodes) for the cluster to be "healthy"?
> GhostDB provides a very large hash table that is distributed across multiple machines. Sounds like no replication to me, AKA the memcached model. I can't find how to actually configure a cluster (the `Cluster Configuration` section of the docs doesn't contain anything related to hosts). I also can't find anything client side that would distribute requests to a list of nodes with a consistent hash, for ex. I can't f…
The clients are the SDKs. Our docs are getting an update now to better explain how to configure clusters.
The SDKs are in separate repos currently (this is due to how university made us structure the project).