In SharePoint 2013 Search, we have Content Sources and Result Sources.
We have Result Sources, Result Types, Result Blocks and Result Sets.
Not to mention Query Rules and Query Builder that one can see everywhere, but defining them is not easy at all. Looks like Query Rules are the "fresh air" of Search in 2013. We feel it, we need it, but it’s hard to touch it...
This is why I decided to create a "big picture" of SharePoint 2013 Search. I'd like to emphasize that it may be complex, BUT the beauty of it is in this complexity: there is so much you can build with Search!
Well, what can you see on this "big picture"?
On the left side are the source systems, with all the data you can "pull in" to SharePoint Search. The most important types of data sources are SharePoint sites (of course), file shares and database content (through direct DB access or Web Services), but you can also connect to Exchange Public folders and web sites (for example, your company's public website). If you have some very specific system, you can also write or buy a 3rd party custom connector (for example, to SAP).
You can connect these systems by creating Content Sources in SharePoint. I wrote a blog post on "How
to Organize Content Sources" a while ago, you can find some best practices there.
The process, in which the Search Engine enumerates and gets the content from these systems is called Crawling. The crawled items will then be indexed into the Local Search Index.
Based on the local index, we can create Result Sources. They can get the indexed items from one or more Content Sources, and we can also apply some filters there. For example, a Result Source can be "Documents" from "everywhere", or "Old content" including everything that is older than 3 years.
Another way to pull content in to SharePoint Search is through Federation: you can define Result Sources to use a remote index to provide the results from. With this, you can provide results from huge web sites like MSDN or Financial Times, or from places that use different security options, etc. You don't have to build the index as you use it from a remote location, but you need live Internet connection; and there are other limitations, too.
Besides the "content" itself, we store a lot of metadata in the Local Search Index which can be used in a lot of different ways. For example, they'll be the basics for the Refiners; we can Sort the results by them; we can display them on the Result Set and/or on the Hover Panel, etc.
Don't forget: metadata is the "glue" of Search, and despite it's a relatively small part of the picture above, this might be one of the most important things in the full Search story!
Query Rules are in the middle, because as I said, they are everywhere. You can use them to transform a query, to change the ranking of the results, to display various Result Blocks (Oops, one more Search term here!), etc.
Result Sets are basically where we display the results in. They can use Query Rules as well as various Result Sources. They can also display various metadata (managed properties) from the Local Search Index. They also use Result Types to decide which item should get displayed in what way (for example, a Word document will be displayed differently than a Calendar item).
Hover Panel gets displayed when the user hovers the mouse over a result in the Result Set. Hovel Panel is the flyout card with the document preview (if it's available), with some metadata, and with some actions to take on the results (e.g., open the document, open its location, send it to someone, start a workflow, etc.) Again, Hover Panel is tied to Result Types - different types have different Hover Panels.
If it's all together, the results are ready to get displayed - the last question we have left is “How?” The answer is formulated in Display Templates. They define the way the results have to get displayed (by Result Type, of course) as well as how the Hover Panel will be displayed. Moreover, we use Display Templates for the Refinement Panel.
To make a long story short, this is the "big picture" of Search in SharePoint 2013. Of course, each of these pieces would be worth a separate blog post, or sometimes even a separate book (like Query Rules, for example). Hope this helps you to understand how these pieces work together - please let me know if it makes sense, if I should change or add anything. This is still evolving.