Natim Shalom talks about scaling MySQL.
He reviews replication and sharding as a means of scaling and dismisses both pretty quickly in favor of a system called In-memory data grids (IMDG). From what I can tell this is a piece of middleware that sits between the application and the database. He describes it thus:
In-memory data grids (IMDG) provide object-based database capabilities in memory, and support core database functionality, such as advanced indexing and querying, transactional semantics and locking. IMDGs also abstract data topology from application code. With this approach, the database is not completely eliminated, but put it in the *right* place. I refer to this model as Persistence as a Service (PaaS).
I am not sure I get the point of this. From what I can tell it is just another layer of abstraction between the application and the database, a layer which sits in memory, is distributed across nodes and optionally offers a different data model to the application. I wonder if this is better than Hibernate which seems to offer the same features.
I also think he dismissed sharding too hastily, a lot of his arguments can be countered fairly effectively. For example he argues that disk I/O is a problem with sharding, but I would argue that sharding is done to deal with disk I/O, assuming of course that you are sharding across machines (which also increases your aggregate memory pool). Resharding can take place without taking the application offline, admittedly this is complicated. As for changes to the data model and application code, my feeling is that most data models can be sharded (some better than others), and you can abstract the shard selection code relatively easily so the application does not ’see’ the shards.
Still I think this is a thought provoking article well worth reading.
By way of Greg Linden, I just finished watching a tech talk given by Professor Gene Cooperman on “Disk-Based Parallel Computation, Rubik’s Cube, and Checkpointing“.
The part that interested me was Cooperman’s assertion that “disk is the new RAM” if you have enough machines in your cluster, reaching a point where the aggregate bandwidth of the disks reach that of RAM.
The first obvious thing that jumps is that this does not make any sense, while the bandwidth may be the same, the latency is quite different, and will be a performance killer.
Cooperman recognizes that and makes the point that you need to organize your disk accesses to minimize latency, basically avoiding piecemeal reading and going for batch reading. Effectively what you are doing is shuttling data to and from memory in very large batches. (As an aside this is nothing new, the Connection Machine 5 had a similar disk system and I am sure there are other such systems out there).
Tim Bunce has posted an interesting presentation on Perl 5 and Perl myths.
I have to confess that I have a special affinity for Perl as it was the first ’scripting’ language I learned, and I have used it extensively over the past 12 years. For example all the index administration code at Feedster was written in Perl, along with lots of parsing and utility libraries, and I always turn to it for all my ‘quick and dirty’ scripts, especially any text processing scripts.
ArsTechnica published an interesting article about the history of file systems which is a fun and interesting read.
Some interesting anecdotes I can add to this article:
A long time ago I worked in tech support for a company selling PC clones, I think we were delivering DOS 3.x at the time. I came across an interesting feature of FAT-32, which was that while you were limited to 512 files per directory the OS did not complain if you exceeded that limit. It would just extend the table into adjoining sectors and eventually either files would be corrupted if the table got too long, or files would be lost if the end of the table was overwritten by a new file.
More recently I tried JFS as an alternative to EXT3 at Feedster and was bitten by a bug of some sort which caused the file system to stop responding for 5 seconds at periodic intervals. This suspension was accompanied by a spike in CPU usage. Odd stuff, and I did not have time (or the inclination) to look for the cause so we just ditched it in favor of EXT3. We did look at XFS briefly but felt that there was too much risk involved since it would lose metadata is there was a crash or a power failure (we were using Gentoo at the time which did not help.)
USENIX has decided to make its conference proceedings freely available to all. A good move I think, which adds to the trove of publications already freely available.
It looks like Sun wants to put Java on the iPhone.My initial reaction was “why”. From what I can tell, the SDK is pretty good, though it does require you to learn Objective-C (in itself not a bad thing, the people who use it generally love it), and adding Java would add another layer of stuff between the application and the device itself when you really need all the performance you can get.
Upon more consideration I thought “why not”, it will be interesting to see how well (or how poorly) Java works on the iPhone.
The Database Column follows up on their original article about DBMSs and MapReduce.
Overall I think they do a very good job of addressing people’s comments about the issues. But I am left with one nagging thought triggered mainly by this sentence in the article:
As such, we claim that most things that are possible in MapReduce are also possible in a SQL engine.
The nagging thought is this: Are we trying too hard to solve very different problems with two very different technologies by claiming that one technology can do it all. The authors present a very good example which is hard to do with MapReduce but easy to do with an RDBMS. What they don’t present is the flip side.
I would suggest that parsing text and indexing it into an index for full text searching is a very good example of something that works really well in MapReduce, but would absolutely “suck” in an RDBMS.
Processing large amounts of log data would be another good example.
And I am sure there are plenty of others.
I would suggest that a good rule of thumb would be to look closely at the data you are processing. If there are lots of joins, or even one, an RDBMS would probably be a good choice. If your data is flat, then MapReduce would probably be a good choice. I hedge here because every situation is different and has to be considered on its own challenges and merits.
The bottom line is that someone who comes to me and says that “Language X” or “Tool Y” can do it all (and make me a cup of tea after that) is being a little jejune.
I recently had an interesting conversation with a colleague about optimization, profiling and telemetry as they relate to application performance.
About optimization, Donald Knuth said:
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
This makes perfect sense since you don’t know were the bottleneck are going to be before building a system. On the other hand, it does not mean that you should throw performant algorithms out of the window. You have to think performance at a local level when you write your code.
Profiling the application means running it with preset data and inputs to see where the performance bottlenecks are, at which point you can optimize the application. A profile will tell you where time is being spent, down to the function, and sometimes down to the line. I have found useful to always reuse the same set of data and inputs so I can track the performance effects of changes. Of course you need to make sure that the data set an inputs provide good code coverage.
Profiling should also give you a good idea of how long it takes to perform operations. This becomes important when you take your system to production, and gather telemetry.
Telemetry (credit goes to Dan Pritchett for the term) is the collection of data on a running application, tracking how long certain operations take, getting data from a database or running a search for example. This data can be collected and monitored.
For example if you have to contact a number of web services to construct a web page, you should capture the time each of those services take. That way you will be able to see the maximum, minimum, mean and median times it takes for each of those services to run. By monitoring this data you will be able to tell when a service is underperforming and take action.
Interesting column in The Database Column comparing MapReduce with DBMSs.
I think the author rather misses the point of MapReduce and the column comes off like a comparison of apples and oranges.
The comments are very interesting and are worth reading.
I have heard this before, actually the first time I heard this was in 1989:
An even more fascinating metric is this: 5% of programmers are 20x more productive than the other 95%. If this were a science, like it claims, we could figure out how to get everyone to the same level.
From a commencement address given by Bruce Eckel for Neumont University, a school in Salt Lake City.
