Saturday, August 27, 2005

There's More than One Kind of Scalability Take a look at: * http://www.possibility.com/epowiki/Wiki.jsp?page=Scalability * http://www.possibility.com/epowiki/Wiki.jsp?page=ScalabilitySolutions Scalability is the ability to keep solving a problem as the size of the problem increases. Scale is measured relative to your requirements. As long as you can scale enough to solve your problem then you have scale. If you can handle the number of objects and events required for your application then you can scale. It doesn't really matter what the numbers are. Scaling often creates a difference in kind for potential solutions. The solution you need to handle a small problem is not the same as you need to handle a large problem. If you incrementally try to evolve one into the other you can be in for a rude surprise, because it won't work as you pass through different points of discontinuity. Scale is not language or framework specific. It is a matter of approach and design. The Two Classes of How to Handle Scalability I've come to think there are two classes of scalability problems: * Scalability under fixed resources. * Scalability under expandable resources. The two different classes lead to solutions using completely different approaches. That's not to say they can't be mixed, but it's helpful to consider them separately when considering a design. * Scalability Under Fixed Resources In this class of scalability problem you have a fixed set of resources yet you have to deal with ever increasing loads. For example, if you are an embedded system like a router or switch, you are not likely ever to get more CPU, more RAM, more disk, or a faster network. Yet you will be asked to handle: * more and more functionality in new upgrade images * more and more load from clients The techniques for dealing with loads in this scenario are far different than load when you can expand your resources. * Scalability Under Expandable Resources In this class of scalability problems you have the ability to add more resources to handle more work, in general this is called [horizontal scaling]. The new era of cheap yet powerful computers has made horizontal scaling possible for virtually anyone. Many companies can afford to keep grid of hundreds of machines to solve problems. This is the approach google has taken to handle their search systems, for example, and it's a very different approach from a fixed resource approach. In a fixed resource approach we would be squeezing every cycle of performance of the resources, we would be spending a lot of time on developing new approaches and tuning existing code to fit the exact problem. When resources are available, and your approach is right, you can just add more machines. You start to figure out ways to solve your problem assuming horizontal scaling. In general this are is called data parallel algorithms.. For example, terrascale (http://terrascale.net/) has an amazing storage grid called Terragrid, that allows you to scale up by adding incrementally adding commodity machines. With the availability of 10Gb ethernet interfaces these approaches become quite powerful. Of course, your approach has to be right. If you select an architecture with single points of serialization then you won't be able to scale by adding more machines. * Examples of Dealing with Scale Here are a few examples of how different people have dealt with scale: * http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf - LiveJournal's Backend * http://labs.google.com/papers/ - google papers on their file system and cluster * http://mysqluc.com/presentations/mysql05/benzinger_michael.pdf - Multi-Terabyte Data Warehouse and MySQL * http://mysqluc.com/presentations/mysql05/dembecki_bruce.pdf - Lessons from an Interactive Environment * http://terrascale.net/ - Terragrid * http://www.possibility.com/epowiki/Edit.jsp?page=DesigningOfALargeScaleStreamingEventSystem comment[] 12:01:46 PM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:41:22 PM.