March 19, 2012

Akiban update

I have a bunch of backlogged post subjects in or around short-request processing, based on ongoing conversations with my clients at Akiban, Cloudant, Code Futures (dbShards), DataStax (Cassandra) and others. Let’s start with Akiban. When I posted about Akiban two years ago, it was reasonable to say:

All of the above are still true. But unsurprisingly, plenty of the supporting details have changed.

Akiban company basics include:

Akiban technical basics start:

Because Akiban’s great virtue is short-request join performance, its target market starts with online businesses that maintain some kind of customer profile along with transaction or presence data — for example retailers or dating services.

*For marketing purposes, the word “essentially” is usually omitted.

In its initial release, Akiban will be a single-server product, dependent on MySQL. That is:

Akiban’s idea of initially focusing on existing MySQL installations makes sense, because:

Looking ahead, Akiban tends to conflate the ideas of:

I think those aspects of Akiban’s strategy could still use some refinement.

As for possible Akiban futures:

One thing we haven’t talked about much is write speed. It would seem challenging for Akiban to achieve append-only/log-structured-merge kinds of write speeds. Update-in-place seems like a more suitable model. To me, that screams “solid-state storage”, but of course the reality is that plenty of high-volume MySQL sites today do update-in-place on cloudy disk-based systems. And a few of them even seem to be using Akiban. 🙂


8 Responses to “Akiban update”

  1. Daniel Lemire on March 19th, 2012 2:09 pm

    Putting aside the fact that it is squarely relational, how would you compare it with CouchDB? Looks to me like there are similarities in the physical layout.

  2. Daniel Lemire on March 19th, 2012 2:55 pm

    Also, how does it relate to clustered tables?

  3. Curt Monash on March 19th, 2012 10:42 pm

    Off the top of my head, I’d say it’s more similar to the SQL Server version of clustered tables than to the Oracle version. But I don’t know that even Microsoft has a multi-level hierarchy ala’ Akiban.

  4. Ori Herrnstadt on March 20th, 2012 10:09 am

    Thanks Curt for the post. As you mention, the ability to retrieve objects directly from a relational database is very importnat to us as it bridges a large part of the object-relational gap.

    In terms of update speeds, we are seeing most application and ORMs write transactions that map to table-groups, making a whole transaction local. For example a transaction updating a customer row alongside a new order and a bunch of new items are all written collocated to the same group. Generally speaking we are seeing the Akiban Server operating faster for transactional loads and slower for single table admin style operations as compared to MySQL.

  5. Ori Herrnstadt on March 20th, 2012 10:11 am

    Hi Daniel, Oracle clustered tables (see put all related rows into a bucket and traverse the whole bucket when a record is needed. In contrast, we encourage making table-groups as wide and as deep as needed. Each row that is a part of a table-group object can be accessed very efficiently directly. See more elaborate explanation on our support site

  6. – With a $10,000 employee referral bonus, it’s safe to say Akiban is hiring! on September 6th, 2012 12:35 am

    […] DBMS2 update on Akiban […]

  7. NewSQL thoughts | DBMS 2 : DataBase Management System Services on January 5th, 2013 3:26 pm

    […] vendors I’ve written about in the past include Akiban, Tokutek, CodeFutures (dbShards), Clustrix, Schooner (Membrain), VoltDB, ScaleBase, and ScaleDB, […]

  8. One database to rule them all? | DBMS 2 : DataBase Management System Services on February 21st, 2013 12:53 am

    […] Akiban fondly thinks its data layouts are well-suited for relational tables, JSON, and XML alike. (But business at Akiban may be in flux.) […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.