Recently I've been working on a large-ish project where all of the UI is written in Javascript. That, in itself, is great. The environments (the browsers) are crappy crappy for development though. Sure, there are Firefox extensions etc etc to help, but it's Just Not Great. Javascript = Great. Ajax = Yay. Browsers = Bah.

Over the weekend I spent all sorts of time getting a simple Rails application running with Apache and mod_fcgid. When I gave up and tried making it work with lighttpd I got server error galore. Yay. What was wrong? My fastcgi? The fcgi Ruby extension? My ruby installation is in /pkg/packages/ruby-1.8.4 or some such and the gem tool couldn't find its own libraries after being installed there. Maybe something similar for something else? I have no idea, I got no error messages anywhere. Ruby = Great. Rails = Very nice[1]. Ruby Gems = It sure is no CPAN.pm. FastCGI/lighttpd/etc = Loosely coupled? No mister, you have some way to …

In anticipation of getting my sunfire , and doing some real benchamrks with it, I thought I’d do a quick, test to see if I can still do them..kind of like a warm up excerise before you do a 1500m swim.

So I grabbed 2 idle machines I have access too, and see how mysql 5.1 performed on both.

I took Brian’s mysqlslap tool and gave it a little whirl.

the 3 boxes I had in my aresenal are

• dual x86-64 @2.4G with 8G of ram

a

• 280R with 2 Ultrasparc III+ processors and 4G of ram.

and my new macbook

• a Intel Dual processor shiny thing

now in their time, both of these boxes were considered pretty sweet. (the 280R was purchased in 2002 I think, and for financial people just nearing the end of it’s lifecycle so you will still …

With the introduction of mysql 5.1, they have introduced full text plugins which allows people to write their own parsers.

Now I’m not an expert in Lucene or this new feature, but it seems that both of these products are heading for the same point, One of the benefits I have often heard touted was that lucene had better relevancy, while mysql was faster. (no I don’t have any numbers to back this up.. maybe when my Sun Fire comes I’ll try loading this up as my ‘benchmark’). So it will be interesting to actually do some experimentation to see if you could get the best of both worlds.

maybe someone can sponsor me to re-tool nutch to work with a pure mysql back-end (Brian/Zack ?? are you reading this? does MySQL want to give …

for most ORM’s the typical access path is

single table selects either for:

• a primary key (for a single record)
• a list of related records (ie.. a foreign key)
• and possibly a ‘%XXX%’ to match a name or something

Is the HANDLER functionality a better (ie faster) method than using SQL syntax in this case? it seems like a more natural ‘fit’ for the ORM type behavior.

Brad Fitzpatrick has a nice discussion over what people should be using for their ‘id’ keys in a distributed environment. and puts a couple of points forward about why it isn’t such a good idea for his application/architecture. which has a ‘few’ central machines handing out ID’s.

The is a central problem with sequences that i’ve seen in most DB platforms. That and their 32-bit size. (I think mysql is 32-bit, i’m sure the geeks who read this will correct me)

The actual question has (If I am reading this correctly) is not about UUID’s vs local-sequences, but how do I move a ‘tree’ of records from one cluster to another, and not have a ID-clash. as if each cluster was independant, it wouldnt be a concern. you would have a central USER->cluster mapping algorithm/server which might be UUID or 64-bit based and then all future requests …