Well, "it depends". The Atomic update has to first go out to disk and decompress the original stored fields in 16K blocks, then overlay the atomic update on the uncompressed doc, then re-index the doc. 40K times in your example.
So yes, the stream going to Solr will be smaller if you do atomic updates, but the processing on Solr will be heavier. Plus, if you're not storing all the fields anyway, storing them just for atomic up dates adds some load to the system as the index on disk is bigger so merges take more I/O and the like. However, you state that "the process of obtaining all relevant information for each object from the database is one of relatively high cost." so likely the extra work on Solr's part is worth it to you. Best, Erick On Fri, Feb 17, 2017 at 2:36 AM, Bram Van Dam <bram.van...@intix.eu> wrote: >> I am aware of the requirements to use atomic updates, but as I understood, >> those would not have a big impact on performance and only a slight increase >> in index size? > > AFAIK there won't be a difference in index size between atomic updates > and full updates, as the end result is the same. > > But you will probably see a performance increase because you'll only > have to send 40000 boolean flags instead of 40000 full documents. > > Using atomic updates sounds like a good idea to me. > > - Bram >
