SPC14: Search architecture and sizing in SharePoint 2013

In this session we will dig into the new architecture for Search in SharePoint 2013. We will cover all architectural components, plus discuss the differences between the 2013 release versus FAST Search and search in SharePoint 2010. Microsoft has updated topology models for different sized deployments. This will be presented along with sizing and scaling data for both physical and virtual machines - actionable data you can use to assess and use during your planning phase. We will also cover planning for high availability, backup/restore, and migration.

Here are my session notes for “Search architecture and sizing in SharePoint 2013” by Barry Waldbaum and Thomas Molbach.

Search Architecture

Thomas briefly explained the Search Architecture – nothing new here for me, its very well documented on Technet.

Scaling

SharePoint 2013 Search scales pretty well –. I tried it in a project and it works.

.

Web Front-End

Display Template, Query Rules – quite a lot happens on the web frontend.

Analytics

With the analytics service you can do very great things because it provides the insights behind the “Trends” in SharePoint. It even provides a view counter.

Search Query Tool

Thomas showed some nice tricks with the awesome Search Query Tool. There is a property called recommendedfor that accepts a url and shows what other items are recommended for the given url. Then he filtered on ViewsRecent to show the elements that were recently clicked on.

More about the tool will be announced tomorrow by Mikael Svenson (blog).

Sizing

Benchmark the VMs to verify that you get the performance they IT department promised you

Scaling from small 10M to 40M:

Average document size is 250KB

I use that as a rule of thumb, too - but it has constraints.

SharePoint 2010 had Single Point of Failures – SharePoint 2013 does not have this anymore

Large Topology: 100M Enterprise

24 Servers – phew.

October 2013 Cumulative Update

High Density Indexing: 4 Index Partitions per Node – this cut the amount of server requirements in half (less licenses!) but you have to scale up your hardware.

Q: Why only 10M items in one index?

A: Higher amount: Backup takes longer, Response time gets worse

Analytics: Scale-up, otherwise it eats more network.

That was incredible - I had to stop taking notes, really dense information delivery 🙂

Backup and Restore

Robust backup, no Query Downtime during backup – it is even supported to restore QA backup on PROD (same topology).

Migration

Re-Implement

Create everything from scratch.

Search First Migration

Publish Search Service Application – done that, works great.

Migrate from SharePoint 2010

Attach the Search Service Application Database

Migrate from Fast Search For SharePoint 2010

Backup/Restore Database – PowerShell script to to some work.

Summary

Apparently 50% of the session was not in the description – I expected more Sizing and Architecture and was close to leave the audience. Then the good part with the sizing started and provided really good value to me. WOW – had a blast! The changes that happened in October 2013 CU/SP1 for search are really incredible. Additionally, I waited in the queue because there were so many questions – and learned even more. Great stuff. Did I say it was great yet?