A fast presentation on search
•
0 likes•326 views
This presentation discusses FAST (Federated Architecture for Search), a solution for federated search across multiple data sources including SharePoint, SQL Server, and Active Directory. It covers the problems with existing search solutions, an overview of the FAST approach, configuration details, indexing, querying, facets, results, and performance. The presentation concludes by discussing future implementations providing federated search across multiple clients.
More Related Content
Viewers also liked
Viewers also liked (10)
Similar to A fast presentation on search
Similar to A fast presentation on search (20)
More from Creative Sharepoint
More from Creative Sharepoint (13)
Recently uploaded
Recently uploaded (20)
A fast presentation on search
- 1. A FAST Presentation On Search March 2012 Adrian Johnson @arptastic adrian@creative-sharepoint.com 20 X 20 FORMAT 1
- 6. The Proof of Concept SQL AD Sharepoint FAST 6
- 7. The Configuration Sharepoint/FAST Sharepoint/FAST Sharepoint/FAST FAST AD SQL 7
- 9. Indexing 9
- 10. …more Indexing JDBC 1 0
- 11. JDBC 11
- 12. Querying 12
- 16. Gotchas 16
- 18. Future Implementations Client 1 Federated Client 2 Search Client 3 18
- 19. Reality Check 19
- 20. Conclusion 20
Editor's Notes
- NamePositionCompanyAround since 2006We do pretty much any consultancy work around SPContact detailsOur experience with FAST search in a LOB application
- Our client: Learning ProviderFrom scratch system – line of business appNeed to manage back office …and portals for their clientsTheir clients need to search the courses on offer…they need to search _all_ of their backend data as well as their courses
- SharePoint Enterprise SearchIs SharePoint NativeWon’t directly talk to LOB dataWould mean breaking into BCS ???We (will) have a lot of dataSQL (Fulltext)Good, well established technologyAlready have it licensedImpact on performanceWon’t scale as system grows
- Part of the SharePoint stackBackend was originally developed for indexing…And serving queries for line of business data…Which is exactly what we want to doSome nice features for searchingSharePoint (for a later phase)Will scale way beyond what we need but will provide value in minimal redundant / balanced configuration
- Plan:Find out what it can do: Lot’s.Can it do what we need? Yes – and then some.Can we deploy it, develop it? Yes.Can the client afford it? Yes.
- Straight forward Sharepoint deploymentSeparate servers for each roleSet out to index some data in FAST and query it (adventure works)
- Following on from PoCSet up a development farm (for dev. team to work on)Central SQL server Each development working on their development boxesSharepoint on each box with FAST
- Wizard based - 2 MethodsStandalone – only for development / testingXML - Allows configuration of multiple nodes, scalingSharepoint configuration required – minimum 2 service applicationsLike SharePoint search you have to bring in managed propertiesTook a number of goes to get this right – can be quite sensitive
- Indexing is quite an important part of any search server…You don’t have much to search without itFAST is very scalable in terms of how it indexes…Work can be split across many nodesAlso very flexible in WHAT it can index…Web, SharePoint, LOBIn SharePoint - usually this would be configured through UI…but LOB data with FAST means we have to break out some PowerShell and XML
- Need to use JDBCConnector (Java Database Connectivity)JavaApplication that sits alongside FASTAllows you to index a multitude of DB serversRequires a SQL query…We would recommend a stored procedure for easier maintenanceAutomatically recognises meta data and columns…All you need to do is configure managed properties
- Write a stored procedureCreate an XML definition for the JDBC connectorModify the file – lots that can be configured here…But primarily we’re interested in making sure it’s pointing at the right data sourceEnsure connectivity works between connector and DBRun the connector
- Provided the configuration and indexing has gone well…You should be able to use free text query within SharePointCan then pull back data FAST has indexedGood way of testing FASTHowever - considering it’s a LOB application…More flexibility required than the out of the box search pages requiredNeed to look at the Sharepoint Search API for customisation
- Search MethodsSharepoint (Standard & Enterprise)Nice and easyDoesn’t take advantage of FAST featuresAllows you to provide logic as to what gets returnedFQLPowerful querying languageAllows you to make use of all additional FAST functionalityExample – you can use weighting to provide context aware resultsProject manager will see more relevant course and events to their role.
- For our custom app it’s down to developers to put togetherWe’re building the application and LoB data, so we know the DB well…And therefore the facets required – really just need some logic to string the queries togetherFAST allows you to query against all standard data types (string, numbers, etc)Results come back in tabular format, so can bind any ASP.NET controls as required
- …We use Telerik heavily for line of business apps so the RadGrid was our control of choice We’re a big fan of RadGrid – but it wasn’t always that way…!A lot of learning around page lifecycle…Very predictable, once you learn behaviourQuick, work well with the rest of ASP.NET and ultimately…Reduces the amount of time spent developing
- Java JRE Version – has previously affected JDBCRunning FAST on VMs does not give you maximum performance – to be weighed upNot much documentation around, the really useful stuff is mostly blog basedSome resources on MSDN / TechNet – but there’s not much substanceGenerally not a massive community around FAST at the momentIt’s difficult to get into – you have to make sure it’s really worth the learning commitment
- As can be expected, queries are served very quicklyIndexing does take a surprisingly long timeConsider how often your data changesA modest table with - 12 columns takes 2-4 minutes to index 1000 records – albeit on a relatively small environmentResource hungry (keep on separate machines to other nodes in your farm)Uses lots of CPU and memoryUse best practices – don’t deploy it on your frontends!
- Functional progressions:Using FQL to provide user / context aware search resultsIncremental crawling through JDBC – still researching…Unfortunately not as simple as flicking a switchNatural progressions:Bringing in federated searchMore facetsOptimising for mobile
- FAST is bigIn fact... it might be too big Reality: Unless you need lots of scalability, indexing huge amounts of SharePoint content… or like us you have a very specificLoB requirement... it might be worth sticking with SharePoint Enterprise.As previously mentioned, getting support and finding documentation is difficult....If you can get it to work for you and your clients and (more importantly) you can support it…I's a worthwhile endeavour.
- Although there was a high initial investment in getting to grips with the technology, for us it has been a worthwhile experience.In the future, should similar requirements appear we will be able to cater for them more easily.…And of course any knowledge is good knowledgeHappy to take questions during the question break