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

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

The birth and road ahead of TokuMX, the alternative MongoDB engine

While not a MongoDB user (or expert), I find Tokutek’s work on their alternative engine for MongoDB, TokuMX, quite interesting both for technical — what is currently broken in MongoDB — and business point of views — is the InnoDB model possible in the NoSQL space?, what are some possible outcomes of the alternative core technology for free products business model?, would a new product bringing together MongoDB’s missing features and combining them with MongoDB’s “friendliness” and product marketing still lead to a successful product?, etc.

Zardosht Kasheff’s post about the history of TokuMX and how the decision was made to pursue this direction brings some light to both these areas.

But really, the BIGGEST benefit to this approach was the following: we could innovate on more of the MongoDB core server stack in ways the other approaches would not allow. Prior to TokuMX 1.4, such innovations include (but are not limited to):

  • Document level locking
  • Multi-statement transactions (on non-sharded clusters)
  • MVCC snapshot query semantics
  • Clustering indexes (although, to be fair, this was possible in other approaches)
  • Dramatically reduced I/O utilization on secondaries (which we will elaborate on in a future post)
  • Fast bulk loading
  • Enterprise hot backup

For these reasons, we chose this option, and after some hard work, TokuMX was born.

Original title and link: The birth and road ahead of TokuMX, the alternative MongoDB engine (NoSQL database©myNoSQL)

via: http://www.tokutek.com/2014/02/how-tokumx-was-born/


TokuMX transactions for MongoDB

In two posts, the Tokutek guys are explaining how transactions work on TokuMX, the replacement engine they are proposing to MongoDB users—remember that Vadim Tkachenko (“MySQL Performance blog“) called TokuMX the InnoDB for MongoDB?:

  1. the what: Introducing TokuMX transactions for MongoDB applications

    • For each statement that tries to modify a TokuMX collection, either the entire statement is applied, or none of the statement is applied. A statement is never partially applied.
    • Commands beginTransaction, commitTransaction`, androllbackTransaction` have been added to allow users to perform multi-statement transactions.
    • TokuMX queries use multi-version concurrency control (MVCC). That is, queries operate on a snapshot of the system that does not change for the duration of the query. Concurrent inserts, updates, and deletes do not affect query results (note this does not include file operations like removing a collection).
  2. the benefits: Four benefits of TokuMX transactions for MongoDB applications:

    1. cursors represent a true snapshot of the system
    2. simpler to batch inserts together for performance
    3. simpler for applications to update multiple documents with a single statement
    4. no need to combine documents together for the purpose of atomicity

✚ I’d find TokuMX’s transactions even more interesting if they would work by default at a shard level instead of cluster level. Users would need to manually configure cluster-wise transaction thus remaining in control of the performance and availability.

✚ I still have my doubts about TokuMK’s positioning, but that’s a business & marketing story.

Original title and link: TokuMX transactions for MongoDB (NoSQL database©myNoSQL)


TokuMX means for MongoDB the same as InnoDB to MySQL

Vadim Tkachenko (MySQL Performance blog) about TokuMX, the fractal tree-based storage for MongoDB:

Why is TokuMX interesting? A few reasons:

  • It comes with transactions, and all that good stuff that transactions provide: a concurrent access to documents (no more global write-lock in MongoDB); crash recovery; atomicity
  • Performance in IO-bound operations
  • A good compression rate, which is a money-saver if you use SSD/Flash
  • But it is also SSD/Flash life-time friendly, which is double money-saver

Some thoughts:

  1. TokuMX brings to the table some features that might not be top priorities or even features that 10gen wants into MongoDB.
    1. I seriously doubt 10gen engineering or sales are recommending TokuMX.
    2. While the advantages of the TokuMX engine are quite interesting, how isTokutek closing sales (considering 10gen is not sharing their list of customers)?
  2. How would this mix of 10gen and Tokutek work at the business level? I don’t think Tokutek wants to sell or that 10gen is ready to acquire/merge with Tokutek.
  3. How would this work for customers? The InnoDB-MySQL and TokuMX-MongoDB parallel looks good on paper, but I cannot imagine how a user will interact with these 2 providers. Buy a license from Tokutek, then pay 10gen support for MongoDB and then call both?
  4. How will this integration work long term considering the complete control 10gen has over the core MongoDB? While 10gen could come up with a compatibility certification, I don’t think they’ll actually do it (see point 1).

Original title and link: TokuMX means for MongoDB the same as InnoDB to MySQL (NoSQL database©myNoSQL)

via: http://www.mysqlperformanceblog.com/2013/06/25/tokumx-is-mongodb-on-steroids/