Jon Bruner's "American Migration" visualization, based on IRS data, demonstrates how "Americans are enormously mobile: 37.5 million people moved from one house to another last year, with 4.3 million of them moving between states." Bruner's interactive map lets you click on a specific county and see both the immigration and emigration data for that location — where folks move from and where they move to.

Screenshot from the "American Migration" visualization (click for full interactive version).

As …

The just gone-by recession (or is it still here?) taught companies to stop investing in new technology hastily and first look inwards to extract some more juice from the existing humming machines. Administrators across the database technologies find themselves at the center stage of that and they are sharing tips and tricks regarding that in [...]

I was giving a presentation of the MySQL’s Enterprise Monitor* application to a client recently. I was demonstrating the “graphs” section of MEM, where you can monitor MySQL sessions, connections, replication latency and more with 60+ graphs. Usually, you view the graphs from within the MEM Enterprise Dashboard (via a web browser). But the client asked if there was a way to automatically download graphs. I wasn’t sure why he wanted to download the graphs (I didn’t ask), but I knew it wasn’t possible by using MEM alone. However, in the past I have written Perl scripts to automatically download files from web sites, so I thought I would see if it was possible with MEM.

I’ve just arrived at ANU in Canberra for the Open Source Developers Conference 2011 (OSDC). I’ve spoken at several of the past OSDCs that have been held around Australia: 2005, 2007, 2008, 2010 and now 2011. It’s one of those conferences with great energy and great people that’s organised by dedicated members in the community who build the conference they want to go to.

I’ll be giving two talks this year:

• Dropping ACID: Eating Data in a Web 2.0 Cloud World
• Drizzle 7: GA and Supported: Current and Future Features

Thanks to the community for a great turn out at the OTN Developer Day: MySQL in Minneapolis, MN.

The room was packed and we had to bring more tables in to handle the crowd. Sessions covered enterprise, replication, overviews and perfomance.

I hope the local MySQL user group can support the new members in their area.

http://www.meetup.com/mn-mysql/

Best of luck to everyone and thanks again.

Thanks to everyone who signed up and attended the webinar I gave this week with Tim Callaghan on Scaling MySQL. For those who missed it and are interested, the video and slides are now posted here.

A brief description of the webinar is also below.

MySQL implementations are often kept relatively small, often just a few hundred GB or less. Anything beyond this quickly leads to painful operational problems such as poor insertion rates, slow queries, hours to days offline for schema changes, prolonged downtime for dump/reload, etc. The promise of scalable MySQL has remained largely unfulfilled, until TokuDB.

TokuDB v5.0 delivers

• Exceptional Agility — Hot Schema Changes allow read/write operations during index creation or …

Read the original article at Seattle Web Tech Meetup Nov 21

I'll be one of two speakers at the next Seattle Web Technology Bi-Weekly Meet up on Nov 21 at the Citrus Lounge.

They've sexed it up a little by calling it a face-off between Windows Azure and Amazon EC2  (no prizes for guessing which side I represent) but really it's going to be a primer on the Platform-as-a service and Infrastructure-as-a-service models. I expect some lively discussions during Q&A.

I'll be covering questions such as what cloud computing is, what EC2 provides, what is datacenter automation and the …

One of the great things about the HTTP protocol, besides status code 418, is that it's stateless. A web server therefore is not required to store any information on the user or allocate resources for a user after the individual request is done. By that a single web server can handle many many many different users easily, and well if it can't anymore one can add a new server, put a simple load balancer in front and scale out. Each of those web servers then handles its requests without the need for communication which leads to linear scaling (assuming network provides enough bandwidth etc.).

Now the Web isn't used for serving static documents only anymore but we have all these fancy web apps. And those applications often have the need for a state. The most trivial information they need is the current user. HTTP is a great protocol and provides a way to do authentication which …

Hi Martin,
great postings thx for that.
Im also migrating my vfp container to other backends. And I was searching and trying tools for that.
But there is a easier way.

Get a Omnis 5 Standard Edition for MySQL ( http://www.Tigerlogic.com)
Get the ODBC-driver for FoxpPro
Setup a ODBC-DSN for your Foxpro db
Start Omnis and setup 2 sessions in the session manager
Session 1: odbc to the vfp dsn
Session 2: to the Mysql db via MySQL Dam see also : http://www.tigerlogic.com/tigerlogic/omnis/technotes/tnsq0012.jsp
Then open both sessions
Now drag the vfp tables to the MySql session and do some finetuning
Example memo fields shout be varchar, byte a…
Index on deleted will not run, delete…

RRG
…

We at ScaleBase talk about sharding so much, it’s difficult for us to see why someone wouldn’t want to shard. But just because we’re so enthusiastic about our transparent sharding mechanism, it doesn’t mean we can’t understand the very basic question, “When do I shard?”
Well, it’s not the most difficult question to answer. I’ll keep it short: if your database exceeds the memory you have on a single machine, you should shard. If you hit I/O, your performance suffers, and sharding will assist.
Why? That’s easy to explain.
Databases in general (and MySQL is no exception) try to cache data. Because accessing memory is so much faster than accessing disk (even with SSDs), database providers have developed rather sophisticated caching algorithms. For instance, running a query caches the query and its results. Indexes are stored in memory so that, when running a query, the database doesn’t have to hit the disk …