back to article Database daddy goes non-relational on NoSQL fanbois

Postgres and Ingres father Michael Stonebraker is answering NoSQL with a variant of his relational baby for web-scale data — and it breaks some of the rules he helped pioneer. On Tuesday, Stonebraker’s VoltDB company is due to release its eponymous open-source OLTP in-memory database. It ditches just enough DBMS staples to be …

COMMENTS

This topic is closed for new posts.
  1. The Fuzzy Wotnot

    Really that useful?

    The in-memory model might be well and dandy on small subsets of data but when you have financial companies with very, very stringent rules on data retention and protection, plus business users with data retention fetishes who seem determined to keep 175 years of data available to report on at a seconds notice, I can't see these in-memory things doing much more than acting as front-end caches, like Oracle's TimeTen, to web server apps.

    Oh an that price of $15,0000, is it $15k or $150k?

    1. Tim Callaghan

      re: transactional history and pricing

      VoltDB is all about workload specialization. Transactional data exists in VoltDB, when the data is static it needs to be transitioned to an OLAP system for long term reporting. We have functionality to assist in moving data out of VoltDB and into these sorts of systems.

      As for pricing, it is $15,000 ($15k).

      Tim Callaghan

      VoltDB

  2. Britt Johnston
    Unhappy

    good try to fix non-problem?

    I would be surprised if speed of oracle is usually the problem. Most of our oracle apps are upgrades of slow but successful access solutions, which don't get a redesign*, and only get tuned for performance if they drag after going live.

    * we used to have a database designer, but he got outsourced

  3. BlueGreen

    Interesting but you can get some way there already

    I'd like the time to look over the papers propely but not going to happen.

    Browsing the first from the link ('The End of an Architectural Era (It's Time for a Complete Rewrite)') they assume a very restricted set of transactions ("H­Store requires the complete workload to be specified in advance, consisting of a collection of transaction classes") and you can effectively disable read locking (& probably latching too if you run in single-user mode, if db supports that) anyway. Given such constraints I bet I could make significant speedups to stuff I've worked on (assuming they needed it, which is another matter).

    Don't understand how they can omit logging though ("One must continue to have an undo log, in case a transaction fails and needs to roll back. However, the undo log does not have to persist beyond the completion of the transaction. As such, it can be a main memory data structure that is discarded on transaction commit." eh? It maintains consistency from other sites but what if they're down?)

    Still, interesting work.

    1. rbetts

      Logging in VoltDB

      An in-memory undo log is kept for uncommitted transactions to allow rollback. This is the only purpose the log serves. HA is achieved through replication. The user can configure the replication factor (how many replicas of each partition to maintain).

      Thank you for the comment, BlueGreen.

      Ryan Betts

      VoltDB Engineering

  4. The First Dave

    untitled

    Think he missed the point a little - the average task is to provide a data-store for an object-oriented design, so there is far more to be gained by dumping the Relational part and replacing with a better model.

  5. OffBeatMammal

    SQL FTW!

    Sharding is a pain in the behind to deal with (and not a good way to scale up), NoSQL is interesting but really makes ad hoc queries difficult and tranditional SQL really starts to suffer when you're doing a huge number on inserts/updates

    If this solution is able to offer SQL style queries but NoSQL scalability by isolating the developer from some of the complexity then it's got my vote

This topic is closed for new posts.

Other stories you might like