Google Architecture - High Scalability -

Google Architecture - High Scalability -

Information Sources

1. Video: Building Large Systems at Google
2. Google Lab: The Google File System
3. Google Lab: MapReduce: Simplified Data Processing on Large Clusters
4. Google Lab: BigTable.
5. Video: BigTable: A Distributed Structured Storage System.
6. Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.
7. How Google Works by David Carr in Baseline Magazine.
8. Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.
9. Dare Obasonjo's Notes on the scalability conference.

1. BigTable has three different types of servers:
   - The Master servers assign tablets to tablet servers. They track where tablets are located and redistributes tasks as needed.
   - The Tablet servers process read/write requests for tablets. They split tablets when they exceed size limits (usually 100MB - 200MB). When a tablet server fails, then a 100 tablet servers each pickup 1 new tablet and the system recovers.
   - The Lock servers form a distributed lock service. Operations like opening a tablet for writing, Master aribtration, and access control checking require mutual exclusion.

1. A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.

Lessons Learned

1. Infrastructure can be a competitive advantage. Many companies treat infrastructure as an expense. Each group will use completely different technologies and their will be little planning and commonality of how to build systems. Google thinks of themselves as a systems engineering company, which is a very refreshing way to look at building software.
2. Spanning multiple data centers is still an unsolved problem. Most websites are in one and at most two data centers. How to fully distribute a website across a set of data centers is, shall we say, tricky.
3. Take a look at Hadoop
4. An under appreciated advantage of a platform approach is junior developers can quickly and confidently create robust applications on top of the platform. If every project needs to create the same distributed infrastructure wheel you'll run into difficulty because the people who know how to do this are relatively rare.
5. Synergy isn't always crap. By making all parts of a system work together an improvement in one helps them all. Improve the file system and everyone benefits immediately and transparently. If every project uses a different file system then there's no continual incremental improvement across the entire stack.
6. Build self-managing systems that work without having to take the system down. This allows you to more easily rebalance resources across servers, add more capacity dynamically, bring machines off line, and gracefully handle upgrades.
7. Create a Darwinian infrastructure. Perform time consuming operation in parallel and take the winner.
8. Don't ignore the Academy. 
9. Consider compression. Compression is a good option when you have a lot of CPU to throw around and limited IO.

Read full article from Google Architecture - High Scalability -