Some findings on Docs/Site Search functionality #3985
Description
Site Search Functionality
Some ways to implement search :
- Via a server-side search engine such as Elasticsearch or Solr.
- Commercial search services such as Algolia.
- Application platforms and database services with add-on search functionality, such as Firebase and Cloudant.
- Client-side JavaScript search libraries such as Elasticlunr.
- Google Custom Search Engine.
Things to consider for the Search Function:
- How often is the data updated? If updates are continual and search results absolutely must be kept up to date, we’ll probably need to use a server-side option.
- Do we need to search content, data, metadata — or all three? Search engines can index content and metadata from binary files such as PDF and Word documents, or access data and content from databases, or extract metadata such as EXIF from images. JavaScript search libraries need JSON.
- How much data do we need to search? If you can cache all of your data locally on the client (say less than 20MB) you could consider client-side search.
Search Engines as a Service
Pros:
- It’s not simple to set up and maintain a large-scale search service able to withstand high concurrent demand and traffic spikes, along with complex data sets and a high volume of updates.
- DIY alternatives can incur greater infrastructure and human resource costs.
- A managed service can be simpler and more reliable to scale.
- Outsourcing search can simplify the management of setup, maintenance and updates — and reduce startup time.
- In most cases, the performance of managed services should be at least as good as a DIY equivalent.
- Managed services are potentially more reliable than self-hosted alternatives and should be able to guarantee minimum service levels.
- It may be possible to include search relatively cheaply within existing cloud contracts.
Cons:
- Potentially more expensive than DIY search engine options.
- Every search query requires a request to the server, which can incur significant data cost and battery usage on mobile clients.
DIY Search Engine
ElasticSearch
Pros:
- Potentially relatively cheap and straightforward to set up and run if you already have a server team (or at least a dedicated system administrator).
- Queries are extremely fast, and updates can be searchable with very low latency.
Cons:
- https://www.quora.com/Why-shouldnt-I-use-ElasticSearch-as-my-primary-datastore
- Setup, maintenance and update cost. Large-scale, high volume installations can be complex!
- Initial and ongoing infrastructure cost.
- Every search query requires a request to the server, which can incur significant data cost and battery usage on mobile clients.
Client-Side Search
Pros:
- Relatively simple to set up and maintain.
- No search engine, database or third party search service required.
- Search is done on the client, so queries do not require a server round trip, so reduce server load and use less radio on mobile devices.
- Client-side search is resilient to connectivity vagaries.
- Client-side search can be extremely fast for smaller data sets.
- Potentially useful for content that isn’t frequently updated, or where updates (though important) are not time critical. For example, an e-commerce site could use client-side search to enable offline access to store locations.
Cons:
- Only viable for a limited amount of data — though this could be up to tens of thousands of documents, potentially more, as long as the data is relatively static and doesn’t change frequently.
- Not viable for data involving multiple pages
- Do we need offline search, if not , client side may not be needed