I don’t know what you’re talking about, because I don’t take benchmark descriptions seriously enough to read and remember them. See the “Benchmarking” section here or search on “TPC” to see what I mean.

CAM

We have worked on a new database/platforms for last 6 years we have been running enterprises on in memory model with many points being listed in this article. From our research we concur, the relational DB model is no good. It is not only about performance but also inflexibility and the resultant introduction of unnecessary complexity.

We have gone much further than all this. Combination of these DB thoughts with semantics leads to all kinds of other weird and amazing properties for db. Radical reductions in size of DB are possible. Atomisation of databases increases speed etc. etc. To discover what is right all the angles have to be investigated. Ultimately DB is just a component to keep/act on knowledge/information.

Pawel Lubczonok

The H-Store claim is that they get an order of magnitude or whatever single-processor performance advantage over disk-based systems, even for database sizes that disk-based systems can put entirely in cache. (Indeed, the starting number is more like 15X, but that’s the really rose-colored view.) That’s supposed to make up for any parallelization awkwardness.

The same team did C-Store/Vertica, and they followed a similar approach. I’m not aware of Vertica having the same level of interprocessor data movement (or, better yet, data movement prevention) sophistication as some of its competitors. But based on their sales figures, it seems they’re winning a lot of POCs even so.

Best,

CAM

I’d like to expand my point about idle processors. Basically, you can always make a database application faster by throwing hardware at it. For many applications, the big modern database products don’t scale very well with multiple machines, so typically you have to buy faster computers, which is expensive because price goes up much faster than computer speed. That is, to get a box that’s twice as fast, you pay lots more than twice as much. What H-Store is trying to take advantage of is that buying twice as many computers of the same speed costs exactly twice as much (less if you get bulk discounts ). So it’s less expensive to have a database product that scales and buy several cheap computers to run it on than to buy one that doesn’t scale and buy big iron.

However, if you have idle processors, that changes the equation. If your processors are idle half the time then you have to buy four computers, not just two. Suddenly the equation doesn’t look quite so good for multiple computers. At that rate, you are better off going with a computer that is twice as fast, so long as it is less than four times as expensive.

Thanks for your comments in the first two paragraphs of 3)!

I’m glad they’re working on better synchronization; despite quite a bit of time talking with them I never got to exactly that point.

Where you confused me is where you seemed to be saying that a stored procedure has to have all of the following properties:

A. No application logic.
B. Single ACID transaction.
C. Coarse-grained and doing a lot of work.

While that’s what I read, it surely can’t be exactly what you meant.

Best,

CAM