Search in Windows Azure
Hi all,
We are starting work on enabling Sitefinity Search on Windows Azure cloud environments. The main goal of this feature is to enable the use of Sitefinity Search - indexing and performing search in cloud environment. For the purpose of this we intend on integrating with external search services such as Apache Solr or ElasticSearch.
We would be happy to hear about your use cases and requirements for setting up Sitefinity Search in Windows Azure deployments.
We will be posting updates on the feature in this thread. You can subscribe and follow it for updates.
Regards,
Radoslav
Sitefinity Team.
Please also consider Azure Search as well.
Thank you for the suggestion Jason. We will put this on the list of possible solutions as well.
While you're working with Search, please add Search widget templates.
This is great news. Its been an outstanding issue for a while.
www.sitefinity.com/.../sitefinity-search-in-windows-azure
Yes I would love to see Azure Search as an option as well.
Search to work for Sitefinity running on Azure Websites. Not Cloud Service.
I wrote a post on how I currently achieve it
www.sitefinity-stuff.com/.../azure-and-search
Multiple instances of Azure websites.
I would love to see more support for Sitefinity in Azure in general. For example extending the Sitefinity cache to use The Azure cache so we can run it on many instances.
Very interested in the integration with ElasticEearch in Azure.
Hi all,
We have decided that our main focus will be integrating with the Azure Search service. The integration with Azure search will also be functional in non-Azure deployments. Apart from integrating with this search service will will be also investing time in making sure that the Sitefinity Search API allows developers to plug into external search services with minimal implementation.
For anyone willing to preview this feature - we will push a preview build for this feature in the beginning of November.
This is great! I am looking forward to it.
We are ready with the preview build. Please note that this build is intended only to preview the support for Windows Azure search feature and should not be used in any projects that are in production or under active development. This build does not contain other upcoming features, the only difference with Sitefinity 7.2 is the support for Azure Search. In order to run the preview build you will need a valid Sitefinity 7.2 license. Further information on what's included in the preview build can be found below:
This feature allows the use of Sitefinity Search in Windows Azure cloud service deployments. However the feature can also be utilized in other deployment scenario - for example VPS or Load Balanced environment. In order for the Sitefinity Search to be running on Windows Azure, an instance of Azure Search must be created. Details about creating such service can be found on the azure website: http://azure.microsoft.com/en-us/services/search/
After the search service has been set there are few settings that need to be considered:
These two properties will be needed for Sitefinity to connect to the Azure Search and fetch / push data to the cloud service.
In Sitefinity we have introduced a new basic settings section which allows choosing of the following options:
If AzureSearchService is chosen, there will be options to enter the URL / IP address where data will be sent and also API key. In both fields, the data should be corresponding with the data from the Azure Search service that was previously created.
After the changes are successfully saved, a search index can be created, which will exist in the cloud.
For the Azure Search we use 3rd party SDK, built to provide usable API for the Azure Search calls. The SDK is called RedDog.Search. The SDK and its API are open source. We plan repacing the RedDog.Search SDK once Windows Azure releases officially supported SDK for Azure Search.
The search result contains 2 results if we search for thread or post.
As the exceptions are not handled (yet) there might be YSODs (e.g. if there is an Azure connection error).
You could check Error.log file for possible problems.
This is the interface of the application service (in contrast to a web service) in Sitefinity responsible for full-text search capabilities of the system.The default implementation, coming with Sitefinity out-of-the-box is based on Lucene.Net and keeps the search indexes on the disk.
By implementing this interface and replacing (using ObjectFactory.RegisterType) the default implementation with a your custom one, you can make Sitefintiy talk to a different search backend, like ElasticSearch, Apache Solr, SharePoint Search, etc.
Sitefinity calls the UpdateIndex method of the registered (your) implementation on each item creation/modificaion, providing a collection of IDocument instances to be added/updated into the index.
Sitefinity calls the Search methods of the registered implementation each time the user uses the built-in search box widget. If you ensure that the built-in search box and search results widget are not used in your site you can skip implementing those and use your custom widgets to directly query the search backend of your choice.
The Search method takes ISearchQuery as a parameter. In the default implementation the query is created and it's ISearchGroup groups are built using IQueryBuilder's BuildQuery method. You can add/remove groups to the query once its built.
ISearchGroup - Contains ISearchTerm and ISearchGroup enumerations. When building the search expression, the goup's Operator is used between the terms/groups.
ISearchTerm - Describes a search term with it's Field and Value.
public class MySearchResults : SearchResults protected override SearchResults.ISearcher GetSearcher() return new MySearcher(this); protected class MySearcher : SearchResults.ISearcher public MySearcher(SearchResults control) this.control = control; public IEnumerable<Telerik.Sitefinity.Services.Search.Data.IDocument> Search(string query, string catalogue, int skip, int take, out int hitCount) var control = this.control; var service = Telerik.Sitefinity.Services.ServiceBus.ResolveService<ISearchService>(); var queryBuilder = ObjectFactory.Resolve<IQueryBuilder>(); var searchQuery = queryBuilder.BuildQuery(query, control.SearchFields); searchQuery.IndexName = catalogue; searchQuery.Skip = skip; searchQuery.Take = take; searchQuery.OrderBy = null; searchQuery.HighlightedFields = control.HighlightedFields; // Contains the default filter - by current language var currentFilter = searchQuery.Filter; var myDatesFilter = new SearchFilter(); myDatesFilter.Operator = QueryOperator.And; // Here we add a clause, that only results for the last 10 days will be displayed myDatesFilter.AddClause(new SearchFilterClause("PublicationDate", DateTime.UtcNow.AddDays(-10), FilterOperator.Greater)); // Persist the language filter, if exists if (currentFilter != null) myDatesFilter.AddFilter(currentFilter); searchQuery.Filter = myDatesFilter; IResultSet result = service.Search(searchQuery); hitCount = result.HitCount; return result.SetContentLinks(); protected readonly SearchResults control; You can download the preview build from here.
A sandbox is also available here: http://azuresearchpreview.cloudapp.net/.
@Radoslav
Okay so it seems to behave just as poorly as Lucene
azuresearchpreview.cloudapp.net/search-page
azuresearchpreview.cloudapp.net/search-page
Is this a gimpy azure&lucene thing or a sitefinity thing? Like Christopher should come up in the results without the user needing to put in a wildcard character (Chris*). More along the lines of the Google-Like...but just curious.
Hi Steve,
In fact this is the default behavior. It will be a breaking change if we change it but you could easily substitute the ISearchService implementation and provide your own. (e.g. derive from AzureSearchService and change the implementation of the Search method as you prefer.)
BR,
Dimitar
Is it technically "Breaking" if it improves the feature (is desired functionality)? What would be the uproar here..."AWW DAMMIT, SEARCH WORKS NOW!" :)
I agree with Steve. I would say that it is worth introducing this as a breaking change. Take full advantage of the new abilities at the start.
Do a targeted survey of customers.
Or provide two versions. Azure Search with the old way or Azure Search with the new.
Hi Steve,
We will change the default search behaviour. We are thinking of always using starts with for search terms. So when you type in Chris it will also return results for Christopher.
This is great news :)
IMO when I do a search like in an autocomplete or something I do StartsWith, then Contains, then EndsWith (or visa\versa) to get the best results. But definitely anything is better than the current exactmatch!
Thanks guys
Hi all,
We've updated updated the preview sandbox. The new feature which is added is autocomplete. This will be available for all search services (Lucene, ElasticSearch and Azure Search). Feel free to checkout the autocomplete here: http://azuresearchpreview.cloudapp.net/.
Hey Rado, if you're playing with the widget ANYWAY...can you change the <input> to a <button> ...or modify the code so it could use either\or...something? <Button> is way easier to style (like if you want to drop in a fontawesome icon or something).
2) Please don't force jquery-ui autocomplete on us...if we have kendo already loaded it's already working and styled...this adds a new script and styling (and it doesn't work as well as kendo)...feels ghetto. If you've already commited to kendo in things like the menu why would we go jqueryUI on search for no apparent reason?
...and you likely know this anyway (not completed yet)...
Elasticsearch returns 2 results
Elastic returns 0
search returns 2 (with nothing related to the Elastic prefix though)
The StartsWith is not implemented, yet. So this explains why you are seeing results only for the complete words.
Will see what we can do about the rest.
Could you maybe do with the autocomplete as you did with the menu? Put the script code into the template itself. That way we can swap in our own implimentation as needed, or yank the code out to our own external script files, or just outright delete it...gives us options. As is to swap jqueryui for kendo we'd have to impliment our own version of the searchboxes .js to override native functionality.
Autocomplete is definalty cool to have, I'm just concerned that if it goes in like this...it's never gonna change. Think of it this way...kendo autocomplete script is already being downloaded in the page...it's already there and for no reason we're opting for a slower one both in page size and rendering.
Thank you for all the feedback. The feature has been released with Sitefinity 7.3. I am closing the thread now.