Creating a cloud database?

Question

As cloud computing seems to be one of the most popular topics, It got me thinking, And as i dont know much about the topic excuse me for any ignorance in the question.

What exactly is a cloud database and how would this service even be created. Would it simply be a MySQL database with a web frontend that would allow users to create their own databases/forms/report/relationships from their browser. Again, excuse my ignorance on the matter.

Whilst browsing i came across this InfoDome Product and it says that this is an online database. What exactly is the difference between this and a cloud database? also, if you look here at the video demo (http://vimeo.com/9132578) of the product it allows the user to create database forms and reports by using a drag and drop interface, How did they go about programming this feature because i found it very impressive.

Thanks for any help in clearing up my confusion.

Answer 1

It is incredibly difficult to have a true database in the cloud because of acidity. Data stores are a different issue entirely. Data storage does not have to be a classical database, in the sense that you might know it. Cassandra and other key-value data stores offer a lot in the sense that they are fast with reads and writes, but difficult to report against. If you have little need for reporting, and speed is your primary concern (meaning you have a very large dataset where joining is not important, which it is typically not in the classical web sense) then something like that is very valuable.

When you are doing large amounts of data-munging and etl work, then a classical database with highly stable and very high performance hash joins can occur is very valuable, but that can even be replaced with a Big Table implementation with a Map Reduce piece of code running over many machines, and you will get good fast results. A Big Table implementation has been built over Hadoop, so you might want to look there.

In memory data stores that are used for very fast retrieval (such as memcache) have uses too, as long as you aren't worried about filling the cache at runtime when an object is regularly pulled on your website.

Unfortunately, once you start applying transactions, and other parts of acidity, to any data store, it becomes much harder to manage. That's why so many non-classical database data stores give up on some of them, in order to get a performance boost.

I don't think that 'Cloud Database' is the right way to look at the problem, instead a 'Cloud Solution'. Cassandra, as a data store, can be thought of as a 'Cloud Solution' to a very big problem: For very large datasets (Facebook, among other sites, use it), how can we get the best performance? If it means that not all clusters will be up to date after a post, then so be it, as long as everything runs smoothly.

An 'Online database' - as they say for infodome - is interesting verbiage. I think of an online database as a database that is running (and that can perhaps be connected to). What I think that they mean is a web-accessible database, which is different. To build a site like that, you probably need a decent knowledge of some kind of datastore, technically, anything that doesn't drop data (Memcache drops data, cassandra does not, postgres, mysql, oracle all are classical databases, so they are good) should work. Then you would need to learn how to code a website, I would recommend that you start with something with a large set of active users (Ruby On Rails, Drupal, although I've never used either, are easier than Perl Catalyst, which I prefer, but is apparently harder), then learn how to build effective client side javascript, and produce a meaningful xml or json api to your application.

Unfortunately, that's a lot of work. I've been in the industry for years, and I promise you, you will be at this for a while before your knowledge is up to snuff enough to write your own application with that level of complexity. When you think about facebook & twitter, they didn't start with that level, but as they grew, their primary issue was scaling, not application complexity, which is different.

Either way, I hope that I answered a few questions and pushed you in the right direction. If not, that's fine too. Just typing to burn some time here.