MagLev 1.0 has been released.
MagLev is a Ruby VM built on GemStone/S, a 64 bit Smalltalk VM. But MagLev is much more than a Ruby VM, it comes with a mature NoSQL data store, from their website:
MagLev VM takes full advantage of GemStone/S JIT to native code performance, distributed shared cache, fully ACID transactions, and enterprise class NoSQL data management capabilities to provide a robust and durable programming platform. It can transparently manage a much larger amount (terabytes) of data and code than will fit in memory.
Monty Williams of VMWare (GemStone was bought by VMWare) to talk about MagLev 1.0
Where does MagLev fit in the current NoSQL spectrum?
- I don’t think of MagLev only as a Ruby VM that has an integrated NoSQL database. I think of MagLev as a NoSQL database that uses Ruby for its data manipulation language.
- The one thing I don’t think people have wrapped their heads around is MagLev provides a “single object space”. Nothing has to be sent/retrieved to/from a separate DB. All your code is executed “in the database.” You don’t even need to keep track of which objects have been modified so you can flush them to disk. MagLev handles that automatically.
- You can store any Ruby object, even procs, lambdas, threads, continuations. Here is an example of stopping, copying, saving, and restarting Threads in a different VM than they originated in. http://blog.bithug.org/2011/09/maglev-debug
- MagLev persistence is akin to Image Persistence, i.e. objects are persisted to disk in the same format they are in shared cache. You don’t need to marshal them or convert them to JSON or another format.
- MagLev transactions are ACID, which means that multiple VM’s can interact with the same repository and share state, objects, and code while maintaining referential integrity.
- When you start a new MagLev VM, code loaded by another VM is likely to still be in the cache. So loading/requiring it can be quite fast.
Official website: http://maglev.github.com/