I don't think so, just from quickly glancing at the source. The Ruby GC (at least in MRI) doesn't deal well with even moderately sized heaps (>500MB), so I imagine they are fairly dependent on the OS disk cache for keeping things in memory.
(I don't want to diss creation in general or an open source project in particular, but the presence of a "competition" table implies that this is going to fill a gap)
There's some other areas where Riak is significantly ahead, such as already having Map-Reduce (allowing the map and reduce functions to be in javascript, even), scaling up and down are both already implemented, and riak supports multiple backends, including in-memory databases, leveldb, bitcask and innostore.
In a matter of days, Riak will also be getting secondary indexes, full text search fully integrated, and riak-pipe, a great way of building workflows.
If these people want to be working in Ruby, there's Ripple-- a ruby library supporting Riak, and adding Ruby style functionality (I believe, I'm not too familiar with Ripple.)
I think if you want to go your own way and build your own thing, that's fine, and good for you, if its' a learning exercise. But if you want to advance the state of the art, either do something different from the rest, or join an existing open source project that is further down the pike and help it go even further.
I say that, of course, while myself I'm working on something I've been thinking of as "ruby on rails done right" (namely, a web platform where you write coffeescript for the server, and you have scalability and database built in via close integration with riak)... but I hope that I'm cutting some new ground. (namely, letting you make coffeescript run concurrently...)
I'm confused by mono table (which implies a single table) and how mono doesn't mean single point of failure. They talk about a cluster, and adding machines, so I guess mono table lives on multiple machines... but how? Is it replicated to every machine? (EG: every node in the cluster contains a complete set of the data?) IF so, this would mean that as you scale, the updates of writes to replicate the changes across the cluster could possibly become quite a problem, in terms of bandwidth and latency. I can imagine each node spending most of its time handling updates from other nodes.
Also, unless you're locking the table on every node simultaneously (the thought of dealing with that gives me headaches) you're going to have consistency issues.
I think their goals are excellent-- zero admin, no SPOF are really important features to me. If they've got a new architecture, then it could be a really important and innovative project.
I am a committer to this project, which is its infancy. We got some premature attention to our homepage, which was not clear on the specific use case we are seeking to solve with Monotable. We've updated the README to address most of the questions we received here and on reddit. https://github.com/imikimi/monotable . Thanks for all the feedback and questions.
17 comments
[ 3.6 ms ] story [ 51.2 ms ] thread(I don't want to diss creation in general or an open source project in particular, but the presence of a "competition" table implies that this is going to fill a gap)
In a matter of days, Riak will also be getting secondary indexes, full text search fully integrated, and riak-pipe, a great way of building workflows.
If these people want to be working in Ruby, there's Ripple-- a ruby library supporting Riak, and adding Ruby style functionality (I believe, I'm not too familiar with Ripple.)
I think if you want to go your own way and build your own thing, that's fine, and good for you, if its' a learning exercise. But if you want to advance the state of the art, either do something different from the rest, or join an existing open source project that is further down the pike and help it go even further.
I say that, of course, while myself I'm working on something I've been thinking of as "ruby on rails done right" (namely, a web platform where you write coffeescript for the server, and you have scalability and database built in via close integration with riak)... but I hope that I'm cutting some new ground. (namely, letting you make coffeescript run concurrently...)
The description of distributed data store should specify the tradeoffs w.r.t. the CAP theorem.
https://github.com/imikimi/monotable/blob/master/lib/monotab...
That evaluation is admittedly, based on a rather specious list of "features".
Also, unless you're locking the table on every node simultaneously (the thought of dealing with that gives me headaches) you're going to have consistency issues.
I think their goals are excellent-- zero admin, no SPOF are really important features to me. If they've got a new architecture, then it could be a really important and innovative project.
Would love to see an architectural description.