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 …
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?
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).
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
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 ("HStore 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.
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.
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.
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
- Geek's Guide to Britain Kingston's aviation empire: From industry firsts to Airfix heroes
- Analysis Happy 2nd birthday, Windows 8 and Surface: Anatomy of a disaster
- Adobe spies on readers: EVERY DRM page turn leaked to base over SSL
- Analysis The future health of the internet comes down to ONE simple question…
- Lollipop unwrapped: Chromium WebView will update via Google Play