Hi Everyone,
 
Please remember that the cutoff is NOON today, per the schedule.
 
Now may be a good time to wrap up what you’re working on, and probably not a good time to start anything new.
 
I once saw a woman late to the subway platform try to stop the closing train doors by swinging her shopping bag of expensive clothes between them. The doors closed and trapped the bag. Then the conductor, who could see what had happened, just pulled the train away with her on the platform and the bag still wedged in the door.

I’ve always admired that conductor.
 
-AO

From the docs:

Attached is a simple import, export, and backup utility. Mahalo.com has been using this in production for several months to back up our HBase clusters as well as to migrate data from production to development clusters, etc.

Simple MapReduce job for exporting data from an HBase table. The exported data is in a simple, flat format that can then be imported using another MapReduce job. This gives you both a backup capability, and a simple way to import and export data from tables.

The output of a backup job is a flat text file, or series of flat text files. Each row is represented by a single line, with each item tab delimited. Column names are plain text, while column values are base 64 encoded. This helps us deal with tabs and line breaks in the data. Generally you should not have to worry about this at all.

HBase Backup/Export/Import Tool

Hadoop: When grownups do open source | The Register

Hadoop is a library for writing distributed data processing programs using the MapReduce framework. It’s got all the makings of a blogosphere hit: cluster computing, large datasets, parallelism, algorithms published by Google, and open source. Every four days or so, a nerd will discover Hadoop, write a “Basic MapReduce Tutorial with Hadoop” tutorial on his blog with some trivial examples, and feel satisfied with himself for educating the world about a yet-undiscovered gem. Comparatively, very few people actually use Hadoop in practice, and those who do don’t write about it. Why? Because they’re adults who don’t care about getting on the front page of Digg.

Read on. It’s great stuff, and you’ll definitely learn something useful if your site needs to…well…scale.

photo credit: doyoukekko

In the past few weeks, I’ve helped some of my friends move their WordPress blogs to new servers. One of them had a consistent problem with their host because WordPress was hogging cycles on the shared server. We implemented the WP-Cache plugin, and things got better in minutes.

Jeff Atwood has written a terrific article about the perils of using WordPress without caching.

I’ve been thoroughly impressed with the community around WordPress, and the software itself is remarkably polished. That’s not to say that I haven’t run into a few egregious bugs in the 2.5 release, but on the whole, the experience has been good bordering on pleasant.



Or at least it was, until I noticed how much CPU time the PHP FastCGI process was using for modest little old blog.stackoverflow.com.

Read the full article if you have Wordpress blog — even if you’re not technically inclined. You’ll thank yourself later.

Caching is the smart way to handle any generated content. When you cache your content, a plugin or service will take the HTML generated by your blog and save it to a flat file. It’s just like taking a snapshot. The cached file will expire after a time, so that your content will remain fresh. It takes many less CPU cycles to serve flat file than to generate them from the database every time. This has the added benefit of speeding up your blog’s display time as well.

Consider your RSS feeds. While RSS is a great thing, every time someone hits your feed you are generating content from the database and serving it out to the world. Poorly behaved RSS readers will this your feed as often as every five minutes. For a worst case scenario, take the file size of your feed when generated, multiply it by the number of subscribers you have, and multiply that by 12. That’s how much bandwidth you could be using per hour for the feed alone. If you have a great number of items in your feed or are very popular you’ll eventually get a shutdown notice from your host or the site will simply shut down on it’s own, displaying a lovely error message to your audience.

To avoid downtime, use WP-Cache or WP-SuperCache to implement a quick caching solution. For an additional layer of protection, try using Feedburner for your feeds. It caches your feed for 30 minutes on their server, so you reduce the load on your server considerably. You’ll see your blog begin to behave, and you’ll get those creepy hosting admins off your case.

Advanced Users: For those of you who have full control of your servers, look at using memcached to handle the caching for the server. Less wear and tear on the disk, performs better for larger-scale projects than simple file caching. Check out Ryan’s post on how to implement WordPress with memcached.