Tony Bain

Top 10 interesting companies in Data Management

A bit of fun for a Sunday.  Below is the list of my top 10 interesting companies in Data Management right now.  Interesting to me means doing new stuff and being somewhat disruptive, or have a “watch and see” quality about them.  Note this is about companies not data management applications. 

While I find a bunch of other data management applications interesting (PNUTS, Cassandra, Redis etc) these aren’t really encapsulated in a company with a go to market strategy.

10gen - They are making interesting noises not sure about delivery yet
Amazon – SimpleDB is neat, but not a grown up data platform yet
Aster Data – Doing funky things with Map/Reduce
GroovyChannel – Are they nuts, they have to change the name of GroovyDB?! *
Kickfire – I love this appliance
The Monty AB Program – Is Maria the new “peoples” MySQL
MySQL  - Because who knows how the Oracle merger will pan out
PostgreSQL Global Development Group – Or is PostreSQL the new “peoples” MySQL?
Wistla - in stealth (shhhhhhh)

Ok you are probably thinking that’s only 9.  I will take feedback in the comments below to help me choose #10 as I am currently undecided on this one.

* Update: GroovyChannel is now know as Groovy Corporation and GroovyDB is known as SQL Switch.

Why you won't be building your killer app on a distributed hash table

A great post from Jonathan Ellis on "Why you won't be building your killer app on a distributed hash table"

Scroll down to see my comment.  I agree a simple DHT is not a suitable solution for mainstream data management issues, but also I think that there is a gap between RDBMS and DHT.

The Problem with the Relational Database (Part 2) – Predictability

• Introduction
• The Problem with the Relational Database (Part 1 ) –The Deployment Model

I met with a friend of mine in New York recently who runs a credit card processing end-point company.  They specifically built their business around a non-relational database platform and feel they would have major issues had they chosen to build their business around a traditional relational database.

In this business they process hundreds of transactions a second, this means that hundreds of people every second are standing somewhere in the world at a checkout making a purchase.  And if the transaction is delayed, that is a lot of people are standing and waiting.  Worst still if the transaction is delayed too long the transaction fails and the customer not only has to retry their transaction, they are likely embarrassed and probably somewhat annoyed.

The relational database certainly has the capability to scale to many hundreds of transactions a second. But the reasons for their move away from the relational database aren’t specifically scale related but instead come down to predictability and consistency.

Relational databases are not predictable or reliable in terms of consistent performance for a number of reasons.

Firstly, every query uses a different amount of resources.  A query could consume 1 or 2 I/O’s or 1 or 2 million I/O’s depending on how the query is written, what data is selected and factors such as how the database is indexed.  Performance is further varied by how the database is maintained (fragmentation).  What makes matters more complex is that different predicate values for a query can have vastly given data distributions.  The same query executed with different constants can have vastly different resource requirements.

Because every query has a different “footprint” running a query in isolation does not provide indicative statistics on how that query will perform under concurrent load.  In fact is become impossible to predict the exact execution duration of a relational database query as its performance will be dependent on what else is being executed at the exact moment it is.

Cost Based Optimization

Because queries can have complex execution steps behind them with multiple paths to achieving the result, one neat thing that was added to the relational database was cost based optimization.  This takes the control of “how” a query is resolved away from the developer and instead the relational database server works this out at runtime using a complex series of algorithms.  This was hugely important for simplifying the use of relational databases.  But it is bad for predictability.

Cost based optimization can get it wrong.  It is much less common now than 10 years ago but every DBA has still come across cases when the optimizer chooses the wrong “query plan” and the query execution takes a long time for seemingly for no reason.  But worse for predictability is cost based optimization is dynamic and looks at a lot of factors at run time to determine which plan is best.  These factors can change meaning that query performance can change (often without any external schema/code modifications).  This dynamic ability can cause headaches to DBAs who are often tasked with resolving performance issues when suddenly the database is “going slow”.

Example:

Ok let’s take a real world look at this problem.  I have gathered some stats from a real, production (SQL Server) relational database.  This database is around 500GB in size and processes ~700 transactions per second 24 x 7.  This data is just a couple of minutes of captured activity.

The first graph I am showing here is the # of queries based on resource usage.  To simplify things resource usage in my example = CPU TIME + # READS + # WRITES. 

Because queries in relational databases can have vastly different resource usage profiles, we get a very wide distribution of resource usage by query (note the logarithmic scale).
 

We can see that most of the queries executing on this database use <50 “resources” (CPU + DISK) but at the same time a smaller number of queries can use anything up to 22750 x this.  That is a massive distribution. 

Problems with predictability can start to occur when a number of high resource queries randomly end up running concurrently.  This restricts resources available to other queries and therefore the execution times of other queries execute at that time are affected.

We can see this by looking at the execution duration of ONLY the queries that have used 50 resources (CPU+DISK) or less.  They have a similar resource usage profile, so in theory they should all have a similar execution duration, right?
 

Unfortunately no.  This graph is showing the execution times for only the queries that used 50 resources or less.  While we can see that most of these queries executed in 100ms or less, many of these queries took a lot longer than this.  In fact there was a wide distribution up to 5297 x this base execution time (529 seconds).  All these queries used roughly the same amount of server resources yet their execution times were massively different.

The reasons for this could be many.  Firstly it could be resource contention.  Many of the queries taking longer could be doing so because they are being executed at the same time as a number of high resource queries.  Or alternatively, it could be because of resource concurrency issues.  These queries may be delayed because they are waiting for blocking queries to complete.  Or it could be because of internal database management issues (indexes updating), or it could be due to concurrent disk issues (log backups, check-pointing) and so on and so on.

These are in fact all issues that DBAs deal with and investigate on a daily basis.  The best you can do is to try and optimize as many of the reoccurring queries as possible.  However in doing this it still isn’t possible to accurately predict performance at run time, or ensure consistency of execution time at run time.  This is bad news when you are trying to use the relational database as a platform for applications where consistency of performance is paramount.

The Problem with the Relational Database (Part 1 ) –The Deployment Model

• Introduction
• The Problem with the Relational Database (Part 2) – Predictability

This is the first detail post in a series I am doing focusing on the issues that exist today with the Relational Database.  This first post is on the deployment model.  It could be argued that this isn’t directly related to the “relational database” but rather is an implementation model problem.  I disagree with this as many characteristics of the relational database lead to the deployment model described (we will explore in later posts).

For most of my career I have been involved with the enterprise and the databases in this environment.  Over the years I have seen the volume of databases increase dramatically in line with an increase of data centric applications.  This has led to even medium sized organizations often having dozens of physical database servers.   Enterprise organizations often have hundreds of database servers, occasionally thousands of them.  The volume does vary heavily by database platform however, SQL Server typically suffering the most sprawl out of all the mainstream enterprise relational database platforms.

Problems happen when DBA’s try to co-locate independant databases on a single server.  The problems are due to the dynamic nature of databases in terms of data volume and dynamic nature of query load.  This dynamic nature makes managing capacity a complicated and time consuming task.  When relational databases share resources you risk a small number of intensive database queries causing concurrent impact to a wider group of other queries.  Because of this, typically small numbers of databases share the same servers.  On average for SQL Server around a 10:1 database to server ratio is seen in the enterprise.

The brokenness of this model is pretty easy to spot.  Firstly, resource inefficiency and ineffective distribution is a clear problem.  While I am generalizing somewhat, an organization with 100 database servers often could have 70% of those servers vastly underutilized, 20% of those servers effectively used and 10% of those servers highly over utilized with users suffering from poor performance, “bottlenecks”, as a result.

 

With this deployment model it isn’t possible to take the unused “resources” (CPU, Memory, I/O bandwidth) from elsewhere in the organization and re-apply it to where needed (even with downtime, let alone in real time).  Instead new infrastructure investment is made to continually add new resource capacity for the bottlenecked databases.

A relational database is capped by the limits of the server on which it currently sits.  A DBA monitors the server trying to keep current query demands as optimal as possible to avoid premature bottlenecking, and continually planning to stay one step ahead of database requirements growth.  This is a costly process and one often not helped by the unpredictability of the relational database (which we will discuss later).  Multiply this need across the hundreds of servers described and you can imagine it is a significant contributor of the cost of ownership.

When you reach the limits possible on a single server many database platforms have few practical options available for further scalability (such as distributed scalability for reasons again we will address in a later post in this series).  Too often organizations with multi-million $ servers are being forced to split workloads, move real time operations to batch operations, replicate data for offline processing purposes and mandate specific times when users can run particular intensive functions.  Again, all this manual fiddling becomes a management nightmare and significant overhead when you multiple it out.

This issue in isolation can potentially be addressed through technologies such as virtualization.  While virtualization is yet to make major impact on the way in which production databases are deployed in the enterprise, this may change in the future.  However as we delve further into the problems associated with the relational database, we will see this is not the only issue that we face taking this technology forward.

Related articles by Zemanta

• Is the Relational Database Doomed? (readwriteweb.com)

The Problem with the Relational Database

• The Problem with the Relational Database (Part 1 ) –The Deployment Model
• The Problem with the Relational Database (Part 2) – Predictability

The relational database has been the core mechanism for structured data storage and retrieval for the past 30 years.  My career so far has focused around the relational database, whether it be from a development, administrator or investment perspective.  In all this time the RDB has been the best generic option available for developers building data centric applications.  The generic nature of the RDB has made it suitable for wide mix of application requirements, be they heavily transaction processing orientated or heavily data analytics related.

However over the few years we have been witnessing a slow shift aware from the “RDBMS” for everything trend that we saw over the preceding decade.  And this is occurring because the demands we are placing on data in terms of scale and volume are growing to a point where the most generic platform is underperforming and instead more specialist database technologies are starting to be selected based on their closer fit with the requirement.

This trend has started in and is therefore more visible in the data analytics space.  The specialist solutions have be slowly cropping up over the last 5 years and now today it wouldn’t be that unusual for an organization to choose a specialist data analytics database platform (such as those offered from Netezza, Greenplum, Vertica, Aster Data or Kickfire) over a generic database platform offered by IBM, Microsoft, Oracle or Sun for housing data for high end analytics.

My argument is that while I see the traditional generic RDBMS remaining the platform of choice for most generic application requirements in the foreseeable future two breakaway alternative paths are also emerging.  The first is that I mentioned above, a reduction in the generic aspects of the RDBMS with a specific focus on high end data analytics functionality.  The second, which I see starting to emerge right now, is the opposite of this.  A reduction in the generic nature of the RDBMS with a focus on the specific requirements of high end transaction processing.

Starting tomorrow I will be presenting a series of posts that discuss real world issues facing the RDBMS when used in transaction processing environments that are being encountered today to highlight why this alternative path in transaction processing is appearing then following this I will present a series of posts on the technology that is emerging in an attempt to address these weaknesses.

Some Observations on Venture Funding

I have been travelling a bit, speaking to a number of different people across a lot of different sectors.  Thought I would put down some of the discussions I have had in relation to the venture and financing sectors at the moment.

The Bad

In general it seems to be tough in the venture market at the moment.  LP’s are pulling some of the funds they have under VC management.  This is having a number of effects. 

• Firstly, VC’s aren’t really looking at seed funding.  Instead they are focusing on using the funds they have to invest in subsequent rounds in their existing holdings.  Those who are still doing seed funding are looking for large stakes, 50% or more.  That is a lot to give up in round 1.
• Secondly because of the LP pull backs many VC funded companies that are up and running and even producing revenues have had their funds cut early.  This is causing problems as revenues are typically < costs so they are caught short and paying bills becomes a problem.  So, many revenue producing software companies are seeking early exists due to the disappearance of investment funds.
• Because the economy is bad, many of the exit points for these companies are no longer viable.  The exit points that rely on raising debt or external funding to acquire are finding it much together to do so.
• Those exit points with large cash reserves (a handful or large software companies) are on a mini buying spree.  They are picking up viable, revenue producing software businesses.  And they are doing it cheap, often below 1x revenues (maybe as low as .5x revenue).
• The founders of these businesses who get caught short because of the funding pull are often ending up with very little if not nothing at all.

The Good

Things appear to be improving.  The mood in the US and Australia is better today than it was at the start of the year.

• Funding is still around but it is harder to get it and you will have to jump through more hoops.
• VC funding is a special class of funding that should only be considered in special circumstances.  These include 1) when rapid time to market is critical, 2) when you need to run for a long period of time before starting to generate revenue (there are others).  But in all cases you should only consider VC funding if you have a model which has a practical path to substantial return on investment within a 5 year timeframe.  HINT: most “software” start ups don’t qualify for this.
• Starting companies that follow a more traditional path to revenue and eventual profits should use a more traditional set of funding mechanisms to achieve this.  That is self funding, angel investors or private equity. 
• In all cases you will be in a better position to receive funding on better terms if you have something real to market and you are producing revenues.
• Getting funding to acquire, do a management buyout, or spin off an existing technology may get you more air time with investors currently than proposing your build something from scratch.  Of course success here comes down how well you convince the investors of your ability to add value to that technology and why this hasn’t happened to date.

I am sure I have forgotten a few things in which case I will post them as updates to this post later.