Try our conversational search powered by Generative AI!
AI OnAI Off
What Search Should I Use If Find Is Not The Option
You need to convince your clients that Find is the perfect fit. It's the best, most scalable and least expensive (compared to writing search functionality from scratch with a custom index) solution.
Oct 21, 2015 7:54
I agree with Mari but if it's absolutely impossible to convince your clients about Find I would probably take a look at ElasticSearch and some .NET wrapper for it like NEST. But then you would have to handle all the events in the CMS to reindex content when it changes and make sure to index all language versions of your content etc etc. I haven't used it myself but I'm guessing it's a lot of extra work compared to using Find.
Oct 21, 2015 10:31
My experience:
Standard EPiServer search
Very good, extendable, requires no hosting / maintenance. The API has some limitations here and there, but you can always query the search index using Lucene.NET. You won’t get index locking issues as long as you keep only one instance of index writer.
Documentation could contain more code samples :)
http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-CMS/9/Search/Search/
Lucene.NET
Open source, pure .NET, no hosting / maintenance issues. In combination with Lucene.Net.Contrib, developers can make very powerful search solutions.
Developers have to code the indexing logic (what happens when editors move / publish / delete IContent), but that’s not something that takes weeks (at least not after a couple of projects).
Lucene.Net.ObjectMapping can also save some coding time.
With Lucene.NET, you have the full control, it can handle up to million documents w/o problems, etc. but
- It doesn’t have powerful tooling support. Can be difficult to debug search index and figure out why search queries don’t return some of the documents, etc.
- There can be only one instance of index writer.
- It can be challenging to use multiple analyzers in one document. For example, Lorem-Ipsum Dolor should be tokenized as [lorem-ipsum] [dolor] in Field1, and [lorem] [ipsum] [dolor] in Field2.
Elasticsearch
Great product, comes with a lot of features out of the box, you can get it up and running in the cloud (Azure / Amazon EC2) in no time.
Cons: personally, sometimes it’s a bit too magical :) It has nice tools for analytics, managing clusters, etc. but as a developer, I’m more interested in debugging index / queries.
Hosted elasticsearch solutions can be a bit expensive, and if you go for azure / amazon / your own server, you have to maintain it by yourself. Java updates can be very nasty sometimes :)
Apache Solr
My personal favorite. Almost the same set of features as Elasticsearch, it may be a bit more difficult to set up than ES but not that much. It has amazing dashboard, and IMO it’s not as "magical" as Elasticsearch :)
Both Elasticsearch and Apache Solr have cloud support, but they can handle millions of documents on a single server w/o any issues, as long as you feed them with lots of RAM :) Of course, everything depends on complexity of documents and search queries.
Oct 21, 2015 10:53
Hi Dejan Caric ,
I am very interested in "query the search index using Lucene.NET" in your first paragraph, can you elaborate how to do that? The way I understand it is to bypass the API & IndexingService.svc and setup a Lucene query targeting the "physical" index in data folder, is that what you are suggesting?
Thanks,
Ethan
Oct 22, 2015 23:14
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
Here is my situation, I am not allowed to use Find, but our clients asked for a lot of search related functionalities for example related news, search panels with multiple filters, sorting etc.
I tried to use Criteria Search, but it just cannot handle "complex" logic such as "A && (B || C)".
Then I tried to switch to Full-Text search, I found some post about customized lucene fields and I was really happy for about an hour. Then I found out there is no sorting anywhere in the API, which is a huge deal on the functionality. Also, apparently there is a 1000 limit on the search result, so we cannot even do a partial query here and do the rest in memory.
As a result of my research, these two option is really not good enough for the requirement. And we are concerned about the performance if we do the search without the help of DBMS or index. Any ideas on how to extend the built-in searchs or other alternative options?
I am thinking about include lucene.net and create a custom index. But I just want to hold this thought untill there is absolutely no hope doing it in EpiServer.