Live data from Hacker News

Xapiand: A fast, simple, modern search and storage engine

kronuz.io

1–10 of 68 posts

Re: Xapiand: A fast, simple, modern search and storage engine

#2
Still beta, last release[0] was 0.8 on 2018 November 18.

It is also not clear to me what, if anything, already integrates with this, and therefore how much code I need to write to try it out and compare against ElasticSearch.

[0] https://kronuz.io/Xapiand/news/

Re: Xapiand: A fast, simple, modern search and storage engine

#3

Still beta, last release[0] was 0.8 on 2018 November 18. It is also not clear to me what, if anything, already integrates with this, and therefore how much code I need to write to try it out and compare against ElasticSearch. [0] https://kronuz.io/Xapiand/news/

fwiw also 11 patch releases (meaning 0.8.z) since then https://github.com/Kronuz/Xapiand/releases

Re: Xapiand: A fast, simple, modern search and storage engine

#7
post #5

It's nice to see new search servers, especially low level ones. I'm going to give this a few tests.

Not sure if you know about tantivy but it's cool too: https://github.com/tantivy-search/tantivy

Also worth mentioning is Toshi: https://github.com/toshi-search/Toshi

Toshi is to ElasticSearch as Tantivy is to Lucene if that makes sense.

Obviously as they are new they are not at feature parity, but Tantivy does win at some benchmarks: https://tantivy-search.github.io/bench/

Re: Xapiand: A fast, simple, modern search and storage engine

#9
I was genuinely wondering recently why the Hackernews site search tool didn't show a very recent article with very obvious keywords, that google, for example, had in the first place in the results, when adding "Hn" to those 2 keywords in the search field. Is it a matter of the indexing, it means the article was too recent and it wasn't yet in the Algolia's(I believe) based HN's search tool memory; and in this case google copied it to memory faster; Or is this purely a matter of the Algorithms themselves? The algorithms for sure sound to be the matter, when the case is that of a search for an old article, that should be in memory already. It seems unnatural. Algolia has a free tier for open-source projects, what is very nice of them and thanks. I genuinely wonder if those algorithms are indeed so complex to justify those comparatively weaker behaviors seen at HN's internal search.

Re: Xapiand: A fast, simple, modern search and storage engine

#10

I'm interested, can anyone give a quick overview of why you'd use this over Elasticsearch?

Well for one, Java is ridiculously memory hungry. The resource costs of Elasticsearch is the #1 reason I'm not using it. I've seen a few projects which had the aim of reimplementing the Elasticsearch backend in Rust, but were incomplete. That would be my ideal solution, personally.
Post reply on HN