Showing posts with label dbms. Show all posts
Showing posts with label dbms. Show all posts

06 June 2008

Aster Data Systems

More database scalability. This is an interesting offering. Read about Aster here, here or here.

19 January 2008

Why Programmers Don’t Like Relational Databases

This article was written a few months ago, but I just happened upon it. It makes some very good points about why many programmers view DBA's as evil.

Inflating MapReduce

There has been a lot of coverage regarding the Database Column's take on MapReduce.

Greg Jorgensen wrote a good rebuttal. A little too good... That bit about replacing 'MapReduce' with 'SimpleDB' was going to be my angle! There are also some good comments, on Slashdot.

I can see where DeWitt and Stonebraker are coming from and I agree with many of their points--though in general, and not necessarily related to MapReduce. I think that they failed to fully frame where they are coming from. They reference universities teaching MapReduce; is this an academia trend that they are seeing? Do they perceive MapReduce as being tought in lieu of relational theory? Now that would be cause for concern as they solve two different problems. Google is not claiming that MapReduce is a solution to data management, are they?

One point that I feel compelled to partially defend DeWitt and Stonebraker on is one that everyone seems to be having a go at: "Given the experimental evaluations to date, we have serious doubts about how well MapReduce applications can scale." Many people are saying, "Scaling? Google? That's a laugh!" They have a point, but they are only considering scaling in one direction; Google's data is largely narrow. Do DeWitt and Stonebraker mean scaling horizontally? Or do they mean performance acceptably scales with the hardware? Again, I think that they failed to frame their argument. As well, they failed to justify their reasoning on why MapReduce is their target.

A few months ago Stonebraker called RDBMSes "legacy technology." My interpretation, he was saying RDBMSes are not one-size-fits-all and you should buy his product because it is column-oriented and it is really fast... for data warehousing. To his credit, he does say that DBMS engines should allow for vertical internals. With the escalating sizes of databases, I imagine the larger DBMS players will get around to this. Is he threatened by the "new" technology he asked for a few months ago? Or maybe he wants publicity for his product? Either way, wearing business and theory hats at the same time is not good practice.

16 January 2008

Sun Buys MySQL

There is a lot of coverage about Sun's billion dollar purchase of MySQL.

I am hoping that Sun is able to restore its empire. They made some serious mistakes in the past, and took a hard fall for it. But maybe they really do want to become a serious company for the Data Center. MySQL is not a perfect DBMS, but it is a very solid product. Sure, there are some design... choices... that are outside of the conventional DBMS, but it also has some great features. I hope that Sun makes good on this purchase and that it ultimately benefits MySQL and the MySQL community.

08 January 2008

LongJump's Database Service

LongJump enters the no-maintenance-scalable database trend with Database-as-a-Service. This sounds like an interesting offer. Though the site is a bit slim on the details, they offer a 30-day free trial. They are also billing it well... unlike some simple services. Instead of toting DBA's as worthless, they say 'You don't need to have a certification in database management, just a desire to optimize your information.' Well put.

Read more at TechCrunch.

Anyone else hoping that this is successful?

21 December 2007

IBM's Solid Stance in Memory

IBM is acquiring Solid Information Technology for the in-memory database product:
IBM buys database software firm Solid Information

IBM Buys Database Software Firm

MySQL in the firing line again as IBM snaps up SolidDB--Hopefully IBM's open source initiative will override its DB2 centric mindset, as a comment pointed out while linking a reference.

A few years ago DB2 had the second largest market share in the DBMS world--not sure if that still holds (Anyone?
This is the most recent article I can find siting numbers, but this has more figures though it is older). Oracle is still well seated in the world of web applications, but larger institutions still trust Sybase and DB2 more (is that vendor faith, or [don't want]/[not economically viable] to migrate?). Of course, Sybase has a very dwindling share of the market. I am curious to see how MySQL has fared in the past year with its growing popularity and release 5 making it that much more of a contender. I would think (and sort of hope) that they have been edging out Oracle. End of tangent.

In any event, it is good to see IBM continuing to adapt; not an easy feat for a giant company.

Also in IBM news,
"IBM Finding Business Uses for Virtual World".

15 December 2007

Amazon's SimpleDB

Amazon is entering the DBMS market... With a non-DBMS?

Let's look at the article found at http://aws.typepad.com/aws/2007/12/a-place-for-eve.html.

"Amazon SimpleDB makes it really easy and straightforward to store and to retrieve structured data. You no longer need to worry about creating, maintaining, or migrating database schemas, monitoring and tuning the performance of your queries, outgrowing the storage or processing capacity of your database server, making backups, or replicating data."

Already I am confused... 'retrieve structured data,' 'no longer need to worry about creating... database schemas.' But... structured data... schema... structure... schema... Do you see my confusion? Let's read on...

"Instead you simply create up to 100 SimpleDB domains (each of which can hold up to 10 GB of data, for a total of 1 TB) and then start to store structured data in the form of items."

So, create a database and put some tables in it? 'Item' is a very vague term. 'Domain' has a few meanings in the IT world, and a very specific meaning in the database world. But everyone brands their own terminology...

"Each item consists of multiple name/value pairs (which we call attributes)"

Novel idea.

"With SimpleDB there is no need for a time-consuming schema change when you need to store additional information in your database. You simply store the additional attributes as desired."

So domain became database. And we are adding columns where desired. How is this not maintaining a schema? More accurately, this is what programmers often do when there isn't a DBA around to smack their wrists... So again, I fail to see any innovation.

"For example, if you were building a tag cloud to represent information about a collection of web sites, you could store the site URL as the first attribute and the entire set of tags as the second."

So it has object oriented capabilities? Cool! There are people that would really like to see that functionality.

"After the system has been running for a while, you decide to add a thumbnail for each URL (of course the Alexa Site Thumbnail Service would be perfect for this) and simply add a third attribute to the new entries. Later, as desired, you can go back and add this attribute to the older entries. This ability to improve your data model on a dynamic, as-needed basis makes Amazon SimpleDB a perfect match for today's fast-paced world of agile development, where flexibility and adaptability are of paramount importance."

ALTER TABLE.

"Applications which require long-running queries and/or complex table joins, such as those for data warehouse applications, are probably not a good fit for SimpleDB today. While RDBMS offerings provide deep functionality, for many use cases, they introduce more complexity (and more cost) than is necessary. Many developers simply want to store, process, and query their data without worrying about managing schemas, maintaining indexes, tuning performance or scaling access to their data."

This sounds like data management, '80s style.

I love Amazon. I think that they are a great company with incredible customer service. It took them years to get in the black and I rooted for them the whole way. Even this nonsense does not turn me off to them. However, I do hope that they revisit their presentation. There are many many reasons why the relational model is better than flat-file and hierarchical models. Dismissing the relational model, RDBMSes and DBAs as by and large unneccessary is ludicrous. Especially when you can't even get away from the basic concepts and terminology in your 'solution.' I also doubt that SimpleDB will be able to scale very large while remaining cost effective--it is simple, after all.

After glancing at links referenced at the bottom of the article, particularly the FAQ, this really does not sound like a bad product for what it is intended to do (or at least how I could see it practically being used (it is a redundant, affordable directory service for data; which has great potential for web applications). How they are billing it though is rather ridiculous. I really hope that I have completely misunderstood this and/or this will have a positive impact on the data management world.