Slashdot Mirror
Open Source Database Underdogs
implex writes "Interactive Week had an article called "Data Underdogs" which they compare offerings of present Open Source Databases with present commercial offerings. In one part they mention ...On the other hand, MySQL developers now have a much-needed transaction management system: NuSphere last month made its Gemini transaction manager for MySQL available as open source code on mySQL.org, a site that the company recently launched. Complicating matters, though, is NuSphere's blood feud with MySQL AB, a Swedish company that runs a competing open source development site for MySQL code at www.mysql.com. No mention of the fact that MySQL AB actually created the product was interesting."
Well, when people talk about market share it is usually by revenue, and given the low price of Open Source databases I'm actually surprised it's even as high as 3%.
But 3% of revenue might actually add up to a fairly substantial proportion of installations.
I don't think you're likely to find that happening on the commercial level. It was so long ago I don't even remember where I read it (though it's the sort of thing that a /. poster might say), but I once heard it said that acknowledging bugs is probably a great way to tick off your investors.
"What, there's a flaw in your product?"
"Yes, but we can fix it pretty easily -- have the bug fix out tomorrow..."
Whereupon the non-technically-inclined investor writes the developer's comments as a sign of weakness and sells. I think that's also why commercial bug fix releases are such a big deal -- probably Microsoft's other reason for cramming all kinds of new features into their service packs.
/Brian
What's the problem here? We've got and open source database that's being developed in two somewhat different directions by NuSphere and MySQL AB ... seems like in the end it'll lead to two different, but each (for their intended applications) excellent products. I just don't see a problem.
Maybe I'm just being dense (first reply: "Yes, you're fscking dense!")
Actually, I've noticed a growing trend in the crowd of programmers I run with is not to care about the implementation platform.. SQL is SQL, and you don't do transactional based stuff on the platform anymore, you abstract away from that into your middleware, and do things the way you want to. In REAL LIFE programming, you often don't have the chance or opportunity to spec out what your back-end platforms are, you have to deal with what's given, or what's legacy at Company XYZ Inc. You also are often dictated a programming langauge for the project whether it be java, c, cobol, perl, python or whatever. The real value lies in being able to adjust to whatever the PROJECT calls for, and being able to implement on just about any platform you need with strong good design patterns. MySQL and Oracle both do exactly the same thing from my point of view, hold data in a relational format for storage and quick retrieval. Putting too much logic into the database only serves to slow things down in the long run. Nasa Switches from Oracle to MySQL shows us why Oracle putting all those bells and whistles in their product may lead to a weakening of their marketshare ultimately. The fact is, bells and whistles cost memory and processor, and there's a balance between the two that Oracle seems to be blithly ignoring.
No. The point is that the design of a great DBMS takes a lot more unity than the large-scale projects OSS has tackled previously. In a DBMS, there must be an internal set of standards for everything from datatypes to join optimization logic.
Databases just don't lend themselves to fragmented development the way operating systems do. Frankly, I'm skeptical that an OSS project could (using current development practices) pull together and produce something as capable and stable as DB2 or Oracle.
While I appreciate the sentiment of the article, it seems rife with misinformation. For example:
"Another feature that NuSphere is adding to MySQL is replication..."
Er, I'm pretty sure that's been in there for quite some time, through the master/slave system.
"The language resembles Oracle's PL/SQL (Procedural Language/SQL), except that PL/pgSQL offers the use of functions only, not procedures. A function call always returns some result, while a procedure may execute certain operations without returning a result."
Wow, that's certainly earth-shattering. Just discard the result. Cripes.
"PostgreSQL, like MySQL, also doesn't provide any native replication capability."
Maybe I misunderstand replication, but what's the matter with:
$ pg_dump mydb | bzip2 > dump.bz2
$ scp dump.bz2 newdb.host.com:
$ ssh newdb.host.com "pg_create mydb; bunzip2 dump.bz2 | psql -e mydb"
"But some Web businesses are finding that they can function perfectly well with open source databases."
Yeah, I guess the features I like are speed, stability, ease of deployment, and excellent development tools. PostgreSQL and MySQL have all of this in spades; the commercial databases I've worked with usually seem clunky and contrived by comparisson.
Imagine that, a consultant that not only lowered the maintenance and upgrade fees for his client, but also delivered a solution that was easier to maintain and ran faster to boot. I bet the port wasn't even that difficult. PostgreSQL is getting to be quite competitive feature-wise.
Believe it or not, this is precisely the type of things that most employers want. However, most IS groups are too busy with CYA tactics to ever even worry about providing the best solution for the job. They just want to choose software that is safe, and in those cases the more expensive it is the better.
Your response was literally the funniest thing that I have heard in some time. Someone replaced DB2 with a low-cost, low maintenance PostgreSQL solution, and your suggestion is that he should have instead spent his time reading some arcane IBM manual.
Companies keep everything on database systems. Hundreds of geek-hours must go into the design of a database application for a company. Whatever system a company chooses, they must be reasonably sure the system will:
- almost never fail
- be supported by a stable company and
- integrate well with other systems, into the future.
A smaller price tag may be a good start to target smaller companies that don't rely heavily on database applications, but the reason Oracle can charge $15k/CPU for 9i Standard: the reputation is worth it.Somehow, Oracle is saying that the Open Source comunity is not 'capable' of producing a dominant database...
Not being overly qualified on the issue - but I thought they would both involve much the same issues - concurrency (e.g. - SMP in OS's), failsafe (Hot swap raid, clustering, and a few features yet to be developed for linux), reliabilty/stability (Linux has this!), efficiency, etc etc. It seems several Free OS's have solved all the issues that database manufacturers would face - so what are they claiming could be so complex that Free software people couldn't cope with?
TimC.
MySQL has two table types that support row-level locking and transactions. One is tied up in this contractual mess, but the other, InnoDB has no such issues, and may even be faster for many purposes.
Actually, Interbase can do "hot" backups and has support for replication.
People really ought to look more closely at Interbase. It just works.
Did I say immediately? No. Given the course of programing languages over the last 20 years, object models seem the not too distant future for database applications. Whether they work well or not is a question of both preference and application requirements. Of course new vendors will not leap at the chance to use an unfamiliar database model, and the money backing the relational models upon which several major DBs are based is pressing for it to stay that way. Of course people in support of the ODM are on the fringe right now, but so were Linux users just a few years back. If we stuck with the dominant model in all things, we'd have never progressed.
Bah ! I remember in the early 80's when big iron buddies used to point ant laugh at dBase II. What they didn't understand, and what some of the big database boys and users don't understand now, is that larger isn't always better.
Databases like MySQL make it very easy for webhosting companies to offer free databases without loosing their shirts or minds. They make it very easy for students to learn SQL. They're also much kinder on resource.
Yes, I'd love to be able to roll-back pooched transactions, but then I have to commit everything as well. Certainly cascades would be slick, but poorly written, they can shoot your foot clean off. Likewise, I can see all the lame support calls coming in because users don't understand the triggers are attempting to maintain referential integrity on foreign keys.
Within a given context, sometimes smaller is suits the purpose better.
healyourchurchwebsite.com - WWJB?
If a database goes wrong (and in Oracles case, my experience is that that's often), and we can't solve it ourselves, we need to be able to get on the phone and speak to somebody who can help. Now, I know that there are companies that offer support for OS DBMS's, but Oracle, Sybase and IBM's round the clock support offering is what i'm after. and getting skilled technicians (possibly the development team itself) involved quickly. OK, so open source offers this as by merit of "use the source luke", but in a corporate environment, this is neither likely or necessarily sensible.
Another, and perhaps more important, aspect to bear in mind (and this is not covered by the article for obvious reasons) is that Oracle, Sybase and DB2 are not the be-all and end-all of RDBMS offerings. There are better, and often significantly cheaper, closed-source offerings out there. One of my current favourites (which I'm working with at the moment) is Clustra - a DBMS that offers 99.999% availability, scheduled and unscheduled, pretty much out of the box, with Linux as their first released OS for the latest 4.1 offering
So, in a nutshell - Open source support offerings need to be improved, but don't rule out the smaller fish in this crowded, and very competitive pond.
Who said databases were boring?
ooooooh! What does this button do? - DeeDee, Dexters Lab.
I don't think you can "abstract away transaction related stuff" from the RDBMS. Please correct me if I'm wrong; but I believe that you simply can not start with a RDBMS that does not support transactions; and slap a transaction processing middleware on top of it to instantly have a database application with transactions.
The standard transactional interfaces that are increasingly becoming popular nowadays (like JTA) depend on the database supporting transactions; most likely in the form of an XA-conformant programming interface.
Zigbee Central: A Zigbee weblog
OSS projects probably could produce something similar to Oracle or DB2, in time, but is there a Open Source market for the features that make Oracle and DB2 special?
For example, how many users of PostgreSQL, MySQL, etc. are planning on setting up a database that can stay available through nuclear attack or power grid failures? Generally, these super-duper robust databases get set up on several "big iron" servers, which means the licensing and administration for Oracle or DB2 just isn't that big of a deal relative to hardware costs, site construction costs, and staff salaries.
For certain projects, paying for Oracle or DB2 can actually save a heap of trouble, since they are so damn capable. This can make them more than worth their price.
On the other hand, I cannot advocate these super databases for small projects. That's where the current OSS databases fit in quite well. Therefore, would OSS really benefit from trying to compete with Oracle and DB2?
Healthcare article at Kuro5hin