there must be a better way @renormalize - Tumblr Blog

Clear. Direct. Concise. Any questions about what Sherpaa does?

Love these.

via Sherpaa

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.

“I practiced that parable over and over and over with my linguist,” Owens says. “Until I got it right.”

From “The World’s Hardest Consulting Gig,” part of Fast Company’s Startup: Afghanistan package.

foundationdb

renormalize

Google F1 may be the best thing to happen right before we make the SQL Layer avaliable. In this article I'm letting Google explain our approach...:

The Google F1 database paper just became generally available. It’s the database that runs AdWords, so I suspect Google kind of cares about it. Google F1 bears an amazing resemblance to our FoundationDB SQL layer. Both leverage an underlying scalable and transactional storage substrate to...

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.

A blissful morning in Rhode Island

brycedotvc

renormalize

from brycedotvc

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.

#schema #hadoop

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.

#Akiban #chartio

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.

http://vldb.org/pvldb/vol5/p298_per-akelarson_vldb2012.pdf

nosql

renormalize

Brent Ozar about the state and future of the things in the SQL Server space:

In SQL Server 2012 and beyond, we’ve got:

AlwaysOn Availability Groups – high availability, disaster recovery, and scale-out reads

Hekaton - in-memory storage with optimized stored procedures and new data formats on disk

Column store indexes – faster data retrieval for certain kinds of queries

Call me maybe crazy, but I don’t see really widespread adoption for any of these.

Leaving crazyness aside, I’m wondering if these features are not of interest for SQL Server users then what is would SQL Server users want to see?

✚ Hekaton is something new for me to read about.

✚ Here’s something interesting about Hekaton:

By late fall 2009, Larson and his colleagues had come up with a design and a simple prototype for an in-memory database engine that showed huge performance improvements. They had moved away from a partitioned approach, which essentially treated a multicore processor as a distributed system, to a latch-free, also called lock-free, design that focused on removing the barriers to scalability present in current systems.

✚ There’s a paper about the MVCC implementation in Hekaton: High-Performance Concurrency Contorl Mechanisms for Main-Memory Databases.

nosql

renormalize

Trying so hard to fit objects and JSON into a relational model. Try nested-tuples man...

A very interesting set of slides from Christophe Pettus looking at the features in PosgreSQL that would allow one to use it as a document database:

XML

built-in type

can handle very large documents (2GB)

XPath support

export functions

no indexing, except defining custom ones using...

Akiban Server is Open Source

Check it out: https://github.com/akiban/akiban-server

Joining it's brothers Persistit store and the parser projects

kiip-engineering

This week marks the one year anniversary of Kiip running MongoDB in production. As of this week, we’ve also moved over 95% of our data off of MongoDB onto systems such as Riak and PostgreSQL, depending which solution made sense for the way we use our data. This post highlights our experience with…

Wouldn’t it be nice if there were a unified solution that seamlessly handled structured, unstructured, and real-time data with transactional and analytics capabilities built into it?

http://sandhill.com/article/database-as-a-service-the-next-frontier-in-the-cloud-2/

Yes it would. Working on it.

Suggestions for maintaining an empty in-box, a goal that has tantalized many since the dawn of e-mail. This article describes the only approach that sort of worked for me, with the addition of quickly skipping what seemed unimportant. Will Mailbox finally change that? I doubt it, but it's good to finally see a head on attempt.

I personally think that the only real solution lies in using a quota system. Sounds as likely as the middle east peace process :)

Trending Blogs

Recently Viewed Blogs

there must be a better way