Solr 8.6.1 • Hacker News Board

Re: Solr 8.6.1

#21

Post by sheeshkebab » Sun, Aug 16, 2020, 9:19 PM UTC

csunbird wrote: post #14

hermanradtke wrote: post #12

Earlier quoted context omitted.

And the need for ZooKeeper with SolrCloud. We had to have at least one person working full time to keep a decent sized cluster working correctly.

This mirrors my experience. The Solr Cluster that we have in production requires full time attention of our infrastructure team.

Never bothered with solr cloud and our simple replicated cluster that pretty much auto scales from 3 nodes to 100+ across multiple regions takes maybe a few hours of maintenance every few months, and no one dedicated to baby sit it...

In summary, avoid SolrCloud like plague.

Re: Solr 8.6.1

#22

Post by scaryclam » Sun, Aug 16, 2020, 9:27 PM UTC

gengstrand wrote: post #10

I remember load testing both ES and Solr about 3 years ago. What was tested was the indexing of randomly generated 500 word documents and keyword based search. When it came to indexing, Solr was faster but ES had better throughput. When it came to querying, Solr was the clear winner. https://glennengstrand.info/software/performance/elasticsear...

I tend towards the rule of thumb that if you want search, Solr is what you use, if you want logging, ElasticSearch is the way to go.

Re: Solr 8.6.1

#23

Post by tekkk » Mon, Aug 17, 2020, 3:00 PM UTC

lukevp wrote: post #20

tekkk wrote: post #11

Solr is one of those technologies which works but isn't really glorious to use and is bit stuffy with its XML configurations and Java interfaces. It's a bit of shame, because search engines are so popular nowadays and everybody seems to be fixated on using ElasticSearch. Which from what I've read and heard is resource-hungry and not really cut for simple text-search. Maybe someday somebody will create a new search en…

Search really has 3 main levels. 1. Core ranked inverted index data store (Lucene) 2. API layer on top of Lucene with easier query, index, data importing, sharding, etc. (Solr/Elastic Search) 3. Fully hosted API / UI for easier GUI for developers and search relevance engineers (Algolia, Lucidworks Fusion). The new hotness in search is currently Rust-based tooling. Rust is a great application for search as it's very p…

Cool, very interesting! Thanks for the summary, I had/have a project that currently uses Solr for quick text search yet the integration has not been totally painless. Also it's kind of ridiculous how much RAM even the tiniest instance uses.

I myself picked up Solr (instead of ES) as it was recommended as better bet for my use case but I did not research in full what others options there were.

Rust seems like a smart choice like it probably is for this type of very fast processing. I guess this is yet another reason to learn it.

Re: Solr 8.6.1

#24

Post by gifflar » Wed, Aug 19, 2020, 7:36 PM UTC

tekkk wrote: post #23

lukevp wrote: post #20

Earlier quoted context omitted.

Search really has 3 main levels. 1. Core ranked inverted index data store (Lucene) 2. API layer on top of Lucene with easier query, index, data importing, sharding, etc. (Solr/Elastic Search) 3. Fully hosted API / UI for easier GUI for developers and search relevance engineers (Algolia, Lucidworks Fusion). The new hotness in search is currently Rust-based tooling. Rust is a great application for search as it's very p…

Cool, very interesting! Thanks for the summary, I had/have a project that currently uses Solr for quick text search yet the integration has not been totally painless. Also it's kind of ridiculous how much RAM even the tiniest instance uses. I myself picked up Solr (instead of ES) as it was recommended as better bet for my use case but I did not research in full what others options there were. Rust seems like a smart…

I also found a nice overview in the MeiliSearch documentation [1]. Maybe, you find it interesting.

[1] https://docs.meilisearch.com/resources/comparison_to_alterna...