Capt. Jake Owens knew the Afghans often communicated through parables, and he had inherited a favorite from a mentor. He holds up an apple and asks, “How many apples do you see?” Most people answer, “One.” “How many seeds are in the apple?” asks Owens. Say you guess eight. “What happens if you plant those eight seeds?” You get eight trees and, of course, all the apples they produce. “So how many apples am I holding in my hand?” Owens asks again.
From “The World’s Hardest Consulting Gig,” part of Fast Company’s Startup: Afghanistan package.
Back by popular demand: presentation at StrangeLoop
Since the acquisition announcement many people have been asking me for a good overview of our technology. Perhaps one of the best places to start is a presentation we gave at the StrangeLoop conference last year.
Akiban is acquired by FoundationDB
When you start a company, you don’t really know what to expect. Just like having a baby, you know it is bound to have some of your DNA, but what personality it will take and how it will grow is quite unknown and exciting.
I started Akiban because I wanted to tackle a simple problem. Relational databases don’t handle objects very well, but objects are how we describe the world. In technical terms, I knew that logical normalization is good but that physical normalization into distinct tables is wrong for most workloads. It’s a frustration that’s encountered in almost every software project and usually means ugly band-aides - and it’s been one of the major drivers for NoSQL. I can say with some amount of pride that we’ve solved that problem in a deep and elegant way.
The FoundationDB acquisition is an exciting moment for me. We’re making a leap in a speed that is hard to imagine - because two incredibly compatible stories and technologies are coming together.
As I write this, our unique database stack is running as a stateless service on top of FoundationDB’s scalable backend. Through close collaboration and over a short amount of time, we are now capable of delivering scale, high-availability, fault tolerance and very high-concurrency because multiple Akiban SQL engines can run in parallel against FoundationDB. Not bad. Especially considering that at present, no one in the NoSQL market is able to support operational SQL. The technical fit, that we describe in more depth on the Akiban blog and FoundationDB blog, is quite striking.
I have learned a tremendous amount at Akiban. I love technology and now see that the business side of it is as equally important, and that engineers must play an active role in defining it. I tend to worry about the wrong things - so I might as well not bother worrying. I also know that years of perseverance and patience stand behind every “overnight success” we hear about. Most importantly, I see how it is all about the people and that we are all so fortunate to be surrounded by incredible individuals - co-workers, investors, clients, friends, advisors, competitors, community. For me, this has been the best part of it all.
I’m excited about what’s to come because it continues to feel extreme and unknown and that’s always compelling to me, and also because the greatest opportunities come with big changes. I know that like every child, companies must grow and evolve. It’s time for Akiban to leave home and move under a new roof. Thanks to everyone that has been a part of Akiban until now.
Schemaless? A bit exaggerated no?
The mongoose quick start guide is interesting in that it encapsulates an insight very cleanly:
Developers are looking for a flexible schema, NOT for no schema.
Here’s an extract from the first few lines of the quick start guide:
So the first concept after connecting to a database is… yes, defining a schema. By making NoSQL systems “schemaless” the ORMs or mapping layer must assume that responsibility and the developers, whether knowingly or not, assume the responsibility for data evolution and data quality. The ease of prototyping is offset by the difficulty in managing and evolving.
Here’s a suggestion for a better approach in the database itself: make it easy for a developer to create schemas, not just tables but of rich objects, and make schema evolution seamless. The advantages of knowing what data one has are that queries become a pleasure and data evolution and data quality are much much easier.
I started thinking about this again when I came across this blog post from hortonworks espousing no schema. In his words “A schema is not needed when you write data; instead the schema is applied when using the data for some application, thus the concept of “schema on read”, because “Changing the schema is a significant undertaking, one that most IT organizations don’t take lightly”. What he forgets to mention is what happens when we loaded a lot of data and have no idea of what’s there.
A smart system will learn the data as it arrives and automatically allow the schema to evolve. Such a system will retain the benefits of fast development, with the advantages of powerful querying and data quality.
I think people are starting to see the no schema hype for what it is: an over-reaction. Relational systems make it hard to model rich objects AND make it hard to evolve a schema. They are outdated. The backlash espouses throwing everything away. Most developers now realize that we need to simply solve the problem.
Charting against an Akiban deployment using chartio
One of the big advantages of the Akiban Service is very fast SQL against native object data (what I technically call nested tuples).
This weekend we had a chance to get chartio working directly against an Akiban deployment. Because we are not 100% compatible with the postgres protocol there were a few loose ends that needed tightening. A little work by our Mike McMahon combined with a bit of advice from Dave Fowler and his team at chartio, and the beauty of running fast SQL reports against object/JSON data comes to life. Here is a sample chartio dashboard working against the employees ‘default’ space that is deployed with every new account.
Current database management systems were designed assuming that data would reside on disk. However, memory prices continue to decline; over the last 30 years they have been dropping by a factor of 10 every 5 years. The latest Oracle Exadata X2-8 system ships with 2TB of main memory and it is likely that we will see commodity servers with multiple terabytes of main memory with- in a few years. On such systems the majority of OLTP databases will fit entirely in memory, and even the largest OLTP databases will keep the active working set in memory, leaving only cold, infrequently accessed data on external storage.