All Atomic Updates do is 1> read all the stored fields from the record being updated 2> overlay your updates 3> re-index the document.
At <3> it’s exactly as though you sent the entire document again, so your observation that the whole document is re-indexed is accurate. If the fields you want to update are single-valued, docValues=true numeric fields you can update those without the whole doc being re-indexed. But if you need to search on those fields it’ll probably be unacceptably slow. However, if you _do_ need to search, sometimes you can get creative with function queries. OK, this last is opaque but say you have a “quantity” field and only want to find docs that have quantity > 0. You can add a function query to your query (either q or fq) that returns the value of that field, which means the score is 0 for docs where quantity==0 and the doc drops out of the result set. It’s not clear whether you search the text field, but if not you can store it somewhere else and only fetch it as needed. Best, Erick > On Jun 15, 2020, at 7:55 AM, david.dav...@correo.aeat.es wrote: > > Hi, > > I have a question related with atomic update in Solr. > > In our collection, documents have a lot of fields, most of them small. > However, there is one of them that includes the text of the document. > Sometimes, not many fortunatelly, this text is very long, more than 3 or 4 > MB of plain text. We use different analyzers such as synonyms, etc. and > this causes that index time in that documents is long, about 15 seconds. > > Sometimes, we should update some small fields, and it is a big problem for > us because of the time that it consumes. We have been testing with atomic > update, but time is exactly the same than sending the document again. We > expected that with atomic update only the updated fields were indexed and > time would reduce. But it seems that internally Solr gets the whole > document and reindex all the fields. > > Does it works in that way? Am I worng, any advice? > > We have tested with Solr 7.4 and Solr 4.10 > > Thanks, > > David
