I don’t know whether it’s aimed at analytics users. I have a tendency to think in terms of OLTP, since I am working on an airline reservation system.

As you say, the fact that it has a MySQL front end may mean that they have in mind LAMP-stack web sites, Drupal sites, etc. I don’t know. And also as you say, streaming technology is good for caching recenbt data in memory. I don’t know whether they are aiming at applications with that property.

As Pror. Stonebraker says these days, one size does not fit all. There are many useful architectures now, and for high performance you have to be careful to match the architecture to the use cases you care about.

ObjectStore, which I co-architected, was aimed at C++ programmer who wanted language transparency, sharing, ability to take advantage of powerful client-side computers, operating on data with good spatial and temporal locality, and not doing complex queries. (There were plenty of customers who were happy with that and Object Design was very successful.) That’s another example of a different (in some ways) DBMS architecture.

Nothing that comes to mind is faster than a streaming engine integrated with a DBMS. But for use cases where Tokutek does the job, it could be simpler/cheaper than that approach.

Not at this time. But I took pity on them and did a favor anyway.

Is reliance on a “cache-oblivious dynamic search tree as an alternative to the ubiquitious [sic] B-tree” (quote from the paper you cite) meant to appeal to analytics users? B-trees are good for random-access retrieval of relatively small numbers of records and the implication of the term “search tree” is that it would be similarly suited.

If the goal is fast data availability, why not look at a streaming-data engine that caches good volumes of recent data in memory? Or is the advantage here that this software is a MySQL engine?

In a conventional relational database system, you have a tradeoff. Adding more indexes makes queries (that use whatever columns are indexed) faster, but it makes updates slower because you have to update all those indexes (and write back the pages they’re stored on). Tokutek’s basic idea is that now you’re free to put in as many indexes as you want (hence the reason it’s good for query-orinted uses), because the indexes do not slow down writes the way ordinary B-tree indexes would.

The “fractal tree” algorithm has been published. It’s based on the “Cache Oblivious” concept; see Wikipedia, which in turn points you to a nice explanation by Prof. Eric Demaine of MIT. The “fractal tree” index papers are pointed to from http://supertech.csail.mit.edu/cacheObliviousBTree.html. Note that the name “fractal tree” was introduced by Tokutek and is not used in these papers. They use names like “cache-oblivious search trees”, just so you know that that’t the thing we’re talking about. “Fractal Tree”, in my opinion, is a reasonable name from a technical point of view and better from a marketing point of view. Naturally, Tokutek and the inventors have patents pending. Bradley Kuszmaul of MIT, Michael Bender of Stony Brook U., and Martin Farach-Colton of Rutgers are the inventors.

It seems to me that doing ACID transactions will still incur costs for committing the index changes to disk, if you implement it the most obvious way. Presumably they will implement it more cleverly than the obvious one. This is not discussed in the academic papers. I speculate that this is why they have not yet implemented ACID — it’s not as easy as just following the published methods. But that’s just a speculation.