April 3, 2010
Akiban highlights
Akiban responded quickly to my complaints about its communication style, and I chatted for a couple of hours with senior Akiban techies Ori Herrnstadt, Peter Beaman and Jack Orenstein. It’s still early days for Akiban product development, so some details haven’t been determined yet, and others I just haven’t yet pinned down. Still, I know a lot more than I did a day ago. Highlights of my talk with Akiban included:
- Akiban is basically in the business of making OLTP (OnLine Transaction Processing) DBMS.
- That said, Akiban does not necessarily aspire to offer the DBMS that has the best update efficiency or throughput. In particular, the Akiban DBMS stores every datum twice, even before replication (and indexes) are taken into account.
- Akiban wants to store everything as third normal form relational databases. I didn’t ask whether 3NF is a hard requirement, a Really Good Idea if you want Akiban to run fast (that’s the one I’d guess), or merely a general design assumption.
- Akiban characterizes its core differentiators/value proposition as being:
- Scale-out
- No need to pay the traditional cost of joins
- Thus, Akiban is telling something like a NoSQL story.
- However, Akiban offers SQL.
- Specifically, Akiban offers SQL through a MySQL front end. However, the choice of front-end could change (Drizzle?), and non-relational front-ends (object?)* could eventually also be offered.
- Akiban’s first target market is SaaS providers, specifically ones that have true multitenancy issues. More generally, Akiban is pursuing cloud/private cloud applications with lots of tables. (Ori talks of a few thousand tables as being a small number.) At least at first, Akiban is conceding the market for huge-volume, scale-out, no-expensive-join web databases to the NoSQL contenders.
- Akiban has been in prototyping/development of some kind for several years. However, Akiban got its first angel funding early last year and its first venture funding late in 2009, so development only ramped up recently.
- Ori tells a version of the rather common “Everything I need to know in life I learned in the Israeli Army, and now I’m commercializing it” story. However, I didn’t get the sense that Akiban is necessarily a direct extension of a specific Israeli military project.
* A lot of Boston-area DBMS developers have significant non-relational experience. E.g., Jack Orenstein was an Object Design founder, and Peter Beaman used to work for Intersystems, both object-oriented DBMS vendors.
Akiban technical highlights include:
- Somewhat confusingly, Akiban databases are divided into “groups” of tables. The point of Akiban groups is:
- Many-to-many relationships exist only within Akiban groups, not among tables in different groups.
- Tables within Akiban groups are kind of pre-joined; more precisely, data is organized physically in a way that anticipates joins.
- Thus, most Akiban joins can be executed without the cost of traditional join algorithms.
- One copy of the data Akiban stores is, in effect, clustered by object. E.g., a customer and her orders are stored together, or a patient and the records of her doctor visits. That’s how Akiban anticipates most joins.
- The other copy of Akiban data is stored in columns (I’m not sure if this part is strictly columnar or more hybrid row/column), which are ordered consistently. In particular, they’re in an order dictated by the organization of the other copy of the data, whatever that means. Akiban’s goal is for this copy of the data to support reporting, operational BI, etc.
- Akiban relies heavily on its optimizer to determine data layout, probably more than conventional DBMS do.
- In essence, Akiban has a MySQL front-end and a storage engine back end, each running on its own hardware cluster, with each node of one cluster talking to each node of the other.
- I gather that Akiban distributes data among nodes clustered according to, in effect, object identifier. Presumably, inter-node joins are rare. But we didn’t discuss distribution, replication, or other scale-out issues in any detail. Indeed, I gathered that significant parts of all that weren’t built yet, and perhaps even not yet architected.
Categories: Akiban, MySQL, Object, OLTP, Software as a Service (SaaS)
Subscribe to our complete feed!
Comments
4 Responses to “Akiban highlights”
Leave a Reply
[…] edit: I’ve now posted again about Akiban, this time based on actually talking with the […]
[…] Monash wrote about a conversation he had with us last week. He wrote: “Akiban does not necessarily aspire to offer the DBMS that has the best update […]
[…] Akiban or VoltDB, Clustrix makes database appliances. The Clustrix software seems to assume a Clustrix […]
[…] Ori Herrnstadt of Akiban […]