|
|
|
|
|
|
by olivierduval
1424 days ago
|
|
|
Interesting but - as usual - benchmarks are a bit twisted: Manticore knows how to optimize its products, and compare to "out of box" ElasticSeach. However, ES is a really complex stack that REQUIRES a lot of tuning to get decent performances... So I guess that a "real life" benchmark, with every product tuned by experts, would be more significant 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.