Question

I need to plan a Blogging Platform on Sharepoint which will have support for more than 40,000 blog sites. The users will come and create blog for themselves.

I checked here for capacity planning and the limits : SharePoint Server 2010 capacity management: Software boundaries and limits

Since a site collection can support 250,000 sites, I thought to keep Site collection as top level container and create the blogs as sites and sub-sites under root-web (such that no of sites at a level is <2000).

Later I saw that the max Content DB size is 200 GB which means I only have ~5MB for each blog ( 200GB/40000). This is too less for a blog as the blogger will also upload images while creating blog posts. I need at least 50MB for each blog and want to increase it on demand.

I am thinking to have multiple site collections but it will be difficult to manage users, branding, masterpage, CSS, navigation etc across the site collections. Also, I can't think of how to route a user to new site collection to create blog when 200 GB limit is crossed.

Any ideas for an alternate solution?

Also, I see that we can go up to 4TB of content DB in some special cases. Does anybody have experience with that?

Was it helpful?

Solution

I think SharePoint is a powerful, feature-rich, and extensible platform and can fulfill your capacity needs if DESIGNED correctly (Information Architecture, Solution Architecture, Infrastructure Architecture and Storage)

You can use a web application and divide the blogs into site collections. Below are few points that may adress your concerns:

  1. Categorize the blogs into at least 20-25 groups or subgroups (For e.g Technology,Finance,HR, Management etc). Create a site collection for each of these groups. You can then create a webpart that will ask user to select an appropriate category for his blog and redirect user to appropriate site collection (better, you can create the blog via code for user at respective site collection)

  2. To have uniform look and feel, You can create a Blog site definition with custom branding,css,master page. Or you can create a feature to apply all these artifacts when a blog is created using an existing site definition.You can use xml based or custom navigation which you can easily consume across site collections.This way you control it all from one location (14 hive)

  3. For data aggregation across site collections,you can use Search. You can create custom search webparts for displaying latest Posts, Tags, Authors etc. You can also create custom timer jobs to programmatically aggregate the data like total Blogs, Posts, Comments, Users etc
  4. You can exploit Service applications like Managed Metadata,User profiles for sharing content types(Content Type hub), term sets (for tagging),user information across site collections
  5. For Blog platform level admins and moderators ,you can use domain groups. SharePoint groups are scoped to the site-collection level, and they can be used only within the site collection. Domain groups can be used anywhere within the scope of the Active Directory directory service.

Please note, it is very important to have a solid Governance Plan in place for such a solution .Check this technet article Governance overview . A governance plan will help you to control the platform over time, and ensure that it runs smooth without introducing unnecessary risks.

OTHER TIPS

The minimum database size is a recommendation, not a stop. Check out my blog post on databases and SharePoint: http://davidlozzi.com/tag/database/.

If you're looking to move above the minimum requirements, you'll need to include additional maintenance tasks, possibly improve hardware and such. SharePoint can support 4TB databases, its up to the infrastructure to support it effectively.

If this is primarily a blog platform, then I would not be too worried about the storage size. The blog posts will not be that large, and unless the images are enormous they will not take up significant space. I agree with David's comments on database sizing and limits.

When thinking about quotas and sizing, you will find that you will not have uniform use from all sites. I typically plan for 20% of quota usage when I have large numbers of sites. With 40k sites, that it may be even less than that in your case.

With that said, I still like to try and have more site collections than sub-sites since it enhances your ability to administer it (permissions, backup/recovery, features). If your concern is branding and navigation, then you can easily manage this by installing a relatively simple set of features that can deploy your MasterPages, CSS, and a global navigation provider.

AS by its name SharePoint says it all, Share everything at a single Point to stop duplication of data, So If everything related to branding can be shared within Site Collection, I am not an expert but this is my Opinion, and you can create just one site definition and another Site template with a custom master page which can be shared between site definitions to create thousands of blog sites.

One thing out of topic I think yu should consider is that, if you will create blogs in SharePoint which means it will be doing some Application pool recycling at midnight or some other time on and blogs wont gonna be accessible (I am not 100% sure if it happens everywhere but it does happens in our SharePoint application)

Also another thing you will be considering is Memory Management, If there are thousands of sites, every single line of your code for webparts must be following SharePoint best practices.

btw If i was you, I would contact some SharePoint Hosting companies and get some advice as they must have done something similar, I know this company that does help SharePoint user group and other people, you must give them a try :)

this is a sharepoint hosting company that might provide you free sharepoint blog only if you request

No I am not a marketing guy for them, I just seen a MVP telling about them here

SharePoint blogger with extra ordinary architecture knowledge

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top