I am building something similar to some Blogfarm and that i discovered a little hurdle. I made use of the Wordpress Multi-User database like a reference and observed that the unique table is produced for every blog that's being produced.

Therefore if the farm will have, say, 'x' million customers (only a strange thought), then your database would ideally have 'x' million tables, presuming a person for every blog.

  1. May be the one utilized by Wordpress MU, a great db design? If so, just how much impact wouldn't it dress in the database performance because of so many 'x' million tables?

  2. Since I am just beginning to code, I've the freedom to select any database I love. Presently I am using PostgreSQL coupled with Ruby on Rails. Do you consider a NoSQL database (like MongodB) could be useful in cases like this? Otherwise, why/why don't you? I've not seen any blog platform operate on a NoSQL db yet.

  3. How can the large men like Blogger, Tumblr or Squarespace get it done?

Any assistance is much appreciated, Thanks.



  1. Most likely adequate. My prediction is it has mostly caching issues. For those who have 1000's of blogs on a single server and every is every bit apt to be hit, then caching will probably be a nightmare, and most likely most queries will have to hit the hard disk (cold cache hits). However, if most queries hit exactly the same blogs, and therefore exactly the same tables, caching is going to be adequate.

  2. My honest advice may be the following. Perform the easiest factor and end up forgetting about scalability problems for the time being. 99.999% of internet sites don't do enough visitors to warrant any sort of problems, and also the .001% of websites which do, may have the assets to really rewrite any code base therefore it scales. Within this context, make use of the following guideline:

    • RBDMS are usually adequate for many uses. In addition they're very stable and well supported. RBDMS have been in existence for 4 decades. :-)
    • NoSQL databases possess a couple of, very specific uses where they shine (e.g. document storage, billion row tables, huge scalability constraints), however they've gotchas (see BASE vs ACID) plus they do represent an elevated risk because they are more recent, less understood concepts.
  3. I suppose they are doing it through some type of sharding. Quite simply, you actually might have countless tables split across 1000 of servers.

The primary point here is this fact architectural option is a downside. For those who have sites with large traffic, you'll need more db servers which enables you to definitely scale horizontally. However, for those who have lots of site with little traffic, you most likely don't have to scale much.