l data movement as possible as you can (as the cost is too high).
5.No JOIN operation. Data is distributed ramdonly, and join operation brings extreme complexity.
6.As for data accessing, primarily, the operation focuses on the latest data, making optimization for this part and archieving old data.
7.Not store non-static data in center DB.
8.Global query using services or Memcached.

Memcached experience
Refer to my previous note: Facebook’s Memcached extension experience. Facebook made great improvement to Memcached. Besides, by the way, few days ago after releasing 1.2.7 version, Memcached released new version 1.2.8, revised some problems.
And there’s one valuable thing that is the description about achieving individual page data. And this is a delicate job you’d have to make single page Benchmark, probably product manager should be able to understand the “Defence” by engineers.
1.Get personal information data: by Cache, the data is got invisibly on user’s database. (get DB based on User-ID).
2.Get friendlink information: by Cache, otherwise, by DB (get DB based on User-ID).
3.From Cache, capture each friend’s 10 picture album IDs, and if it’s useless, capture from DB again (based on ablum ID).
4.Capture photo data from latest ablum at the same time.
5.Run php and execute the entire procedure logic.
6.Return data to user.

And then they made a description about Facebook’s non-LAMP stuff, basically, the source codes are free. At last, let’s take a look at two architecture pictures.
Architecture sketchmap for Facebook NewsFeed

Architecture sketchmap for Facebook search function