elasticsearch

How is Elasticsearch "closed source"? The code is literally right here: https://github.com/elastic/elasticsearch

(disclaimer: I'm one of the cofounder of Quickwit.io, we are doing log search) (edited to add vector search category and add manticore) When looking at OSS search projects, it's nice to have a rough ideas of the different use cases, here is the list I have in mind: - user facing search (think algolia): elasticsearch[1]/opensearch[2], meilisearch[3], typesense[4] - enterprise search: elasticsearch/opensearch - log search: elasticsearch/opensearch, loki[5], quickwit[6], zincsearch[7] - vector search: Milvus[8], Qdrant[9], Vald[10] Weaviate[11] Vespa.ai[12] is great but I don't really know in which category to put them, user facing and enterprise search seems to work well with them. It's interesting to note that Elasticsearch and Opensearch are general purpose search engine, Solr as well. They are all powered by Lucene, the popular and per

The opensearch project was released a while ago as opendistro and was just renamed to opensearch a year ago [1]. As for features, it depends what you're doing, but ES upgraded to Lucene 9 6 months ago [2], and they've had document level alerting for at least two years. [1] https://opensearch.org/blog/technical-posts/2021/07/how-to-u... [2] https://github.com/elastic/elasticsearch/issues/74057

I hate the fact that OpenSearch divide in a bipartite the human resources allocated at improving elasticsearch, which is a tragedy. The hypocrisy is strong at amazon, they have allocated a lot of engineers on OpenSearch and yet their number of contributions pre-fork drama was much much lower (although they were still an important contributor though). But once the management has control and developers can have their own NIH dopamine release, humans are eager to work.. For this human resources reasons, I hope the OpenSearch distraction dies in darkness. However, beside my utilitaristic goals, I am also one of the only person caring about the technology. And it happens that the technology is generally not found in ElasticSearch but in the much more salient project: Lucene, which it uses. However, despite its big humans resources, ElasticSear

Disclosure: I work for AWS. There were contributions sent upstream for Elasticsearch bugfixes and enhancements. Some of those PRs are still open, for example [1]. A sampling of additional PRs can be found in this blog post [2]. Further contributions upstream to Apache Lucene have been growing over the years. The new Approximate Nearest Neighbor support in Elasticsearch 8.0 comes from work that was sponsored by Amazon in upstream Apache Lucene [3]. [1] https://github.com/elastic/elasticsearch/pull/64513 [2] https://aws.amazon.com/blogs/opensource/stepping-up-for-a-tr... [3] https://issues.apache.org/jira/browse/LUCENE-9004

Can see the number of commits drastically drop off where OpenSearch forked Elasticsearch: https://github.com/elastic/elasticsearch/graphs/contributors https://github.com/opensearch-project/OpenSearch/graphs/cont... Over an order of magnitude more development on Elasticsearch than OpenSearch since that fork

Awesome. I've tried MeiliSearch and it is very easy to set up and use. It works very well for less than a million of data. The only let down for me is their very slow indexing speed when it comes to millions to tens of millions of data (personal experience, also experienced by other users in their public slack workspace). Other competitors / alternatives: - https://github.com/typesense/typesense - https://github.com/quickwit-oss/quickwit - https://github.com/elastic/elasticsearch - https://github.com/valeriansaliou/sonic A decent feature-by-feature comparison: - https://typesense.org/typesense-vs-algolia-vs-elasticsearch-... If you guys know other open-source competitors / alternatives, I'd love to check those out!

This brings back memories. I once failed an interview because an interviewer asked me how a certain API could be implemented and I suggested that you could send a body with a GET request. My thinking at the time was that, even though unusual, Elasticsearch does this (2016: https://github.com/elastic/elasticsearch/issues/16024#issuec...) and it might be easier to cache than POST but I could tell that the interviewer wasn't happy with my reponse. Glad that a QUERY method will be provided instead, and I learnt my lesson about giving against-the-grain responses to interviewers.