VoltDB takes that approach. Each of their partitions is handled by a
single threaded process. They manage concurrency control with a
transaction scheduler, so no server ever runs concurrent transactions,
hence no locking at all. Their replication is handled by any number of
independent server executing transactions in lock step. They generally
don't run more servers than cores.

The upside is that a transaction can be isolated to a single partition
it executes extremely quickly. The downside is that if the transaction
can't be isolated to a single partition (an unqualified "select count(*)
..", for example), then the entire cluster runs at the speed of a single
core. They also have to subset SQL to the point of unrecognizability so
every SQL execution is a full transaction.

It produces very good numbers and not very enthusiastic customers.

On the other end of the spectrum, NuoDB is now pushing 140,000 YCSB
transactions per second on four transaction engines and a single storage
manager. Kinda worthless transactions, but 140,000 of anything per
second boggles the mind.

On 10/30/2012 4:39 PM, paulruizendaal wrote:
>
>
>
> It is interesting to see that on the high scalability side designs
> seem to end up with a 'single threaded' (one or at most a few threads
> per core) architecture, running many non-blocking tasklets
> concurrently using event driven scheduling. The underlying
> architectural patterns of for example nginx and the erlang VM are
> quite similar. The pattern seems to apply to some of the N*SQL
> databases as well.
>
> --- In Firebird-Architect@yahoogroups.com
> <mailto:Firebird-Architect%40yahoogroups.com>, "mariuz" <mariuz@...>
> wrote:
> >
> > Why nginx is better ? is the architecture : simple and better and
> yes the author did ASM programming too
> >
> >
> > http://www.aosabook.org/en/nginx.html
> >
> > http://news.ycombinator.com/item?id=4669234
> >
>
>



[Non-text portions of this message have been removed]