Manticore Search: Elasticsearch Alternative

Whenever I see quotes like “182x faster than MySQL! 29x faster than Elasticsearch!” as the intro to a project, I’m immediately sceptical of the quality of the entire project.

Interesting but - as usual - benchmarks are a bit twisted: Manticore knows how to optimize its products, and compare to &quot;out of box&quot; ElasticSeach. However, ES is a really complex stack that REQUIRES a lot of tuning to get decent performances... So I guess that a &quot;real life&quot; benchmark, with every product tuned by experts, would be more significant<p>Manticore is full C++ so it surely is better than a full stack java ES for memory (and maybe performance) on single server... but ES has a proven history of horizontal scaling (throw more servers to scale). And I didn&#x27;t see any architectured benchmark. Real ES use case are often based on multiple servers, specialized nodes...<p>So, all in all... I would be interested in more &quot;real life&quot; use cases before making my mine

As a former Sphinx user: awesome, looking forward to trying this out.<p>Elastic just gives me grief all the time, sphinx always just worked perfectly for me. Perhaps ES can do more, but I&#x27;ve never found sphinx lacking for the usecase I run into.<p>I&#x27;m seeing a lot push abck about the simplistic benchmarks, and sure, they are super meaningful perhaps. But they do give you a good idea of where the strengths of this might be. Benchmarks are pretty meaningless anyway imo.<p>Also, I am just very happy to see there is ANY alternative engine to Lucene. A bit of competing ideas is very healthy for the ecosystem. Lucene has been pretty much the only solution for years and I don&#x27;t think that is sustainable.

I have worked for many years with Elasticsearch at scale, good thing I am not working with it anymore. The main issue with Elasticsearch was to upgrade versions and maintain the cluster. The cluster is a live creature that can get mad at your data and start hogging the CPU at any time, not to mention GC stops. We used some geo operations on Elasticsearch and from a minor version to another they broke it. What a hell on earth, I hope OPs alternative will bring some relief for those in pain or avoid the pain for those that will eventually need a FTS engine.

It&#x27;s worth noting that Manticore search isn&#x27;t a new development: it&#x27;s a fork Sphinx, a pretty popular search engine in 2010s written by Andrei Aksenov in C++. It got superceded by ElasticSearch because the original engine never fully emraced multicore processing and working as a cluster, but I personally used Sphinx and it was very simple and very robust, a stark contrast to Elasticsearch, especially for tasks where you do need to ingest a lot of data like log collection.

Far more important to me than the speed of the searches is the quality of them. Are there any benchmarks that attempt to test this? I&#x27;m not even sure how to determine what the criteria would be, but there must be a few well-definable domains that could be used.

Seems like it is focused so much on how fast it responds to queries that it forgot that it is extremely important on how good it&#x27;s responses are. Lucene&#x27;s main benefit is the huge library of token filters to improve the understanding of the text in index. Manticore only has an ability to plug your own single filter in. And while that doesn&#x27;t make it any less possible to make search results good, it&#x27;s definitely a lot harder to do. Producing good results is the main goal of search, speed is only necessary for it to not be too slow. A well working search will offset any extra infrastructure that it might need to run fast.

Here is a blog post about it <a href="https:&#x2F;&#x2F;manticoresearch.com&#x2F;blog&#x2F;manticore-alternative-to-elasticsearch&#x2F;" rel="nofollow">https:&#x2F;&#x2F;manticoresearch.com&#x2F;blog&#x2F;manticore-alternative-to-el...</a>

From benchmarks it seems that columnar storage shines when there isn&#x27;t enough RAM avaliable. Lower cost full text search seems quite good value proposition.<p>And row-wise storage for lowest latency when cost is not a problem.<p>Also, I took a quick look at ranking. With things like BM25 and geo-spatial search it seems to be flexible and feature rich enough. I think it&#x27;s time I take a serious look at Manticore.

If you already use Postgres consider PH full text search first.

Are there any comparisons on how quickly this indexes documents compared to elasticsearch or lucene? I work with some static snapshots and we kind of need those to have a short lead time which is indexing them.

I would totally use this for really small hobbyist level stuff if it had something that &quot;plugged&quot; right into it as &quot;pretty&quot; and &quot;feature full&quot; and &quot;easy to use&quot; as Kibana.<p>From what I could tell clicking through its links on GitHub... it has no UI offering? It&#x27;s just an API?<p>I guess technically that <i>does</i> compare 1:1 with Elasticsearch but...<p>ELK is what most people think of when they think of Elasticearch, right? aka... full blown stack complete with UI<p>This just gets the backend piece done from what I can tell. Any frontends that plug into it?

Looks promising, keen to try it out.<p>Related question though: why do so many FTS offerings in the space also try and offer column&#x2F;analytics features? In my experience, I&#x27;ve already got a database for that, I&#x27;d really just love to see a FTS engine that _just_ searches text and filters responses, as fast and accurately as possible. Leave the analytics to my column database, just search the text as fast as possible.

Has anyone used it in production? Any informed opinions?

They released an official C# client few weeks ago. Nice.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;manticoresoftware&#x2F;manticoresearch-net" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;manticoresoftware&#x2F;manticoresearch-net</a>

Also, Sonic: <a href="https:&#x2F;&#x2F;github.com&#x2F;valeriansaliou&#x2F;sonic" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;valeriansaliou&#x2F;sonic</a> (written in Rust)

Speed is important, but so is quality of results, especially when it comes to search. You can make something search blazingly fast, if it doesn&#x27;t need to be accurate.

I was falling in love... Until I discovered authentication is not yet supported!!<p>It&#x27;s a critical feature for adoption, please include it in your roadmap :)

I’ve been very happy with MeiliSearch. It powers internal search services for customer support at my ecom site.

Sweet. Glad it&#x27;s not running on the JVM (Looking at you ELK.).