To get started login to try.akiban.com and select your favorite deployment:

Then use the credentials to connect chartio to the data:

But first the execution plan in Akiban Server for the query above:

 Limit_Default(limit=5: project([Field(0), Field(1)]))    project([Field(0), Field(1)])      AncestorLookup_Default(Index(schema.users.PRIMARY[IndexColumn(uid)]) -> [schema.users])        IndexScan_Default(Index(schema.users.PRIMARY[IndexColumn(uid)]) (,) (Field(0) DESC))

Translation: scan the index in DESC order, look up the user row in the table group using AncestorLookup operator, Project the row to output and Limit to 5 rows. Simple.

A more common query is one looking for users with the latest changes:

SELECT * FROM user ORDER BY latest_change DESC LIMIT 5;

Well, that's easy. Put an index on user.latest_change. Done. The execution is about the same:

 Limit_Default(limit=5: project([Field(0), Field(1)]))    project([Field(0), Field(1)])      AncestorLookup_Default(Index(schema.users.LATEST_CHANGE_IDX[IndexColumn(uid)]) -> [schema.users])        IndexScan_Default(Index(schema.users.LATEST_CHANGE_IDX[IndexColumn(latest_change)]) (,) (Field(0) DESC))

What if another table was involved? Say, filtering users with a specific memberships level on top of the same query (a user may have several membership levels):

SELECT * FROM user, user_membership WHERE user.uid = user_membership.uid AND user_membership.membership_level = 3 ORDER BY user.latest_change DESC LIMIT 5;

Well, in a relational system I'm a bit stuck.

Option 1:

use an index on user_membership.membership_level. Go to the user_membership row to get the uid. For each uid get the user row and the latest change. Put in a temp table. When done scanning the index sort all the users in the temp table on latest_change. Now bring the latest 5 in DESC order. If there are only 10 users with that membership level it's not too bad. What if there are 10,000 user with that membership level? Scan all 10,000 and sort them to bring back 5. kind of expensive.

There must be something else a relational system can do right?

Yes,

Option 2:

use the index on user.latest_change as before, scan it in descending order, but rather than returning each user, first check that the user has membership 3. If the user has membership level 3 return the row, otherwise, discard it and continue to the next row.

This plan is diametrically opposite to the previous one. It'll be very good for a very common membership level and very bad if it is rare. It eliminates the sort but may have to scan a lot of the users to come up with the 5 it needs.

Win some loss some? Yes, except losing in one million users could hurt for a few seconds each time.

In Akiban Server we can build indexes on table groups, not just single tables:

CREATE INDEX 'GROUP_INDEX_EXAMPLE' ON user_membership (user_membership.membership_level, user.latest_change)

And the execution plan? As simple and efficient as the other queries on a single table above. It scans 5 index values max because it now has a covering index that provides both filtering and sorting:

 Limit_Default(limit=5: project([Field(0), Field(1)]))    project([Field(0), Field(1)])      AncestorLookup_Default(Index(schema.users.GROUP_INDEX_EXAMPLE[IndexColumn(uid)]) -> [schema.users])        IndexScan_Default(Index(schema.users.GROUP_INDEX_EXAMPLE[IndexColumn(membership_level), IndexColumn(latest_change)]) (>=UnboundExpressions[Literal(3)],<=UnboundExpressions[Literal(3)]) (Field(1) DESC))

So this new Index Scan in the line above applies the predicate as a range (membership_level>=3 AND membership_level<=3) asking for the output to be sorted by the latest_change column in DESC order.

In classic relational systems, objects (or documents) get normalized into multiple physically distinct tables. While normalization is great for modeling it translates to massive inefficiency in both storage and access of distinct tables.   It just doesn’t scale.

The core realization we came to, and apparently now Google came to as well, is that rows from related tables that are always retrieved together should be colocated with one another. A customer row should be stored with it’s order rows.  An order row should be stored with it’s item rows.  When you retrieve this collection of related rows, you will get it in a single read.  When you transact on these records it will write to a single location.  It scales.

And, this is a “big deal”.  Do you know Edgar Codd?   He’s the father of relational databases,and 40 years ago he “invented” the use of relational algebra and relational modeling for databases.  In the first sentence of his seminal work he opens with:

"Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation)."

Let’s pause and listen. What he’s telling us is that there’s no reason why data has to be physically stored in tables.  But, databases are all about tables, right?  How could you have SQL without tables?

I’ve always thought that this idea, this insight in Codd’s vision is the missing link between RDBMs and what we have called “NoSQL”.   There’s this competition between the two that doesn’t need to exist.  NoSQL vendors are running around painting relational databases as the enemy, and just last week I saw a flurry of Tweets proclaiming the beginning of the “post-relational age”.  This is premature overreaction.  Relational databases have a lot of room to grow.  With the right approach we can get the best of both worlds: Document like access to table-groups alongside seriously fast SQL, and we’re just getting started. SQL is just a language and scapegoat.   We’d rather solve the fundamental problem related to physical data storage and processing.

While Google has been busy migrating one of their most critical systems, we’ve been helping our customers do the same.   These are customers that were hitting the same performance and scalability bottlenecks that drove the development of F1.   Google’s solution is for a system that runs on Google scale with massive data centers.   The solution Akiban is building is for any scale.  We think that the central idea of table-groups can benefit all applications (even if they run in fewer than 11 data centers).

So what do table-groups give us?

Simpler schema: A relational schema goes from hundreds or thousands of tables to a few main table-groups

Merge documents and SQL: A table group is a definition for an object or document

Super high performance: Queries are fast. In fact, table-groups replace Fact Tables because joins are eliminated (like Fact tables) but without the data redundancy