Thanks Erick for the useful information. Will keep the below points in mind
while designing my solution.
Thanks,
Uday
On Sat, Feb 24, 2018 at 12:47 AM, Erick Erickson
wrote:
> bq: However if i dont have majority of other column data while doing update
> operations, is it better to go with atomi
bq: However if i dont have majority of other column data while doing update
operations, is it better to go with atomic update?
I don't understand what you're asking. To use Atomic Updates, _every_
original field (i.e. any field that is _not_ the destination of a
copyField directive) must be stored
Hello Erick,
Thanks for the explanation.
However if i dont have majority of other column data while doing update
operations, is it better to go with atomic update?
And also during the update process, if there is a simultaneous search
request on the collection, will there be any lag in response?
The approximate amount of work will be very close to what it would
take Solr to just index the documents from a client. Actually it puts
a little _more_ of a load on Solr. In the case you do an Atomic
Update, Solr has to
1> fetch all the stored fields from the index
2> construct a Solr document
3>
Can you please let me know what will be the performance impact of trying to
update 120Million records in a collection containing 1 billion records.
The collection contains around 30 columns and only one column out of it is
updated as part of atomic update.
Its not a batch update, the 120 Million up
