We are continuously working on improving our product Feedback by Hexmos day by day for the upcoming release.
New features and pages are coming up, the UI is changing, bugs are being noticed and fixed, and many changes are happening in the product. As the product grows, we realize we need to improve the navigation across the product.
We already have a sidebar and a client-side search package cmdk to navigate to different screens, but difficulties arise when we want to search for different user profiles, teams, team performance, etc., which forces us to integrate a better third party search engine for Feedback.
Another reason for a dedicated search engine is that we have other products in the chain such as FeedZap, which requires a complex text search operations in future.
Considering this, we are planning to put effort into implementing a dedicated, powerful search engine that adapts to our use cases and resource availability.
There are a lot of search engines available, including open-source search engines, serverless, server-based, etc.
Before diving in to figure out the right one, it's always better to do an analysis of your requirements and infrastructure, including present and future needs.
For some products, searchable data are minimal but require a decent search feature with minimal operation, yet can't afford a dedicated server.
For other products, the dataset is larger, requires additional complex search operations and have enough resources to load a dedicated search engine.
Based on this, I reviewed a few popular search engines.
If you are using PostgreSQL and don't want to maintain any other index-based database, then PostgreSQL Full-Text Search (PSFTS) is a good option. However, it is not recommended for large use cases where you deal with millions of transactions and extensive data management.
Bleve is another option to consider if your project is within the Go ecosystem. It is recommended if you can't rely on powerful server-based search engine services. Here is the benchmark report on Bleve.
Tantivy is written in Rust and is particularly useful for Rust-based projects. It has received numerous positive feedbacks and is a good option to consider.
If you own a server or cloud instance and require a powerful, scalable search engine with full control, then a server-based option is the way to go.
Our considerations and requirements led us to choose a server-based search engine. We have enough resources to host it, and it is better than serverless options for
After extensive filtering, we narrowed it down to four options in this category such as:
Here is a comparison between them:
Criteria | meiliSearch | Typesense | Pisa Search | Manticore |
---|---|---|---|---|
Search-as-you-type | yes | yes | No | No |
facet search | yes | yes | No | No |
multiple schema/product support | yes | yes | - | yes |
RAM usage | for 224 MB disk:~305 MB RAM prmary index location is disk | primary index location is RAM, for 100MB disk requires 300MB RAM | - | - |
CPU Usage | for 12 core machine it uses maximum 6 core github issues related to high cpu usage | for 4vCPU handle 104 concurrent search/seconds | - | - |
typo, synonyms handling | yes | yes | - | - |
We filtered out PISA Search and Manticore because neither of them offers search-as-you-type and facet search features, which are required for our application.
Continue reading the full article here: https://journal.hexmos.com/we-chose-meilisearch-over-10-other-search-engines-despite-a-major-drawback/
The above is the detailed content of We Chose Meilisearch Over Other Search Engines Despite a Major Drawback. For more information, please follow other related articles on the PHP Chinese website!