3 ms·

Weirdly I still find Solr easier to use then ES. Solrs's bulk import has csv support out of the box instead of converting it to json first and increasing its si

Weirdly I still find Solr easier to use then ES. Solrs's bulk import has csv support out of the box instead of converting it to json first and increasing its size and payload a lot. The query DSL is way easier and better documented I find. And it tends not to break all the time between releases. I moved a couple of times from Solr to Es and back again. SOLR comes with a tiny admin that you can just use OOB and use to fire your queries against instead of choosing another frontend, configuring and setting that up etc. I find solr's experience way easier and lower ceremony after all.

sheeshkebab 6y ago
It’s also amazing how versatile solr is - I’ve used as both an embedded search lib in an tool as well as a multi region distributed replicated cluster in large scale prod environments, all from pretty much the same distribution.
- leetrout 6y ago
  Could you speak more about using solr as a primary DB? Or did I misunderstand how you were using it?
  - joking 6y ago
    you can, but almost nobody will recommend to use it, neither will do with elasticsearch. In most cases it works, but it has priorized speed over resilience, so it's better to have a source from where you can rebuild the index.
    - cmckn 6y ago
      > it's better to have a source from where you can rebuild the index. Having worked for several years at a company selling search, I can't emphasize this enough. Rebuilding indices should always be straightforward, and your data should be very accessible in some other (preliminary) form. We ran into so many issues, and had so many panics, because the index had become the only place some things existed. It's also way easier to tweak (read: optimize) your schema over time when you're in the habit of rebuilding the index.
    - eivarv 6y ago
      Another "but" here is what [0] may happen if you're storing personal data in big indexes... TLDR; In some cases, what data you actually have (as in "on disk") becomes complicated. For instance, in some cases, once a segment reaches max size (5GB by default) it will only be eligible for merging when it accumulates 50% deletions. This means you might not be able to guarantee deletion of data within 30 days (in accordance with the GDPR). [0]: https://www.eivindarvesen.com/blog/2018/09/23/lucene-indexes-and-gdpr https://www.eivindarvesen.com/blog/2018/09/23/lucene-indexes...

sheeshkebab 6y ago

It’s also amazing how versatile solr is - I’ve used as both an embedded search lib in an tool as well as a multi region distributed replicated cluster in large scale prod environments, all from pretty much the same distribution.

leetrout 6y ago
Could you speak more about using solr as a primary DB? Or did I misunderstand how you were using it?
- joking 6y ago
  you can, but almost nobody will recommend to use it, neither will do with elasticsearch. In most cases it works, but it has priorized speed over resilience, so it's better to have a source from where you can rebuild the index.
  - cmckn 6y ago
    > it's better to have a source from where you can rebuild the index. Having worked for several years at a company selling search, I can't emphasize this enough. Rebuilding indices should always be straightforward, and your data should be very accessible in some other (preliminary) form. We ran into so many issues, and had so many panics, because the index had become the only place some things existed. It's also way easier to tweak (read: optimize) your schema over time when you're in the habit of rebuilding the index.
  - eivarv 6y ago
    Another "but" here is what [0] may happen if you're storing personal data in big indexes... TLDR; In some cases, what data you actually have (as in "on disk") becomes complicated. For instance, in some cases, once a segment reaches max size (5GB by default) it will only be eligible for merging when it accumulates 50% deletions. This means you might not be able to guarantee deletion of data within 30 days (in accordance with the GDPR). [0]: https://www.eivindarvesen.com/blog/2018/09/23/lucene-indexes-and-gdpr https://www.eivindarvesen.com/blog/2018/09/23/lucene-indexes...