Monty Williams (VMWare/GemStone) interviewed by Werner Schuster:
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.
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. 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.
Am I the only one confused by the mouthfullness of the above “NoSQL OODB” description?
Original title and link: MagLev NoSQL OODB With Smalltalk-Based Ruby VM (NoSQL database©myNoSQL)
