Manticore Search: Elasticsearch Alternative(github.com) |
Manticore Search: Elasticsearch Alternative(github.com) |
So anyone can reproduce the results or at least look carefully into them, understand the testing methodology etc.
It would be interesting to see queries benchmarked for their intended workload (logs/sorting/full-text etc).
Fastest Avg: https://db-benchmarks.com/?cache=fast_avg&engines=elasticsea...
Slowest: https://db-benchmarks.com/?cache=slowest&engines=elasticsear...
In practice, claims boil down to this query is 182x faster than that query in MySQL.
Using the same type of comparison, you can come to the conclusion that MySQL is 10x faster than MySQL because one query was constructed one way and the other another. (Applying induction, we can thus prove that MySQL is infinitely fast ;-)
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't see any architectured benchmark. Real ES use case are often based on multiple servers, specialized nodes...
So, all in all... I would be interested in more "real life" use cases before making my mine
I don't like those kind of benchmarks too: you tune your product to maximum and don't touch your competitor at all.
That's why the mentioned benchmarks imply NO TUNING or very light one like enabling mlock in Elasicsearch / enabling secondary indexes in Manticore. Otherwise it works as it's shipped. If you read the articles here https://db-benchmarks.com/posts/ you'll understand that the authors really wanted to do fair benchmarks and to use as little tuning as possible.
> ES has a proven history of horizontal scaling (throw more servers to scale). And I didn't see any architectured benchmark.
This is true. ES is better in terms of this. Manticore has replication and distribute indexes, but doesn't have automatic sharding and shards orchestration. This is a work in progress.
Elastic just gives me grief all the time, sphinx always just worked perfectly for me. Perhaps ES can do more, but I've never found sphinx lacking for the usecase I run into.
I'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.
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't think that is sustainable.
It's true that Lucene has more token filters and is perhaps more flexible. It's partly because Manticore's another focus is simplicity and ease of use, so there are: * just "charset_table=non_cjk" which is a default and should work for most languages (it already does case folding and accents folding) * on top of that you can apply one or multiple morphologies: stemmers (available for many languages via libstemmer library and some stemmers are built-in), lemmatizers (available for English, German, Ukrainian and Russian languages) * "charset_table=cjk" + "morphology=icu_chinese" to segment Chinese text * you can combine that all if you wish * built-in stopwords for most languages
and of course prefix search, infix search etc.
But what we really want is that the default settings work fine in most cases.
And row-wise storage for lowest latency when cost is not a problem.
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's time I take a serious look at Manticore.
From what I could tell clicking through its links on GitHub... it has no UI offering? It's just an API?
I guess technically that does compare 1:1 with Elasticsearch but...
ELK is what most people think of when they think of Elasticearch, right? aka... full blown stack complete with UI
This just gets the backend piece done from what I can tell. Any frontends that plug into it?
Related question though: why do so many FTS offerings in the space also try and offer column/analytics features? In my experience, I've already got a database for that, I'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.
That's why Clickhouse can be integrated with Quickwit, for example.
Manticore aims to be a good full-text search engine + can process large data volume that doesn't fit into RAM with help of the columnar storage.
Is it a replacement for elasticsearch? Maybe. Depends on your search requirements. I prefer elastic when you have power users needing to search over specific fields, and all of the syntax that it gives you. For a plain text box you want people to type terms into though manticore is much easier to configure.
Scaling is not a good as elastic currently but you don’t need it as soon due to its lower footprint.
That said I’m about to replace it with my own custom index, but that’s not because manticore is a problem. Just that I can do better for my specific use case. I’m abusing manticore in ways it’s not happy about. For other projects I’d happily use it again.
Very stable, fast, and easy to connect to mysql.
It's now handling index over 280M+ documents and has been drama-free - just works.
It's a critical feature for adoption, please include it in your roadmap :)
But I agree implementation of a proper auth should be prioritized. I'll discuss it with the team.
I just couldn't tweak ranking with BucketSort to get a desired relevancy. And memory usage was extremely high.
I didn't bother testing Manticore since there was no good open source client for C#, but seeing they released an official client I might test it to see how it compares to Solr.
If anyone were to search for how to index a webpage with it, they'd get frustrated pretty quickly. I started a new version of Grub to address this, but I've found my motivation for working on it lacking: https://github.com/kordless/grub-2.0
A friend and I assembled a module for that repo called Aperture, which implements a scalable screenshot crawler that sends document into Solr. If anyone is interested, hit me up and I'll provide some instructions for using it!
Comparing Elasticsearch / Manticore with MySQL may be not the fairest thing since they are too different, but comparing them one with another and using not only full-text queries seems fine to me.
But for the public data case, you probably still need to worry about DoS or data corruption.
In the logs case, a malicious actor can probably control at least part of the logs, so if a bug leads to arbitrary code execution, a bad actor could possibly get all kinds of valuable data.
Also, just to be clear, the language doesn't necessarily mean there are significant security bugs. A well written c++ app is probably better than a poorly written java app. It's just harder to avoid memory bugs in c++ than java.