homepage Welcome to WebmasterWorld Guest from 54.205.241.107
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / Databases
Forum Library, Charter, Moderator: open

Databases Forum

This 38 message thread spans 2 pages: 38 ( [1] 2 > >     
Oracle Acquires InnoDB
antonaf

5+ Year Member



 
Msg#: 75 posted 3:10 pm on Oct 9, 2005 (gmt 0)

I was reading [oracle.com] that Oracle has acquired InnoDB what does this mean for the future of MySQL?

Will MySQL include its most powerful storage engine into future updates?

I do not know why MySQL didn't go ahead and purchase InnoDB long time ago, knowing the importance of this storage engine. Hopefully, they will have a strong supplement to InnoDB which will allow them to continue on without it.

Oracle is a corporate giant and I believe this acquisition was intentional to cripple MySQL or have them at their mercy. I do not think Oracle goal is to have a GPL relatiionship with MySQL they will go forward with commercial licensing, I'm sure. I am also disappointed that InnoDB allowed this to happen, knowing the great influence it has had on the open-source community.

Oh! Well that's what you get when you have a kid in the basement coming up with bright ideas.

[edited by: jatar_k at 7:54 pm (utc) on Oct. 9, 2005]
[edit reason] to press release [/edit]

 

txbakers

WebmasterWorld Senior Member txbakers us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 3:23 pm on Oct 9, 2005 (gmt 0)

That is indeed scary news.

There is nothing warm and cuddly about Oracle. Their hostile take over of PeopleSoft is still smarting, and this doesn't bode well for mySQL.

Time to start learning SQL Server?

aspdaddy

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 4:13 pm on Oct 9, 2005 (gmt 0)

A good move as Oracles database doesnt compete directly with MySQL or MS SQL. In fact the db market is interesting Access, MySQL, MSSQL & Oracle all have distinct markets. Im sure theyll keep everyone guessing for a while what the plan is :).

mack

WebmasterWorld Administrator mack us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 4:36 pm on Oct 9, 2005 (gmt 0)

This will be very interesting. InnoDB is currently GPL'd so in theory Mysql can continue to distrinute and modify the InnoDB engine.

Another importaint point to bear in mind, is If Oricle intend to use the InnoDB engine as part of their own software then need to release into the community and modifications. To take something out of Open source into proprietory ownership of code is not an easy task.

It all comes down to the terms of sale between InnoDB and Oricle.

Mack.

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 5:00 pm on Oct 9, 2005 (gmt 0)

Time to start learning SQL Server?

Time to consider using PostgreSQL. MySQL is not all cuddly either -- their recent licensing policies regarding drivers needed to access MySQL server are just way over the top.

Oracle bought InnoDB in hope to stop assault on its database from MySQL side -- sure InnoDB may be open source, but people who work for it aint, so its likely somebody else will need to develop it, and its not that easy. MySQL itsels used this aggressive approach -- bought developer of .NET access drive and all new versions are under new license.

encyclo

WebmasterWorld Senior Member encyclo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 5:08 pm on Oct 9, 2005 (gmt 0)

InnoDB is currently GPL'd

This is the key - even if Oracle get the agreement from every single developer who contributed to InnoDB to change the license and go closed-source, the current GPL version can still be forked by the MySQL team (or anyone else) and continue to be used under the original license terms.

The difficulty comes if all the developers go to Oracle, who would take on the job (and pay the developers) to continue development of InnoDB? Hopefully, MySQL AB or another high-profile open source company will be able to step into the breach if required.

mack

WebmasterWorld Administrator mack us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 7:49 pm on Oct 9, 2005 (gmt 0)

InnoDB is not a standalone database product: it is distributed as a part of the MySQL database. InnoDB's contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship.

That part is interesting. Pay to play?

Mack.

txbakers

WebmasterWorld Senior Member txbakers us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 12:30 am on Oct 10, 2005 (gmt 0)

PostgreSQL looks very interesting. All the functions without the Hype of the mySQL.

The big question though - what would be the ASP connection string for it? I couldn't find it on a cursory glance through the docs.

mcavic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 1:15 am on Oct 10, 2005 (gmt 0)

Time to start learning SQL Server?
Time to consider using PostgreSQL.

Nope. Time to grab your latest copy of MySQL and keep it safe.

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 1:23 am on Oct 10, 2005 (gmt 0)

Nope. Time to grab your latest copy of MySQL and keep it safe.

And who is going to fix bugs and security holes in it? Software is fluid, very few important programs can be used unchanged for more than few years.

mcavic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 1:37 am on Oct 10, 2005 (gmt 0)

bugs and security holes

A valid point, but if I'm running a standalone server with stable releases of everything, new bugs shouldn't be cropping up.

And if I'm not accepting inbound MySQL connections from outside machines, MySQL shouldn't have any security holes that concern me.

Anyway, I'm not really concerned. MySQL will cope if necessary. Their user base is too big not to.

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 1:55 am on Oct 10, 2005 (gmt 0)

I'm not really concerned.

Me too -- I use PostgreSQL as I had enough of MySQL when they:

a) changed authentication scheme in 4.1.x
b) changed license for their access drivers (former ByteFX client)

The source for ByteFX is still available, but the primary developer is now working for MySQL (good for him by the way), and in complex non-trivial projects it is not just easy to find someone to pick them up and maintain.

This is the reason why Oracle bought InnoDB, they would have preferred to buy MySQL, but the price must have been too high so they decided to strike it in place that would make it harder for MySQL to be accepted as replacement for Oracle.

Check the last version of ByteFX driver on Sourceforge site -- its March 11, 2004 and that version does not support new authentication scheme (AFAIK), this is what MySQL did to users of the driver and this is what Oracle will do to MySQL.

Namaste

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 6:02 am on Oct 10, 2005 (gmt 0)

wow, shocking.

how is Postgres looking?

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 12:26 pm on Oct 10, 2005 (gmt 0)

how is Postgres looking?

The biggest issue with PostgreSQL I had was necessity to "vacuum" it regularly as otherwise performance would fall to unacceptable levels (and I mean unacceptable), this vacuuming is a slow process that can pretty much lock out database so its not easy to have 24/7.

Now take my words with a pinch of salt -- I am not expert in PostgreSQL and I am sure there are ways to tune it to avoid the issue I described before, in my case it was not critical, more of an annoyance really. Since the database is superb overall and free, I can't really say that problems with PostgreSQL were big enough to switch to Oracle or even SQL Server (which I actually prefer due to long experience with T-SQL syntax, but I am not paying ridiculous amount of money they want).

txbakers

WebmasterWorld Senior Member txbakers us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 75 posted 12:46 pm on Oct 10, 2005 (gmt 0)

OK, now you'll need to elaborate on that. What do you mean by vacuuming?

And how bad is the performance? Would an occasional reboot take care of the problem, or is it just not designed for heavy lifting?

Please tell...

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 12:53 pm on Oct 10, 2005 (gmt 0)

Vacuuming is a procedure that cleans up database -- re-arranges data and recalculates statistics for indices. The reboots won't help because reboots don't change data on disk (never had loss of data with PGSQL despite many reboots by the way).

PostgreSQL people recommend running it regularly and from my experience you really neeed to do that as otherwise database performance degrades over time.

How often you need to run will depend on database usage -- if you mainly read data from it then you don't need to vacuum often at all, but if you update/insert then vacuuming is essential. As I said I am not an expert on PostgreSQL and I am sure there are tuning parameters that limit necessity to vacuum it, all I am saying is that you have to consider it and can't just leave database hanging for months like it can probably be done with MySQL.

Run a search for postgresql vacuum on G for more info -- I'd love to tell it here but I don't want to upset PGSQL guys who did a fine job by giving possibly incorrect information about that DB :)

woop01

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 2:55 pm on Oct 10, 2005 (gmt 0)

Is vacuuming synonymous with reindexing on SQL Server?

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 2:59 pm on Oct 10, 2005 (gmt 0)

Is vacuuming synonymous with reindexing on SQL Server?

I think vacuuming goes further -- during this process data in the whole database or selected tables get physically re-arranged with deleted tuples removed thus reducing amount of IO it takes to scan data, also index stats get updated etc.

Its best to read up on what VACUUM does in PostgreSQL.

The things that I am clear about are: you will need to VACUUM database from time to time (period depends on usage).

Having said all that I doubt PostgreSQL is a good replacement for MySQL for web service tasks (ie mainly read only OLTP work).

jimbobway

10+ Year Member



 
Msg#: 75 posted 5:07 pm on Oct 10, 2005 (gmt 0)

[mysql.com...]

Namaste

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 5:08 pm on Oct 10, 2005 (gmt 0)

According to Marten Mickos, CEO of MySQL, "This announcement represents further validation of the open source movement. The beauty of open source software and the GPL license is freedom. As with all MySQL code, InnoDB is provided under the GPL license, meaning that users have complete freedom to use, develop, and modify the code base. We are pleased to see even broader industry acceptance of open source database technology. This also means that database developers now have even greater flexibility to use MySQL and Oracle in the same environment."

[mysql.com...]

mcavic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 5:18 pm on Oct 10, 2005 (gmt 0)

Yes. Also, from the first article:

InnoDB's contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship.

The spirit of both articles is that Oracle wants to contribute to the community by fostering InnoDB. Of course, Oracle is a public company, and thus should be expected to act in their own best interests. But I just don't see much of a threat.

Lord Majestic

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 5:26 pm on Oct 10, 2005 (gmt 0)

Of course, Oracle is a public company, and thus should be expected to act in their own best interests.

Indeed -- and what's Oracle's interest in supporting database that users can use for free rather than pay obscene amounts of money for Oracle's DB license? InnoDB is what was making MySQL actual "RDMS", not just flat file reader, this is done by Oracle in self interest to make sure that MySQL won't convert into Oracle's challenger.

Indeed Oracle acts in self interest, but don't be mistaken to think that this interest is alligned with those who produce free databases.

bcolflesh

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 5:49 pm on Oct 10, 2005 (gmt 0)

The developer tried to sell InnoDB to Oracle before partnering with MySQL - I'd like to see the differences between those two offers - LOL.

Row-level locking is possible in MyISAM (5.1 dev) and most InnoDB features could eventually exist with BDB and some other combo I'm sure.

Or they could just partner up w/:

[janus-software.com...]

decibel

5+ Year Member



 
Msg#: 75 posted 8:11 pm on Oct 10, 2005 (gmt 0)

Before I go into what this probably means for MySQL, I'll answer some of the PostgreSQL questions:

PostgreSQL uses Multi-Version Concurrency Control instead of locking to provide ACIDity. This means that every tuple (row) in a table has data that indicates what transactions are allowed to 'see' that tuple. So when you delete a tuple (and update is actually the same as insert/delete), the tuple isn't immediately removed. Instead, it's marked "deleted as of transaction #so-and-so".

Of course, the downside to this is now you have a tuple in the database that will eventually be doing nothing but taking up space. This is where vacuum comes in. It scans through the table and when it runs across a deleted tuple, it checks to see if any transactions currently running can still "see" that tuple. If none can, it will remove the tuple, reclaiming the disk space.

Of course, that's a high-level overview. When it comes to vacuuming, your best bet is to use pg_autovacuum (versions before 8.1), or to enable the built-in autovacuum in 8.1. This will handle 90+% of users in a painless manner. Note that pg_autovacuum will exit if the database is stopped, so you might want to use the scripts at [cvs.distributed.net...]

You can also throttle vacuum so that it doesn't clobber your server while it's running.

Something else to consider is that the out-of-box configuration for PostgreSQL is *very* conservative. It's meant so that you've got the best possible odds of being able to start the database, even if you're on an old 486. Of course this also means that there's some big performance gains to be had from tweaking a few parameters.

--
Jim Nasby, Sr. Engineering Consultant

[edited by: volatilegx at 9:22 pm (utc) on Oct. 10, 2005]
[edit reason] fixed sig [/edit]

jeff95350

5+ Year Member



 
Msg#: 75 posted 8:15 pm on Oct 10, 2005 (gmt 0)

Trying to clear up a couple issues:

InnoDB is GPL, and that means that an open source developer could pick it up and continue development. However, MySQL cannot include it in their commercial product without Oracle's permission, which almost certainly means they will drop it from the commercial version and open source version alike. After all, they don't want the commercial version to be worse than the open source version. That means that InnoDB would be a separate forked project, and may or may not be successful.

Regarding PostgreSQL:

It's a good product, certainly take a look if you're concerned about MySQL.

A couple people made comments about VACUUM being a problem, but it isn't really a problem anymore. In fact, v8.1 (in beta right now) has an autovacuum process, and you can just turn that on and forget about it. Also, VACUUM does not actually rearrange much data on disk, it merely marks old deleted rows as "dead" so they can be reused. If you specify "VACUUM ANALYZE" it also collects statistics which are used for the query optimizer, which can help performance. Neither of these processes interfere much with normal activity (they don't prevent concurrent reading or writing to the tables).

However, VACUUM FULL does interfere with normal database activity. It rearranges many of the rows in the table to pack it tightly to save disk space. It's unecessary for most situations, even for most 24/7 systems.

And I'm not sure why someone mentioned that PostgreSQL doesn't work well for websites (read-mostly OLTP). It works for me. It should have comparable performance to InnoDB. MyISAM, I hear, is significantly faster than PostgreSQL for low concurrency.

decibel

5+ Year Member



 
Msg#: 75 posted 8:17 pm on Oct 10, 2005 (gmt 0)

I think folks are missing a few points about what this means for MySQL.

First, while there is a GPL'd version of InnoDB, that does MySQL absolutely no good for their commercial version. Granted, a user of the commercial version could obtain InnoDB on their own and use it, but then they'd still be using a GPL'd database. If they're going to do that there's a good chance it doesn't buy them anything over the GPL'd version of MySQL. Though I guess MySQL has special constraints about using the GPL'd version for web hosting, so maybe hosting providers will end up using commercial MySQL with GPL'd InnoDB.

Second, Oracle could almost certainly have bought MySQL. They have something like $1B in cash after-all. If they were actually interested in MySQL itself, that's probably what they would have done. But I don't think they're interested in MySQL at all; I suspect they want to kill it. And buying a core piece of technology is probably the cheapest way to do that. This doesn't kill MySQL outright, but it does make it much more difficult to use MySQL in a commercial environment and have it be ACID. That's the environment that Oracle operates in, so it's what they care about.

It'll be interesting to see if they go after PostgreSQL next, and how exactly they'll do it.

jeff95350

5+ Year Member



 
Msg#: 75 posted 8:25 pm on Oct 10, 2005 (gmt 0)

Of course, the downside to this is now you have a tuple in the database that will eventually be doing nothing but taking up space. This is where vacuum comes in. It scans through the table and when it runs across a deleted tuple, it checks to see if any transactions currently running can still "see" that tuple. If none can, it will remove the tuple, reclaiming the disk space.

You are referring to VACUUM FULL. Regular VACUUM just marks the deleted tuple as "dead" and PostgreSQL will reuse that space the next time you INSERT. Regular VACUUM is quite unobtrusive, and you can throttle it back so it's a low priority. It does not prevent concurrent reading/writing to the tables while the VACUUM is running.

VACUUM FULL actually moves the tuples around, packing the table more tightly to save disk space. This is sometimes useful if you have not VACUUMed in a *long* time and there are so many dead tuples that they will never all be reused. VACUUM FULL is rarely necessary; even most 24/7 systems don't need to use it.

iamlost

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 8:33 pm on Oct 10, 2005 (gmt 0)

<added>I see I am slow typing again but will leave as is</added>

Some clarification re the PostgreSQL VACUUM:

PostgreSQL retains rows that have been updated or deleted simply marking them "expired". An update actually writes a whole new row. This permits "prior state" views and enables rollbacks.

However, frequent update/delete operations build an ever expanding table decreasing efficiency.

The VACUUM FULL command removes/deletes the "expired" rows. It also compacts the table by moving subsequent rows into the vacated "expired" rows' positions.

As mentioned VACUUM FULL locks the DB/table while operating. When used on a multi-table DB it is best to vacuum (and lock) one table at a time. Most servers have peek and valley usage so pick the (s)low time(s), set an automated schedule, and monitor as required (almost set and forget).

VACUUM (without FULL) is what should normally be used, especially in high update situations, as it simply deletes but does does not compact and therefor does not lock the DB/table. The "vacant" rows are then available for re-filling.

[postgresql.org ]

Recommended practice for most sites is to schedule a database-wide VACUUM once a day at a low-usage time of day, supplemented by more frequent vacuuming of heavily-updated tables if necessary. (If you have multiple databases in a cluster, don't forget to vacuum each one; the program vacuumdb may be helpful.) Use plain VACUUM, not VACUUM FULL, for routine vacuuming for space recovery.

VACUUM FULL is recommended for cases where you know you have deleted the majority of rows in a table, so that the steady-state size of the table can be shrunk substantially with VACUUM FULL's more aggressive approach.

If you have a table whose contents are deleted completely every so often, consider doing it with TRUNCATE rather than using DELETE followed by VACUUM.


zCat

10+ Year Member



 
Msg#: 75 posted 8:45 pm on Oct 10, 2005 (gmt 0)

Apologies if this is slightly off topic, but because the topic of Postgres has been raised here, a few words from my experiences.

Speed: on simple selects, possibly with a couple of joins, MySQL with myisam tables is probably unbeatable. Anything more complex, especially involving write operations and / or referential integrity stuff, and Postgres is just as fast, if not faster. I converted my main site to Postgres about 18 months ago (purpose-built app which was getting quite complex) and speed is not a problem (even for 100% dynamic pages).

Functionality: currently Postgres blows MySQL out of the water. I'm interested to see how MySQL 5 compares, but Postgres will have had the features for longer, so they're more mature.

Reliability: Postgres is a lot less prone to random failures of the kind that occur from time to time in MySQL (i.e. requiring a REPAIR TABLE kind of operation). The only corruption I have ever experienced is with flaky hardware, and even then Postgres managed to "fail gracefully", i.e. not reading or writing bad data.

Postgres's biggest disadvantage is the lack of applications, at least web-based ones, and where there is support the implentation is lagging behind. Postgres is also a bit harder to tune, you have to work on the queries sometimes until the joins are tweaked into the right order.

iamlost

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 75 posted 8:50 pm on Oct 10, 2005 (gmt 0)


PostgreSQL looks very interesting. All the functions without the Hype of the mySQL.

The big question though - what would be the ASP connection string for it? I couldn't find it on a cursory glance through the docs.

I love Postgre :-)

A basic DSN-less connection string:

connect_string = "Driver={Postgres}; Server=[server name]; Port=[port number]; Database=[database name]; UID=[username]; PWD=[password]"

This 38 message thread spans 2 pages: 38 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Databases
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved