Log in

No account? Create an account

Databases, The End User Experience

« previous entry | next entry »
Jul. 29th, 2010 | 10:11 am

Does it matter if the end user knows what the database is?

Recently I got a wonderful view of a database from the end user perspective.

While I was traveling I had found a restaurant where I had decided to let friends who live locally know where I was at. Part way through my food I got a message from a local friend that said "Don't eat there, their food always makes people sick!"

"Always" is a word that I would think would be a little too strong when applied to a restaurant, right?

Nope, the next day I got to feel the full truth of the word.

A couple of days later I am telling some friends about this and a local asked me "Where was this, I want to avoid them." I didn't get asked this question once, I got it asked a dozen times.

I don't know where the place is. Why is that? Because the system I was using lost the entire day worth of my data. I don't know how often they loose data, but from asking a few other folks it appeared to be that it is more frequent then not.

It came up in casual conversation the other day that the site had moved off Postgres to another system recently. Which suddenly made everything make sense, because the particular solution they moved too is not very durable.

We talk about databases being "transactional" or not. We talk about them being "durable". What matters in the end, to me as an end user, is that when I put my data in a system, I want a confirmation that the system stored it. I don't want to retype my data, and I don't want to collect it again. If I was the operator for the site? I certainly wouldn't want to be losing my users data.

In the MySQL world? MyISAM is the most abandoned storage engine in the stack. People will pick it initially because it is fast, but the first time they discover data corruption or have to deal with multiple hours of recovery time they quickly move away from it.

As an operator I wouldn't want to be having to explain to my users or my boss, that we had to wait 12 hours until the database recovered itself (or that it had corrupted itself). "Transactional" systems know how to handle recovery. People will wave their arms about and talk about disk controllers, disk failures, etc... That is hand waving. A properly configured system is redundant and sure it can be hit by lighting, but the real issue is most likely going to be that a plug gets pulled or a program crashes.

I look at, and even work with, some of the "no-sql" solutions. Some of them I recommend, and other's of them I don't. I look at scale out needs, usage patterns, and a wide variety of other details.

As end user though?

I would like to know that my data was stored, and that I will reliably be able to retrieve it when I want. I don't like outages. Of the services online that I pay for or that I have integrated into my life? I can't imagine wanting to deal with a system which was unreliable. A free service which does not work most of the time, is not free. It will consume my time whenever it is not available.

There is an end user experience for the database, site operators ought to remember this.

Link | Leave a comment |

Comments {4}

Mark Atwood

(no subject)

from: fallenpegasus
date: Jul. 30th, 2010 08:21 pm (UTC)

One of the things I took away from NoSQL Live in Boston is that the standard "MySQL master/slave with replication" is even worse than most of the NoSQL solutions out their already, not even having an "eventual consistancy" guarantee, instead having a "wishful consistancy".

On the other hand, some of the very popular NoSQL solutions right now are really bad. The one that you mentioned without naming, 10gen's MongoDB underlying Foursquare, makes no attempt at all to be durable.

I sometimes quip that MySQL 3.11 became popular a decade ago because it fit very well to quickly and poorly written PHP3 apps. MongoDB may be the modern version of that, fitting very well to quickly and poorly written Ruby apps.

But I fear that because 10gen MongoDB is the one that has VC mindshare over other, technically better, document stores and other NoSQL stores, it might win on the "worse is better" principle.

Reply | Thread