ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

MagLev: All content tagged as MagLev in NoSQL databases and polyglot persistence

MagLev NoSQL OODB With Smalltalk-Based Ruby VM

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)

via: http://www.infoq.com/news/2011/11/ruby-maglev-10