MyISAM is an analytical engine. Load data into it and then run queries. It has some limited concurrent functionality but really its a "load and query" storage engine.
In 90% of the cases I have seen, Innodb is the right pick. Most people learn this the first time they have to deal with a corrupt MyISAM table.
I would completely agree with you on this point. I added the link to my "crippleware" blog entry for this reason. While I believe it is best for the server to be open source, there is nothing stopping anyone from writing closed source extensions to their open source projects. As long as licenses are obeyed and a company acts in an even handed manner I believe that they will avoid creating crippleware.
If anyone in the know had written the original article I doubt they would have put "Sun" in the title. It was pretty much a MySQL decision all along. The original article was not completely wrong, but it certainly was wrong on the Sun part.
There are a number of ways to approach this problem. For one, you can throw hardware at it. Put a raid system under the data and just scale it out by applying as many disks as you can. In theory solid state disks will also solve this problem (though right now the limit for a single disk instances is 64gig).
You could use MySQL Cluster. It scales by pushing writes off to multiple storage nodes. If you need more speed you add more nodes.
From the software side you can choose to partition. This would push out locks to multiple partitions, and in the case of Innodb or MyISAM you can put the tables on different disks.
If what you need is fast aggregate operations, then the Archive engine will work for you.
There are number of ways to approach this. If you want to give me some more details about what you are trying to do, I'd be happy to offer up some solutions.
Thank you for the suggestions. Both sound like excellent ideas. Off the top of my head both can be done pretty easy with compiles, but it would be good to make a "jail break" version where the user really had not options.
Answer is... you either set the default to Innodb or configure to use Innodb as the default engine. Its all about options.
The same goes for sql syntax requirements. We offer the option of being ANSI strict or not. Its up to you.
If PostgreSQL works for you, that is awesome. Please use what you are comfortable with.
Re:Dificult to say...
on
Sun Buys MySQL
·
· Score: 4, Informative
There are many of us who have been working on MySQL for many years (my efforts with MySQL begin a decade ago). None of us are willing to move away from our open source roots. I've seen nothing that makes me think that Sun had any interest in doing anything foolish. They understand the value of MySQL being open source.
-Brian
Re:Im a sun employee
on
Sun Buys MySQL
·
· Score: 4, Informative
Hi!
We added triggers, stored procedures, and views in 5.0. Today there are publicly several transactional engines (supported by companies like Oracle, IBM, Solid, and yes ourselves). There are many other non-public transactional engines.
MySQL is compliant with the SQL core 92 specification, and has some of 2003. It is as compliant as any other database on the Market, and just like all of the other databases it has extended the SQL grammar.
You certainly have a different experience of Continuus then what I have. My one experience with it involved one company were we had purchased it and then blown hours of consulting time getting it to work. Never happened. The few projects that tried to use it had constant problems with corruption. It was an awful tool, and not one I would recommend any one to use.
Turns out I had not done a "make clean" in the PG directory, so it was a lot larger then what it needed to be. I've updated the tgz with a smaller file.
MySQL 5.0 has 2PC with XA support, our Java driver already exposes it and we exposed it in the SQL layer so languages like perl and PHP can make use of it. Further, we use it internally to communicate between multiple storage engines.
MySQL has been doing master to master replication for several years now. We also have support for setting all sequences for the entire database so that they don't clash with those also doing replication. This saves you the trouble of having to set it up on each and everyone of your tables.
a MySQL developer say "yeah, I don't know what we were thinking, that's a really fucked up thing to do"
Yep, its a fucked up thing. This is why we implemented strict mode for 5.0. In 4.1 you get warnings, in 5.0 if you are using a transaction table it tosses an error. If this is an issue, upgrade to 5.0. Personally for me it is.
Re:Now about SCO, this is my opinion, not MySQL's
on
MySQL and SCO Join Forces
·
· Score: 3, Informative
What the announcement from SCO about was for the agreement that allows SCO to act as a reseller for MySQL. What does this mean? It means that they can go to their customers and sell MySQL support, aka the support that any other MySQL customer gets from MySQL. They can also sell commercial licenses where their customers need it. We do the support, not SCO.
MySQL is platform agnostic. Developers themselves use FreeBSD, OSX, Linux, Windows, and Solaris, but we ship MySQL on several other platforms as well. Our goals are in the database market, we don't ship an OS, and we try to stay out of the "which OS is better" argument.
Just like we don't resale Linux, FreeBSD, Windows, or Solaris, we do not resell SCO OpenServer as well. The partnership does benefit us by selling more support contracts, but it doesn't change the fact that we didn't and still don't sell OpenServer or any other SCO product.
At some point the courts will make a decision on SCO's case and their behavior, but no matter what in the end there will still be SCO users and they will need support.
Now about SCO, this is my opinion, not MySQL's
on
MySQL and SCO Join Forces
·
· Score: 5, Informative
So, lets begin this statement with "these are my thoughts, not those that represent MySQL's". First of all I was one of the people who had us stop building on SCO in the first place. For a while now we have not been building for SCO, and had only been providing binaries for customers who had an existing contract with us for those binaries.
The source code for MySQL has always compiled for SCO unixen and since MySQL is open source anyone was free to compile it themselves. We don't ship Amiga binaries either but I can tell you that there is a group out there who keeps MySQL working on that platform as well. So our lack of support for SCO just meant that users were forced to either compile MySQL themselves or find a third party who were distributing the binaries.
Now why should we provide binaries for SCO? I'm of a couple of minds about this, and put some thought into it before I said "yes, lets do it" internally at MySQL.
First our users are our users no matter what platform they are on. This isn't about SCO, this is about the users of that platform who deserve to be able to get support. There are still a lot of SCO servers sitting out there and the users deserve to be treated like any other users. They didn't pick SCO's battle and many of them have legacy applications that can not be easily ported or easily rewritten. The choice of a vendor is not always an option.
Second, its about pushing open source into new territories. Years ago, I think 15 or so, I wrote a network client for the Mac. At the time a certain figurehead of the open source movement made a point of asking me "why would you ever write code for a closed source platform?". I have thought a lot about this over the years. Personally I believe that open source is not a all or nothing situation, and I believe that its going to take a while before we get to an all open source environment, which I am not at all certain will ever occur. Bringing well supported open source applications to closed source environments provides the users of these platforms a different opinion. Its an opinion that "maybe you should consider open source". I am all for spreading the gospel.
Keep in mind that our community binaries are GPL. This means that applications built on SCO that make use of these binaries must also stick within the agreement of the GPL or they have to buy licenses that in turn fund developers to work to create more GPL software. Its a win either way, we see either more GPL software being published or more GPL software being created via payment through licenses or subscriptions.
SCO OpenServer already ships with a number of other open source projects and if you look through many open source mailing lists you will see ongoing support and patches for OpenServer. What we will be doing is treating it like any other platform. Personally I hope that an open source stack on SCO creates more value for their customers and for SCO personally since I believe that this will push both SCO and their customers toward an open source path.
We, MySQL AB, license by host, not client. I am not sure where you got your information but it is incorrect. Can you tell me where you got your information? I would like to make sure we correct whatever the source of it was.
Replicating your data does not require that you have a commercial license. If you put your data, the databases, and an application on a CD and start shipping it to people, it might. As always, if you are really curious about the GPL, ask the FSF.
Timothy is very much a Libertarian, Pudge is very much a Republican. and Jamie is very much a liberal. Democrats are quite scarce. The daily IRC channel is filled with just about every thought one could imagine, and the only agreed upon source is Jon Stewart, who is god.
Do you distribute the application? Is your customer free to redistribute your software?
Even though your application uses an open source language, are you licensing the application that you are giving to them under an open source license (this assumes you ship it, if you are an ASP the situation is fairly cut and dry)?
Slashdot Mirror
MyISAM is an analytical engine. Load data into it and then run queries. It has some limited concurrent functionality but really its a "load and query" storage engine.
In 90% of the cases I have seen, Innodb is the right pick. Most people learn this the first time they have to deal with a corrupt MyISAM table.
Hi!
:)
Well I have no ability to edit a previously written story so I can do nothing about what went on before
Cheers,
-Brian
Hi!
I believe that I did mention Sun in the post, and I did so in a positive way. So I do not understand your comment.
Cheers,
-Brian
Hi!
I would completely agree with you on this point. I added the link to my "crippleware" blog entry for this reason. While I believe it is best for the server to be open source, there is nothing stopping anyone from writing closed source extensions to their open source projects. As long as licenses are obeyed and a company acts in an even handed manner I believe that they will avoid creating crippleware.
Cheers,
-Brian
Hi!
If anyone in the know had written the original article I doubt they would have put "Sun" in the title. It was pretty much a MySQL decision all along. The original article was not completely wrong, but it certainly was wrong on the Sun part.
Cheers,
-Brian
Hi!
There are a number of ways to approach this problem. For one, you can throw hardware at it. Put a raid system under the data and just scale it out by applying as many disks as you can. In theory solid state disks will also solve this problem (though right now the limit for a single disk instances is 64gig).
You could use MySQL Cluster. It scales by pushing writes off to multiple storage nodes. If you need more speed you add more nodes.
From the software side you can choose to partition. This would push out locks to multiple partitions, and in the case of Innodb or MyISAM you can put the tables on different disks.
If what you need is fast aggregate operations, then the Archive engine will work for you.
There are number of ways to approach this. If you want to give me some more details about what you are trying to do, I'd be happy to offer up some solutions.
Cheers,
-Brian
Hi!
Thank you for the suggestions. Both sound like excellent ideas. Off the top of my head both can be done pretty easy with compiles, but it would be good to make a "jail break" version where the user really had not options.
Answer is... you either set the default to Innodb or configure to use Innodb as the default engine. Its all about options.
The same goes for sql syntax requirements. We offer the option of being ANSI strict or not. Its up to you.
If PostgreSQL works for you, that is awesome. Please use what you are comfortable with.
There are many of us who have been working on MySQL for many years (my efforts with MySQL begin a decade ago). None of us are willing to move away from our open source roots. I've seen nothing that makes me think that Sun had any interest in doing anything foolish. They understand the value of MySQL being open source.
-Brian
Hi!
We added triggers, stored procedures, and views in 5.0. Today there are publicly several transactional engines (supported by companies like Oracle, IBM, Solid, and yes ourselves). There are many other non-public transactional engines.
Cheers,
-Brian
Not likely :)
Hi!
MySQL is compliant with the SQL core 92 specification, and has some of 2003. It is as compliant as any other database on the Market, and just like all of the other databases it has extended the SQL grammar.
Hi!
You certainly have a different experience of Continuus then what I have. My one experience with it involved one company were we had purchased it and then blown hours of consulting time getting it to work. Never happened. The few projects that tried to use it had constant problems with corruption. It was an awful tool, and not one I would recommend any one to use.
Turns out I had not done a "make clean" in the PG directory, so it was a lot larger then what it needed to be. I've updated the tgz with a smaller file.
Hi!
MySQL 5.0 has 2PC with XA support, our Java driver already exposes it and we exposed it in the SQL layer so languages like perl and PHP can make use of it. Further, we use it internally to communicate between multiple storage engines.
MySQL has been doing master to master replication for several years now. We also have support for setting all sequences for the entire database so that they don't clash with those also doing replication. This saves you the trouble of having to set it up on each and everyone of your tables.
Cheers,
-Brian
a MySQL developer say "yeah, I don't know what we were thinking, that's a really fucked up thing to do" Yep, its a fucked up thing. This is why we implemented strict mode for 5.0. In 4.1 you get warnings, in 5.0 if you are using a transaction table it tosses an error. If this is an issue, upgrade to 5.0. Personally for me it is.
What the announcement from SCO about was for the agreement that allows SCO to act as a reseller for MySQL. What does this mean? It means that they can go to their customers and sell MySQL support, aka the support that any other MySQL customer gets from MySQL. They can also sell commercial licenses where their customers need it. We do the support, not SCO.
MySQL is platform agnostic. Developers themselves use FreeBSD, OSX, Linux, Windows, and Solaris, but we ship MySQL on several other platforms as well. Our goals are in the database market, we don't ship an OS, and we try to stay out of the "which OS is better" argument.
Just like we don't resale Linux, FreeBSD, Windows, or Solaris, we do not resell SCO OpenServer as well. The partnership does benefit us by selling more support contracts, but it doesn't change the fact that we didn't and still don't sell OpenServer or any other SCO product.
At some point the courts will make a decision on SCO's case and their behavior, but no matter what in the end there will still be SCO users and they will need support.
So, lets begin this statement with "these are my thoughts, not those that represent MySQL's". First of all I was one of the people who had us stop building on SCO in the first place. For a while now we have not been building for SCO, and had only been providing binaries for customers who had an existing contract with us for those binaries.
The source code for MySQL has always compiled for SCO unixen and since MySQL is open source anyone was free to compile it themselves. We don't ship Amiga binaries either but I can tell you that there is a group out there who keeps MySQL working on that platform as well. So our lack of support for SCO just meant that users were forced to either compile MySQL themselves or find a third party who were distributing the binaries.
Now why should we provide binaries for SCO? I'm of a couple of minds about this, and put some thought into it before I said "yes, lets do it" internally at MySQL.
First our users are our users no matter what platform they are on. This isn't about SCO, this is about the users of that platform who deserve to be able to get support. There are still a lot of SCO servers sitting out there and the users deserve to be treated like any other users. They didn't pick SCO's battle and many of them have legacy applications that can not be easily ported or easily rewritten. The choice of a vendor is not always an option.
Second, its about pushing open source into new territories. Years ago, I think 15 or so, I wrote a network client for the Mac. At the time a certain figurehead of the open source movement made a point of asking me "why would you ever write code for a closed source platform?". I have thought a lot about this over the years. Personally I believe that open source is not a all or nothing situation, and I believe that its going to take a while before we get to an all open source environment, which I am not at all certain will ever occur. Bringing well supported open source applications to closed source environments provides the users of these platforms a different opinion. Its an opinion that "maybe you should consider open source". I am all for spreading the gospel.
Keep in mind that our community binaries are GPL. This means that applications built on SCO that make use of these binaries must also stick within the agreement of the GPL or they have to buy licenses that in turn fund developers to work to create more GPL software. Its a win either way, we see either more GPL software being published or more GPL software being created via payment through licenses or subscriptions.
SCO OpenServer already ships with a number of other open source projects and if you look through many open source mailing lists you will see ongoing support and patches for OpenServer. What we will be doing is treating it like any other platform. Personally I hope that an open source stack on SCO creates more value for their customers and for SCO personally since I believe that this will push both SCO and their customers toward an open source path.
We, MySQL AB, license by host, not client. I am not sure where you got your information but it is incorrect. Can you tell me where you got your information? I would like to make sure we correct whatever the source of it was.
Thanks!
The code is committed and has been for several months :)
We provide XA both via SQL and the JDBC driver currently.
Along with Yahoo, you can also add Google and a host of other companies.
Hi!
Replicating your data does not require that you have a commercial license. If you put your data, the databases, and an application on a CD and start shipping it to people, it might. As always, if you are really curious about the GPL, ask the FSF.
A topic plus someone to setup a bit torrent of the show's episodes :)
I don't think there are any typical liberals. In some ways pudge can even be liberal in a few cases.
Timothy is very much a Libertarian, Pudge is very much a Republican. and Jamie is very much a liberal. Democrats are quite scarce. The daily IRC channel is filled with just about every thought one could imagine, and the only agreed upon source is Jon Stewart, who is god.
Do you distribute the application? Is your customer free to redistribute your software?
Even though your application uses an open source language, are you licensing the application that you are giving to them under an open source license (this assumes you ship it, if you are an ASP the situation is fairly cut and dry)?