« May 2007 | Main | December 2007 »
I have been looking for a new project to work on. Last Saturday I went to a party on the USS Jeremiah O'Brien. The engine room was amazing they have an all-volunteer staff and I am thinking of seeing if I can help out on the engine. It is a four story closed loop stem engine that uses see water to recondense the steam back into water before it goes back into the boiler. It looks like a whole lot of greasy fun to me. I have some more photos of it here.
O' HAI I has cuddle.
"""
Even though we shouldn't be, we're actually a little shocked. We'd always assumed the labels had met with a team of technology experts in the late nineties and ignored their advice, but it turns out they never even got that far -- they didn't even try! Understanding the Internet certainly isn't easy -- especially for an industry run by a bunch of technology-averse sexagenarians -- but it's definitely not impossible. The original Napster hit its peak in 1999 -- kids born since then have hacked into CIA computers. Surely it wouldn't have taken someone at Universal more than a month or two to learn enough about the Internet to know who to call to answer a few questions. They didn't even have any geeky interns? We give this industry six months to live.
"""
So I have been long frustrated with the fact that my camera's flash kind of sucks but that unassisted in low light it is nigh impossible (at least if your subject is breathing). So I had this idea that I could solve the problem and create some fun shots at the same time by using a flashlight to illuminate my subject. Here are the results of my first experiment with the idea.
The common method of read scaling is to copy read heavy data to more nodes. This increases the available read throughput of a datum by increasing the total amount of resources dedicated to serving it. This will always be necessary when the read load for a single datum surpasses the resources of a single node (IO, CPU, Network, etc). This method scales well but has the down side that it is often not efficient with respect to storage space. This is not so often a issue for data on disk but is a often issue for data cached in memory. The following example demonstrates the difference:
Let us posit that there two nodes { node1, node2 } and a data set having four datums, { A, B, C, D } with the load distribution <A:40%, B:40%, C:10%, D:10%>. To scale reads one could fully replicate the datums across both nodes, node1:{ A, B, C, D }, node2:{ A, B, C, D }. We would then distribute the query load evenly between the two nodes so they were each handling one half of the total load for the data. A second option would be to share the load between the two nodes by partitioning the data across the nodes. One such repartitioning is node1:{ A, C }, node2:{ B, D } resulting in the load distribution of node1:<A:40%, C:10%>, node2:<B:40%, D:10%>. With this partitioning the read load is still evenly distributed across the nodes but only half as much data is stored at each node.
Even though this example appears to assumes that reliable load data is available for each datum it is possible to achieve a even distribution of load by methods such as repartitioning with only node level knowledge. One such method would periodically randomly select a datum from node a with above average load and move it to a node with a below average load. Such a scheme should lead to a balanced cluster over time. ( This scheme will likely be discussed in more detail in a later post. )
The cost of using partitioning as a read scaling method is the added complexity of creating the partitions on the data and maintaining the routing information required to deliver queries to the appropriate node.Tags: Databases
This page contains all entries posted to 0x0000 in November 2007. They are listed from oldest to newest.
May 2007 is the previous archive.
December 2007 is the next archive.
Many more can be found on the main index page or by looking through the archives.
