What can Google hold in RAM?
For those that might not know, RAM = Random Access Memory. This is the memory that a computer uses to temporarily store data while it is in use. If you have bought a computer recently, or are familiar with the specifications on your computer, you will notice that it will be anywhere from 512MB to 4-6GB. Your hard drive capacity (which is the other GB rating on your computer) is usually much larger. Say 250GB, even up to 2,000 GB (2 Tera Bytes) in some cases.
Taken by DailyInvention (Flickr)
Google Fellow Jeff Dean gave a talk at a conference called LADIS 2009 – Large-Scale Distributed Systems and Middleware. In his talk, he shed some light on some of the server configurations that Google uses to power their almighty search engine and myriad of other services.
Here are some interesting facts that I pulled out from his slides:
- Each of Google’s servers has about 16GB of RAM, with approximately 2 TB (about 2,048 GB) of Hard Drive space
- There are between 40 – 80 servers in a rack.
- There about 30 racks in a cluster, connected to one switch called a ‘Cluster Switch’
So what those few facts tell me is:
- Each rack of servers, can have between 640GB to 1.28TB of RAM. This means that in one rack of servers, Google can have more RAM storage than many people have of Hard Drive Storage.
- One cluster of racks, can have between 19.2TB to 38.40TB of RAM.
So remember the RAM that your computer has, yes the 2GB….well..Google has, quite literally, thousands of times more than that in one cluster.
What does this mean? The read/access time is significantly faster when data is stored in RAM, as opposed to on your hard drive. That’s why, whenever you are using your computer if you aren’t doing too much, everything is so zippy. The moment you decide to either edit a large picture, look at videos stored on your computer, listen to music, edit music, or do anything that requires your hard drive to start to make a noise, it goes much slower.
According to Jeff, the time it takes to read 1MB from RAM is 80 times faster than the same file size from a perfectly functioning hard drive. So if you could hold all of your data in RAM, and force your operating system to read from RAM only, there would be a SIGNIFICANT performance increase. Not likely to be an exact 80 times faster, but MUCH faster.
Now…back to Google. Let us just look at what one rack of servers can hold – then you can scale it out in your head and realize how much RAM capacity Google has.
Greg Linden, who gave me the idea to write this post, writes:
For comparison, a large web crawl with history, the Internet Archive, is about 2 petabytes and “the entire [written] works of humankind, from the beginning of recorded history, in all languages” has been estimated at 50 petabytes, so it looks like Google easily can hold an entire copy of the web in memory, all the world’s written information on disk, and still have plenty of room for logs and other data sets. Certainly no shortage of storage at Google.
Let’s take it a step further.
Apple guesstimates that 1GB can hold approximately 250 songs, or roughly 1 hour of video. Also let us assume that the average size of a picture is 250K, based on unscientific observation. One DVD can hold approximately 4.7GB of data, while one Blu-Ray disc can hold approximately 50GB. Using those figures, means that one rack of Google’s servers can hold:
- 12.8 to 25.6 Blu-Ray Discs or
- 136 to 272 DVDs or
- 640 to 1280 hours of video or
- 160,000 to 320,000 songs or
- 2,621,440 to 5,242,880 pictures IN RAM!!!
If you want to scale out to one cluster, we are looking at approximately 30 times all of the above numbers. I don’t know exactly how many clusters there are in one datacenter, but I would imagine anywhere from 20 – 100 (possibly more, possibly less). I also don’t know exactly how many datacenters Google has, but I do know it is more than 30, because there are at least 20 that we know of in the US alone.
If you liked this post, subscribe to my feed to get notifications on other posts, and you should follow me on twitter here.
Related posts: