So, I mentioned in my MySQL Cluster post that I found out that cluster and joins don’t get a long too well. There are a couple of tips I have for using joins or replacing them with other techniques that I thought I would share.

Here are some things I keep in mind when using the NDB engine. These may apply to the other engines as well.

1. Test using the NDB engine. Testing against another engine is not adequate.
2. Avoid JOIN if you can, test often if you can’t
3. Avoid subqueries always
4. Select using primary keys when at all possible. Always select using a key.
5. Be sure to include both your where and order by columns in your keys.

Try your join from several directions.

Sometimes, the way you join can affect the engine. This is more …

There is a bunch of posts on Planet MySQL this week about RAID.  This comment from Kevin Burton really kind of made me go “huh?”.

You?re thinking too low level. Who cares if the disk fails. The entire shard is setup for high availability. Each server is redundant with 1-2 other boxes (depends on the number of replicas). If you have automated master promotion you?ll never notice any downtime. All the disks can fail in the server and a slave will be promoted to a new master.

Monitoring then catches that you have a failed server and you have operations repair it and put it back into production as a new slave.

Someone has to think low level.  The key phrase in there is  you have operations repair it and put it back into production as a …

Pawel Barut has published the 48th edition of Log Buffer, the weekly review of database blogs, on his blog, Software Engineer Thoughts. Coskan Gundogar takes it up next week, but the schedule is quite open after him. Log Buffer wants you! Read the Log Buffer homepage and get in touch if you’d like to [...]

Jeremy retorts that RAID is alive and well in the real world:

Kevin Burton wrote a sort-of-reply to my call for action in getting LSI to open source their CLI tool for the LSI MegaRAID SAS aka Dell PERC 5/i, where he asserted that ?RAID is dying?. I?d like to assert otherwise. In my world, RAID is quite alive and well. Why?

I should note that I said:

I?d like to assert that in 3-5 years RAID will be a thing of the past.

I’m not saying it’s dead now - but I do think it’s dying.

RAID is cheap. Contrary to popular opinion, RAID isn?t really that expensive. The controller is cheap (only $299 for Dell?s PERC 5/i, with BBWC, if you pay full retail).

… that’s the price of one HDD. You’ve just lost some IO there. Granted this isn’t a major issue but it all ads …

Kevin Burton wrote a sort-of-reply to my call for action in getting LSI to open source their CLI tool for the LSI MegaRAID SAS aka Dell PERC 5/i, where he asserted that “RAID is dying”. I’d like to assert otherwise. In my world, RAID is quite alive and well. Why?

• RAID is cheap. Contrary to popular opinion, RAID isn’t really that expensive. The controller is cheap (only $299 for Dell’s PERC 5/i, with BBWC, if you pay full retail). The “2x” disk usage in RAID 10 is really quite debatable, since those disks aren’t just wasting space, they are also improving read (and subsequently write) performance.
• Latency. The battery-backed write …

In an effort to reduce the number of open tabs I have in Firefox, I have some rather interesting MySQL-related resources that I think the rest of Planet MySQL will quite enjoy.

• Linbit (the makers of DRBD) and MySQL are in a partnership now, and Irwan Jamaluddin, a systems adminstrator at one of the only Linux support companies in Malaysia, has recently blogged about his journey with DRBD and MySQL. The operating system base is RHEL 5, and there is a step-by-step guide on how he got it working. From what I gather, its a cut-n-paste tutorial, not something I’ve verified, but I’m sure I’ll refer to it when I want to play with DRBD.
• MySQL Basics in Pictures. Granted they’ve used an odd version of Linux for the basis of the tutorial, but that doesn’t affect the quality of the …

Jan Kneschke works for the MySQL Development Team and is the author of the very popular lighttpd web server. I recently had the opportunity to ask him a few questions about himself and his work.

In our last installment, we looked at how to write data into a storage engine, now lets look at updating it.

To update data you need to first know that it exists. To do this MySQL reads the rows that need to be updated, either by index or scan read. Since we have already spoken on scan reads, we are going to look at updates that occur that need to scan the entire table. MySQL will start up a read and do the folllowing:

rnd_init()
rnd_next()
rnd_next()
rnd_next()
update_row()
rnd_next()
rnd_next()
rnd_end()

In the above example, MySQL find four rows in the table. The third row is matched for an update. The engine writer doesn't have to do to the predicate test themselves (aka ... UPDAT E A SET b=5 WHERE a=3, the engine writer doesn't need to worry about matching the a=3). The …

I recently saw the Planet MySQL post Five months with MySQL Cluster by Brian Moon.

Thought I’d add my 5 cents worth (Australian’s don’t have 1 cent coins any more to make 2 cents worth)

Firstly, it’s great you wrote about your experiences in moving to MySQL Cluster. I think more people should.

Joins

“We used a lot of joins. We learned (later) that joins in the cluster are not a good idea.”

MySQL Cluster’s number one strength is Primary Key Lookups, it’s very good you learned that joins (especially say 5-6-7 table joins) are not a good idea, it is not a strength, and certainly not scalable to thousands of queries per second.

Rewrite

“We rewrote our application (basically, our public web site) to use …

So, the whole world changed at dealnews when Yahoo! linked us. We realized that our current infrastructure was not scaling very well. We had to make a change.

The Problem

Even though we were using all sorts of cool techniques, the server architecture was really still just a bunch of web servers all serving the same content. In addition to that, our existing systems as the time used a pull method. When a request came in, memcache was checked, if the data was not there, it was fetched from our main MySQL server. So, when there is no data in the cache or when it expires, this was very bad. Like when Yahoo! hit us. Some cache item would expire and 60,000 users would hit a page and each page would try and create the cache item.

The Solution

I …