@Erick, I kinda have to learn somehow. And I like to do performance optimizations. So learning + fun + performance .. yeah. Other projects that I want to do are harder (our email-exchange, my other threads on the list) so I have to start on something simpler.
Example: I have a project where `id` is 3 long fields which are already indexed+stored (each doc is 10 - 20 long fields (so 1/4 more data for the id?)), think event-store. The data needs to be in-memory + many queries/second + records are always increasing etc. On Sat, Apr 29, 2017 at 9:44 PM, Erick Erickson <[email protected]> wrote: > What you haven't really explained is why you care. The only hint I see > is that you don't want to store the redundant data of your composite > key as both individual fields and a concatenated <uniqueKey>. > > This feels like a whole lot of effort for no particularly good reason. > Unless you have a bazillion _very_ short docs, concatenating the parts > together in your <uniqueKey> field is unlikely to be of measurable > consequence. If you have _measurements_ showing that's not true, it's > another story. > > Assuming I'm on the right path here, I'd guess there are much more > valuable things you could spend engineering time on than the rabbit > hole of trying to work around Solr's way of dealing with <uniqueKey> > ;).. > > Best, > Erick > > On Sat, Apr 29, 2017 at 11:38 AM, Dorian Hoxha <[email protected]> > wrote: > > @Yonik Thanks, makes sense. > > > > @Walter > > > > After reading the cwiki page on update request processor looks like you > > can't modify the GET/DELETE handlers, right ? > > Because I want to NOT index/store the 'id' field, so clients/solr-cloud > > (which needs /get) continue to work normally but internally 'id' appears > > only in translog. > > And I need to do something similar for GET/DELETE. > > > > How to do that ? > > > > Regards, > > Dorian > > > > On Sat, Apr 29, 2017 at 8:04 PM, Walter Underwood <[email protected] > > > > wrote: > >> > >> If you do want a composite key in Solr, you could use an update request > >> processor script to make it out of the multiple fields. > >> > >> wunder > >> Walter Underwood > >> [email protected] > >> http://observer.wunderwood.org/ (my blog) > >> > >> > >> On Apr 29, 2017, at 11:02 AM, Yonik Seeley <[email protected]> wrote: > >> > >> On Sat, Apr 29, 2017 at 1:45 PM, Dorian Hoxha <[email protected]> > >> wrote: > >> > >> @Yonik > >> > >> Thanks makes sense. So this means that the 'id' need to be indexed(is > >> always?), (so you can get/update/delete docs not in translog), right ? > >> > >> > >> In Solr, yes. In Lucene, only if you want lookup-by-id to be fast, or > >> if you want to use updateDocument with an indexed term for overwriting > >> documents. > >> > >> -Yonik > >> > >> > >> On Sat, Apr 29, 2017 at 7:24 PM, Yonik Seeley <[email protected]> > wrote: > >> > >> > >> Solr doesn't use Lucene for RT GET, it uses it's transaction log. > >> Only when the document is not found in the transaction log will it go > >> and consult the lucene index (which can only search as of the last > >> commit). > >> > >> -Yonik > >> > >> On Sat, Apr 29, 2017 at 12:57 PM, Dorian Hoxha <[email protected]> > >> wrote: > >> > >> I know all that. My point is, lucene is NRT, while GET is RT (in both > >> ES/SOLR). How does lucene return the right document (Term Query) before > >> doing a commit on GET ? > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
