stephen_mcd
Joined 16 years ago
Karma
533
Submissions
155
Member since
Apr 10
http://jupo.org
View on Hacker NewsRecent submissions
Comment · 8 years ago
Cool!
I built CurioDB a while back with the same idea, but using Akka as the underlying framework. Persistent Redis with distributed transactions, embedded Lua and a websocket front-end:
Comment · 10 years ago
You're not wrong, Walter.
Comment · 10 years ago
CurioDB too: http://curiodb.jupo.org
Comment · 10 years ago
If each key/value in the DB is treated as distributed (as per the actor model), a lot of the limitations Redis faces in a distributed environment are solved. I wrote a lot more about it here: http://blog.jupo.org/2015/07/08/curiodb-a-distributed-persis...
Comment · 10 years ago
I really love the idea of explaining the actor model as tons of tiny little servers compared to a single monolithic server. I tried to make the same comparison recently when I talked about adding distributed transactions to CurioDB (Redis clone built with Scala/Akka): http://blog.jupo.org/2016/01/28/distributed-transactions-in-...
Comment · 11 years ago
Great project. I recently used LuaJ to embed Lua scripting inside CurioDB: https://github.com/stephenmcd/curiodb - it's a distributed Redis clone built with Scala/Akka. In terms of matching features with Redis, LuaJ was a life-saver.
Comment · 11 years ago
Yep, one actor per KV means some kind of distributed coordination would be needed - that doesn't exist yet.
Comment · 11 years ago
That'd be good!
Comment · 11 years ago
Hey Jon, long time no see. :-)
Yes I imagine the thinking there is similar in your project, eg: Redis/CurioDB :: Node/SocketCluster (https://github.com/SocketCluster/socketcluster).
Comment · 11 years ago
Glad you like it!
Hardware requirements would depend on your usage of course, it's like asking about the length of a piece of string. :-)
Honestly though, the code probably needs a lot more eyeballs on it before it's production ready, which is why I posted it here.