DB design and optimization considerations for a social application

Question

The usual case. I have a simple app that will allow people to upload photos and follow other people. As a result, every user will have something like a \"wall\" or an \"activity

Answer 1

There are many options you can take

• Add more hardware, Memory, CPU -- Enter cloud hosting
• Hows 24GB of memory sound? Most of your importantly accessed DB information can fit just in memory.
• Choose a host with expandable SSDs.
• Use an events based system in your application to write the "history" of all users. So it will be like so: id, user_id, event_name, date, event_parameters' -- an example would be: 1, 8, CHANGED_PROFILE_PICTURE, 26-03-2011 12:34, and most important of all, this table will be in memory. No longer need to worry about write performance. After the records go past i.e. 3 days they can be purged into another table (in non-memory) and included into the query results, if the user chooses to go back that far. By having all this in one table you remove having to do multiple queries and SELECTs to build up this information.
• Consider using INNODB for the history/feeds table.

---

Good Resources to read

• Exploring the software behind Facebook, the world’s largest site
• Digg: 4000% Performance Increase by Sorting in PHP Rather than MySQL
• Caching & Performance: Lessons from Facebook