And what happens if instead of a varchar/char you try storing 300 in a tinyint? Or 10000 in a numeric(4)?
MySQL's biggest problem is that it's developers always want to try and make things easy at the expense of data integrity. They think it's ok if your data gets a little 'banged up' along the way.
The problem with your reasoning is that it becomes extremely expensive as database size grows. The reason to add analytic capabilities to the database are because it's more efficient. 10 years ago, the same argument could be (and was) made about adding OLAP functions to databases. Yet now they're in all of the 'big 3' in one form or another.
If you only need a database as a way to store and retrieve data then you don't need a database, you need a flat file.:P
Actually, they discovered that most of the randomness in the lava lamp cams was from background noise. There's now a site that uses cameras with their lens caps on to generate random numbers at a much higher rate.
How does 'never had anythingto do with the GPL' make them suck? They're releasing drivers for a GPL and BSD-licensed OS, that's not good enough for you?
Sorry, I guess you're one of those people who will never be happy until no one anywhere can make any money off of any software or anything related to software. Nevermind.
The incremental cost of electricity for a computer that is idle verses one running at 100% CPU is actually very, very small.
If we assume that the CPU draws 60W more at 100% use than at 0% (Intel lists maximum heat disipation of 60W for the P4), then 8,000 computers would consume a total of 480kW. Sounds like a lot, right? Now consider that so far today, California has had a maximum power draw of 28,000GW, which is 58 *million* times more than 480kW. And that's just one state.
I know a few details, since I help create the software:)
The software is push-based, just like the software you can download to participate in our global research projects. Unlike many other distributed computing clients though, ours has the ability to update itself, which greatly reduces administration overhead.
Also, although the client software normally operates independantly in a push-based manner, it is possible to do MPI as well, it just has to be coded as part of the actual application software.
There are many computational problems that require far more power than a 50-100 person company can easily pay for. 'Fabless' semiconductor manufacturers and small drug discovery companies are two examples. Even for larger companies, renting time can make a lot of sense if they have an infrequent need for large processing power.
Something else to consider is that unlike most corporations, Gateway continually rotates the newest machines available into their showrooms, so their grid will always be growing in power.
However, I think that with the time they've been taking on RC5-64 (over four years now, and nearly another year to go to exhaust the keyspace) shows that that key length is still fairly secure against "casual" hackers.
Depends on your definition of casual, but in any case, determining how long a brute force attack might take is still useful. Many security experts use 20 years as the benchmark for how long something should be safe from an attack. In the extreme, this means that if we are able to complete the RSA challenge before 2016 or so (I don't remember exactly when they offered the challenges), then RC5-64 isn't secure.
Admittedly, that's a very extreme view, but given the progress that a group of volunteers has been able to make against RC5-64 I hope it shows that nothing that needs long-term protection should be encrypted with RC5-64 (imagine how long it would take to brute force RC5-64 in 2010, for example).
I'm not really sure what to make of your comment. First, there's plenty of good connectivity in Austin, Houston, San Antonio, and Dallas. More importantly, we have a large concentration of staff in Austin, which is very important whenever physically working on the hardware is required.
Remember that the components in any digital system - and I'm not just talking about your windoze desktop PC, but servers, mainframes and embedded systems too - have to talk to each other in order to do anything remotely useful. Last time I looked, most PCI devices din't utilise the provision for 64-bit data bus operation.
True, most PCI devices don't support 64bit, but there's no need for most of them to. The biggest bottleneck isn't getting stuff off the network or even off the disk; it's moving data back and forth between memory and the CPU. Certainly, more bandwidth for some peripherals might help in some cases, but generally you're not going to see the need for it.
Memory is a different story of course. Take the RS/6000 platform as compared to Sun. Everything about the 6000s is designed around memory bandwidth, so that even mid-grade 6000s have crossbars capable of 20+GB/s. Sun doesn't do this (only their very high end boxes even have crossbars), and because of this you typically need a Sun box with 2x the number of CPUs as a 6000 to get equivalent performance on Oracle. Since Oracle is sold per CPU, a lot of companies are discovering that they can upgrade from Sun to RS/6000 for free, because the cost savings of the Oracle license pays for the upgrade. The 6000 gets this performance using PCI for peripherals, too.
This can easily be overcome by gating the input to a logic stage with a handshaking signal from the stages that are inputs to it.
Instead of thinking of this as being clockless, think of it as being dynamically clocked. Instead of clocking operations at a fixed frequency, you just gate them based on how long they take to perform. This presents an enormous performance benefit because you don't have to slow the entire chip down to the speed of the slowest portion of the chip.
An analogy is polling v. interupts. Instead of polling for something to happen at a fixed frequency, you can go about your business until whatever you were waiting on taps you on the shoulder and says "I'm done". In both cases, you don't have to worry about metastability, as you still have a gating factor to keep things under control.
Also, my guess is that they didn't bother turning off all kinds of features in the other databases in order to put them on equal ground with MySQL. Features such as transactions, row-level locking, etc.
It's amazing how much faster a database runs when it doesn't have to worry about such 'niceties'.
I think you're confusing clustering and replication.
Replication is having multiple copies of the same database and trying to keep all the copies in sync.
Clustering is taking a database and splitting it up across multiple machines. For example, DB2 allows you to do this at the table level, where rows for a single table are stored on multiple machines. What makes this work is DB2 hides most(if not all) of this from the applications, so it looks just like one large database.
Personally, I'm more in favor of getting hardware capable of running the database, since administrating a single machine is generally much easier than administrating dozens, not to mention power consumption and floorspace considerations.
Everyone comments on how MySQL is faster than Postgres, but have these comparison's been made in an apples-to-apples manner? Obviously MySQL will perform much better out of the box, since it doesn't use things like row-level locking. I'm guessing that Postgres does use row-level locking by default. If you don't care about concurrancy, most databases will allow you to use table locks instead, which gives you a huge performance increase.
Row-level locking is available in mysql by using a third-party table type [innodb.com]...As are transactions, and page-level locking.
The point is that any organization that promotes ideas such as "table level locking is superior to row level locking because it's faster" obviously has little understanding of what kind of features are needed for a robust database. That kind of attitude raises all kinds of questions about everything from their high level design down to the code. Data integrity isn't something that you tack-on to a database engine as an afterthought, it's something that should be designed in from the start. Have they ever thought about things such as data integrity problems caused by re-ordered writes by the filesystem? Probably not because it's not much of an issue if you don't provide transactions. (Yes, I know there are 3rd party add-ons that provide transactions)
It's encouraging to see 3rd parties adding sorely missing features to MySQL, but the point is that MySQL's developers should have at least realized what kind of things MySQL needs to be more than a glorified flat file handler. If they don't want to add these features that's their call, but it's a real disservice when they bash features they don't want to impliment because they see no use for them. If there was no use for them, then Oracle, IBM, Sybase, Microsoft, and countless other companies wouldn't have spent a lot of money developing them.
I've never heard of either of the databases you mention, so I can't comment on them.
Typically, there are two reasons why people go with commercial databases:
- Support
- 'Quality' (more robust, more scalable, etc.)
Support is pretty obvious... something goes wrong, you call. I'm sure some companies are much better at providing support than others, but it's a pretty safe bet that you'll get better support for a commercial database than a free one. And before the flames start, by support I mean 24x7 support, the kind of support you need when a system is down. Popping into an IRC channel and hoping someone's awake isn't a very good support plan when you're losing business by the second:)
Quality depends greatly on what you're trying to do. For example, would you open an account with a bank that uses MySQL to keep your account information? Or trust a hospital to keep your medical info in MySQL? Big databases like DB2 and Oracle provide the tools you need to ensure data integrity. They also have a well-proven track record of use in industries where losing or corrupting data simply is not an option (I'm talking things like NYSE and financial institutions, not some e-store or a simple website).
Another issues is scalability. People love to tout MySQL's performance, but it's very easy to see where you can make it fail. Not having row-level locking means good luck using it in a OLTP system, for example. It also doesn't cluster (which is an absolute requirement if you're going to do anything serious on x86 hardware).
On the other hand, it'd be pretty silly to pay for something like DB2 just to run a small website.
Slashdot Mirror
Couldn't port the data? Or the application?
Better yet, if you really care about your data, use a database that does as well.
And if you don't care about your data, why are you even bothering to store it?
And what happens if instead of a varchar/char you try storing 300 in a tinyint? Or 10000 in a numeric(4)?
MySQL's biggest problem is that it's developers always want to try and make things easy at the expense of data integrity. They think it's ok if your data gets a little 'banged up' along the way.
DB2's clustering doesn't use shared storage iirc. In Oracle what you're looking for is replication, not clustering.
Actually, Oracle supported this in 9i as well.
The problem with your reasoning is that it becomes extremely expensive as database size grows. The reason to add analytic capabilities to the database are because it's more efficient. 10 years ago, the same argument could be (and was) made about adding OLAP functions to databases. Yet now they're in all of the 'big 3' in one form or another.
:P
If you only need a database as a way to store and retrieve data then you don't need a database, you need a flat file.
http://sql-info.de/mysql/gotchas.html : 31 mysql gotchasm l : 13 postgresql gotchas
http://sql-info.de/postgresql/postgres-gotchas.ht
Which one would you rather use?
Actually, they discovered that most of the randomness in the lava lamp cams was from background noise. There's now a site that uses cameras with their lens caps on to generate random numbers at a much higher rate.
Never attribute to malice that which can be blamed on stupidity. :)
How does 'never had anythingto do with the GPL' make them suck? They're releasing drivers for a GPL and BSD-licensed OS, that's not good enough for you?
Sorry, I guess you're one of those people who will never be happy until no one anywhere can make any money off of any software or anything related to software. Nevermind.
The incremental cost of electricity for a computer that is idle verses one running at 100% CPU is actually very, very small.
If we assume that the CPU draws 60W more at 100% use than at 0% (Intel lists maximum heat disipation of 60W for the P4), then 8,000 computers would consume a total of 480kW. Sounds like a lot, right? Now consider that so far today, California has had a maximum power draw of 28,000GW, which is 58 *million* times more than 480kW. And that's just one state.
Uhm, oops. That should be the MetaProcessor, not MeteProcessor.
*wipes egg off face*
They are using the United Devices Alliance MeteProcessor.
The software is push-based, just like the software you can download to participate in our global research projects. Unlike many other distributed computing clients though, ours has the ability to update itself, which greatly reduces administration overhead.
Also, although the client software normally operates independantly in a push-based manner, it is possible to do MPI as well, it just has to be coded as part of the actual application software.
There are many computational problems that require far more power than a 50-100 person company can easily pay for. 'Fabless' semiconductor manufacturers and small drug discovery companies are two examples. Even for larger companies, renting time can make a lot of sense if they have an infrequent need for large processing power.
Something else to consider is that unlike most corporations, Gateway continually rotates the newest machines available into their showrooms, so their grid will always be growing in power.
Althogh that link does work, RC5-72 stats are not yet available, we're still working some bugs out.
However, I think that with the time they've been taking on RC5-64 (over four years now, and nearly another year to go to exhaust the keyspace) shows that that key length is still fairly secure against "casual" hackers.
Depends on your definition of casual, but in any case, determining how long a brute force attack might take is still useful. Many security experts use 20 years as the benchmark for how long something should be safe from an attack. In the extreme, this means that if we are able to complete the RSA challenge before 2016 or so (I don't remember exactly when they offered the challenges), then RC5-64 isn't secure.
Admittedly, that's a very extreme view, but given the progress that a group of volunteers has been able to make against RC5-64 I hope it shows that nothing that needs long-term protection should be encrypted with RC5-64 (imagine how long it would take to brute force RC5-64 in 2010, for example).
I'm not really sure what to make of your comment. First, there's plenty of good connectivity in Austin, Houston, San Antonio, and Dallas. More importantly, we have a large concentration of staff in Austin, which is very important whenever physically working on the hardware is required.
True, most PCI devices don't support 64bit, but there's no need for most of them to. The biggest bottleneck isn't getting stuff off the network or even off the disk; it's moving data back and forth between memory and the CPU. Certainly, more bandwidth for some peripherals might help in some cases, but generally you're not going to see the need for it.
Memory is a different story of course. Take the RS/6000 platform as compared to Sun. Everything about the 6000s is designed around memory bandwidth, so that even mid-grade 6000s have crossbars capable of 20+GB/s. Sun doesn't do this (only their very high end boxes even have crossbars), and because of this you typically need a Sun box with 2x the number of CPUs as a 6000 to get equivalent performance on Oracle. Since Oracle is sold per CPU, a lot of companies are discovering that they can upgrade from Sun to RS/6000 for free, because the cost savings of the Oracle license pays for the upgrade. The 6000 gets this performance using PCI for peripherals, too.
This can easily be overcome by gating the input to a logic stage with a handshaking signal from the stages that are inputs to it.
Instead of thinking of this as being clockless, think of it as being dynamically clocked. Instead of clocking operations at a fixed frequency, you just gate them based on how long they take to perform. This presents an enormous performance benefit because you don't have to slow the entire chip down to the speed of the slowest portion of the chip.
An analogy is polling v. interupts. Instead of polling for something to happen at a fixed frequency, you can go about your business until whatever you were waiting on taps you on the shoulder and says "I'm done". In both cases, you don't have to worry about metastability, as you still have a gating factor to keep things under control.
Also, my guess is that they didn't bother turning off all kinds of features in the other databases in order to put them on equal ground with MySQL. Features such as transactions, row-level locking, etc.
It's amazing how much faster a database runs when it doesn't have to worry about such 'niceties'.
I think you're confusing clustering and replication.
Replication is having multiple copies of the same database and trying to keep all the copies in sync.
Clustering is taking a database and splitting it up across multiple machines. For example, DB2 allows you to do this at the table level, where rows for a single table are stored on multiple machines. What makes this work is DB2 hides most(if not all) of this from the applications, so it looks just like one large database.
Personally, I'm more in favor of getting hardware capable of running the database, since administrating a single machine is generally much easier than administrating dozens, not to mention power consumption and floorspace considerations.
Everyone comments on how MySQL is faster than Postgres, but have these comparison's been made in an apples-to-apples manner? Obviously MySQL will perform much better out of the box, since it doesn't use things like row-level locking. I'm guessing that Postgres does use row-level locking by default. If you don't care about concurrancy, most databases will allow you to use table locks instead, which gives you a huge performance increase.
The point is that any organization that promotes ideas such as "table level locking is superior to row level locking because it's faster" obviously has little understanding of what kind of features are needed for a robust database. That kind of attitude raises all kinds of questions about everything from their high level design down to the code. Data integrity isn't something that you tack-on to a database engine as an afterthought, it's something that should be designed in from the start. Have they ever thought about things such as data integrity problems caused by re-ordered writes by the filesystem? Probably not because it's not much of an issue if you don't provide transactions. (Yes, I know there are 3rd party add-ons that provide transactions)
It's encouraging to see 3rd parties adding sorely missing features to MySQL, but the point is that MySQL's developers should have at least realized what kind of things MySQL needs to be more than a glorified flat file handler. If they don't want to add these features that's their call, but it's a real disservice when they bash features they don't want to impliment because they see no use for them. If there was no use for them, then Oracle, IBM, Sybase, Microsoft, and countless other companies wouldn't have spent a lot of money developing them.
I've never heard of either of the databases you mention, so I can't comment on them.
:)
Typically, there are two reasons why people go with commercial databases:
- Support
- 'Quality' (more robust, more scalable, etc.)
Support is pretty obvious... something goes wrong, you call. I'm sure some companies are much better at providing support than others, but it's a pretty safe bet that you'll get better support for a commercial database than a free one. And before the flames start, by support I mean 24x7 support, the kind of support you need when a system is down. Popping into an IRC channel and hoping someone's awake isn't a very good support plan when you're losing business by the second
Quality depends greatly on what you're trying to do. For example, would you open an account with a bank that uses MySQL to keep your account information? Or trust a hospital to keep your medical info in MySQL? Big databases like DB2 and Oracle provide the tools you need to ensure data integrity. They also have a well-proven track record of use in industries where losing or corrupting data simply is not an option (I'm talking things like NYSE and financial institutions, not some e-store or a simple website).
Another issues is scalability. People love to tout MySQL's performance, but it's very easy to see where you can make it fail. Not having row-level locking means good luck using it in a OLTP system, for example. It also doesn't cluster (which is an absolute requirement if you're going to do anything serious on x86 hardware).
On the other hand, it'd be pretty silly to pay for something like DB2 just to run a small website.