Subqueries in Mysql is as useful in the real-world deployments as paper and pencil. Actually, at least with p&p, I can doodle some fancy comics.
Subselects is so limited in the indexes it can use the performance as melted has pointed out is bad. To me, it's not bad, it's unusable in just-in-time page generation. Usable for cron jobs and data warehousing but forget about it if you want it "fast".
As a heavy user of Mysql since 4 series, 5.X has been the buggiest, slowest, with the most god-awful slow release schedule of them all. 4.1 alpha was higher quality in terms of bugs/stability than all the stable "5.0" releases and 5.1 just takes forever to get even beta revisions out the door. Mysql is getting slower and slower at getting releases out the door. Expect Mysql 6.0 in 2011 if not later.
I'm a paid mysql enterprise subscriber and I'm pissed at their pace.
It's one thing to have a slow stable release but for crying out loud, shorten your "beta/rc" releases please? The amount of bugs fixed between each release is staggering which is why the bleeding edge adopters need faster releases!
in how they recycle their gigantic heat output...perhaps move data center to the windy city, open up a homeless shelter next door, and put the hot air to good use for once. They might even get a tax break on this.
Better yet, open up a nursery (plant type) next door , build a green house, and piple 25% of the heat to it. Have you guys see the price of trees lately? Google could make a killing with the "recycling" plant.
No where did they mention battery backed-up ram modules as a recommended config so I believe your're correct to assume that disk not only has to be used, but MUST be used.
Without ramsan style battery packed ram, there is no way any enterprise would trust clusters of any kind to ram only storage for write commits.
Looks like each write transaction will be synchronized acrossed all nodes, which would explain the gigabit and lower latency interconnects. Still, this is crazy complex to make fast and reliable.
So to make it truely synchronized, they have to write to disk, for backup/log, before committiong the data to the ram. So regardless, writes are slow and I'm waiting to see how they by-pass this disk write commit latency. Add on that they have to do this for all nodes before responding to the app, writes are crazy slow, relatively, since they can influence indices, force cache/ramed-data flushes, etc. Would be interesting to see how they handle this.
Also, I'm interested to see what type of check code/algorithm to see which NODE is healthy and which ones are corrupt (not dead since dead servers are the easiest to detect). From their diagrams, looks like N-type replication so each node is an exact synchorinized duplicate of all others. But how to know for sure which one is the "safe" one when corrupts happen?
Also, I wonder how they tackle gigantic inserts/update like "replace into table2 select * from gigantic_table1". They can't assume or dictate that we only stick to small write transactions right?
Cheap N-way synchronized replication is my and probably most dbms managers' holy grail so I'm crossing my fingers for Mysql to get this right.
If this is the requirement deployment then for people like us were db size at over 20GB, and yes the big blogs are already stored in compressed using compression, this would not be economically pratically to use. Factoring OS, caching, I need to get 22GB memory for each node? Last I checked, the 2GB cheaps are still nasty expensive.
Slashdot Mirror
Subqueries in Mysql is as useful in the real-world deployments as paper and pencil. Actually, at least with p&p, I can doodle some fancy comics.
Subselects is so limited in the indexes it can use the performance as melted has pointed out is bad. To me, it's not bad, it's unusable in just-in-time page generation. Usable for cron jobs and data warehousing but forget about it if you want it "fast".
As a heavy user of Mysql since 4 series, 5.X has been the buggiest, slowest, with the most god-awful slow release schedule of them all. 4.1 alpha was higher quality in terms of bugs/stability than all the stable "5.0" releases and 5.1 just takes forever to get even beta revisions out the door. Mysql is getting slower and slower at getting releases out the door. Expect Mysql 6.0 in 2011 if not later.
I'm a paid mysql enterprise subscriber and I'm pissed at their pace.
It's one thing to have a slow stable release but for crying out loud, shorten your "beta/rc" releases please? The amount of bugs fixed between each release is staggering which is why the bleeding edge adopters need faster releases!
in how they recycle their gigantic heat output...perhaps move data center to the windy city, open up a homeless shelter next door, and put the hot air to good use for once. They might even get a tax break on this.
Better yet, open up a nursery (plant type) next door , build a green house, and piple 25% of the heat to it. Have you guys see the price of trees lately? Google could make a killing with the "recycling" plant.
My guess is just as your guess which would be:
your guess + 1 = my guess.
We already know they have enough servers to saturate a T1000 line so might as well stop here and talk about something more constructive.
No where did they mention battery backed-up ram modules as a recommended config so I believe your're correct to assume that disk not only has to be used, but MUST be used.
Without ramsan style battery packed ram, there is no way any enterprise would trust clusters of any kind to ram only storage for write commits.
Looks like each write transaction will be synchronized acrossed all nodes, which would explain the gigabit and lower latency interconnects. Still, this is crazy complex to make fast and reliable.
So to make it truely synchronized, they have to write to disk, for backup/log, before committiong the data to the ram. So regardless, writes are slow and I'm waiting to see how they by-pass this disk write commit latency. Add on that they have to do this for all nodes before responding to the app, writes are crazy slow, relatively, since they can influence indices, force cache/ramed-data flushes, etc. Would be interesting to see how they handle this.
Also, I'm interested to see what type of check code/algorithm to see which NODE is healthy and which ones are corrupt (not dead since dead servers are the easiest to detect). From their diagrams, looks like N-type replication so each node is an exact synchorinized duplicate of all others. But how to know for sure which one is the "safe" one when corrupts happen?
Also, I wonder how they tackle gigantic inserts/update like "replace into table2 select * from gigantic_table1". They can't assume or dictate that we only stick to small write transactions right?
Cheap N-way synchronized replication is my and probably most dbms managers' holy grail so I'm crossing my fingers for Mysql to get this right.
Wow...I have to apologize for my atrocious spelling and grammar in the post. I'm usually not this bad. =)
If this is the requirement deployment then for people like us were db size at over 20GB, and yes the big blogs are already stored in compressed using compression, this would not be economically pratically to use. Factoring OS, caching, I need to get 22GB memory for each node? Last I checked, the 2GB cheaps are still nasty expensive.