다음을 통해 공유

Tales from Training: FAST Search for SP2010

  • 아티클

So, today I started day one of my week-long FAST Search for SharePoint 2010 training. Over the next couple of days, I wanted to share some tidbits that I found interesting (and hoping it may help someone else along the way). In no particular order (and provided with very little testing on my part to confirm said tidbits...)

  • The Managed Property ServerRedirectedUrl contains "a URL used in association with Web Access Companion (WAC). This enables you to provide thumbnail previews in the result." (https://msdn.microsoft.com/en-us/library/ff407618.aspx)
    • Key Takeaway: In theory, you could implement thumbnail previews in SharePoint Search results (e.g. without FAST installed) by building a custom results web part and leveraging this Managed Property (woot! I see a future blog post topic) 
  • The FASTSearchKeywordAdministrators group provides a means to delegate control over Search Keywords (for example, to Site Collection Admins) without having to add those users as FAST Admin(s)
    • Note: This group is not automatically created during installation, but can be created manually [as a local group on the FAST Search Server 2010 for SharePoint administration server] if you want to use this level of authorization. (https://technet.microsoft.com/en-us/library/ff381251.aspx)
  • Click-through: For both SharePoint Search as well as FAST Search, SharePoint tracks the user click-through within the search results web part. These clicks are then fed into the relevancy engine to help better order future search results. For example, if users regularly search for 'foo' and then tend to click on the fourth result, the search relevancy engine will learn from these clicks and then boost this particular result higher in future queries
    • Key Takeaways:
      • This click-through data is stored in the Query SSA
      • Then on a nightly occurrence, the FAST Search Server 2010 for SharePoint Click Through Extractor Job "extracts click-through data and uploads them to the configured FAST Search Server 2010 for SharePoint farm. The collected click-through data is used for relevancy tuning." (https://technet.microsoft.com/en-us/library/cc678870.aspx)
  • (This is a point I need to further clarify... but from my understanding) Managed Properties (for FAST) are tracked in the Query SSA.
    • The actual mapping of Managed Properties to particular content (e.g. the table that connects particular indexed content to a managed property) exists in the FAST Admin DB... however, this would seem to conflict with my next bullet
  • SharePoint Search vs FAST Search:
    • With SharePoint 2010 Search, crawled properties exist in the Property Store DB and the Full Text Index exist as files on the Query server(s). 
    • With FAST Search, no crawled content exists in a SQL Server database - instead, all crawled information exists directly within the index
  • Heads Up: When you create the Query SSA, the typical start addresses will be added to the content source. For example, something like: https://our.fake.com, https://my.fake.com , and sps3://my.fake.com. In this case, remove everything except the sps3://my.fake.com start address, which will be used for crawling the Profile Store (aka: the "People Crawl")
    • Key Takeaways:
      • FAST Search handles People Search requests by leveraging a federated request to the Query SSA
      • It's also worth noting that the Content SSA handles the crawling of content (e.g. SharePoint Sites, file shares, etc), but the Query SSA (in addition to its roles related to queries) handles the crawling of the Profile Store
  • On the Reading List: How FAST Search for SharePoint Fits into SharePoint 2010 (en-US)

 

That's it for today, but I'll try to add as much as I can over the coming days.