Re: Solr Atomic Updates by Query

Oh, I see. May be it's not such a good idea.) Thanks. _ _ Batalova Kseniya Not to my knowledge. In Solr terms this would be a _very_ heavyweight operation, potentially re-indexing millions and millions of documents. Imagine if your q were id:* for instance. Plus routing that to all shards and

Re: Solr Atomic Updates

Hope I'll succeed) Anyway, solr-user community surprised me in a good way. Thanks again. _ _ Batalova Kseniya NP. It's something of a step when moving to SolrCloud to "let go" of the details you've had to (painfully) pay attention to, but worth it. The price is, of course, learning to do thin

Re: Solr Atomic Updates by Query

Not to my knowledge. In Solr terms this would be a _very_ heavyweight operation, potentially re-indexing millions and millions of documents. Imagine if your q were id:* for instance. Plus routing that to all shards and dealing with other updates coming in would be a nightmare. Best, Erick On Thu,

Re: Solr Atomic Updates

NP. It's something of a step when moving to SolrCloud to "let go" of the details you've had to (painfully) pay attention to, but worth it. The price is, of course, learning to do things a new way ;)... Best, Erick On Thu, Jun 4, 2015 at 10:04 AM, Ксения Баталова wrote: > Erick, > > Thank you so

Re: Solr Atomic Updates by Query

Is it planned soon? Or may be not soon.. _ _ _ Batalova Kseniya There is no equivalent of, say a SQL update...where... so no, atomic updates by query... Best, Erick On Thu, Jun 4, 2015 at 2:49 AM, Ксения Баталова wrote: > Hi! > > I have one more question about atomic updates in Solr (Solr 4

Re: Solr Atomic Updates

Erick, Thank you so much. It became a bit clearer. It was decided to upgrade Solr to 5.2 and use SolrCloud in our next release. I think I'll write here about it yet :) _ _ Batalova Kseniya I have to ask then why you're not using SolrCloud with multiple shards? It seems to me that that gives

Re: Solr Atomic Updates by Query

There is no equivalent of, say a SQL update...where... so no, atomic updates by query... Best, Erick On Thu, Jun 4, 2015 at 2:49 AM, Ксения Баталова wrote: > Hi! > > I have one more question about atomic updates in Solr (Solr 4.4.0). > Is it posible to generate atomic update by query? > I mean I

Solr Atomic Updates by Query

Hi! I have one more question about atomic updates in Solr (Solr 4.4.0). Is it posible to generate atomic update by query? I mean I want to update those documents in which IDs contain some string. For example, index has: Doc1, id="123|a,b" Doc2, id="123|a,c" Doc3, id="345|a,b" Doc4, id="345|a,c,d".

Re: Solr Atomic Updates

On 6/3/2015 2:19 PM, Jack Krupansky wrote: > BTW, does anybody know how SolrCloud got that name? I mean, SolrCluster > would make a lot more sense since a cloud is typically a very large > collection of machines and more of a place than a specific configuration, > while a Solr deployment is more ty

Re: Solr Atomic Updates

BTW, does anybody know how SolrCloud got that name? I mean, SolrCluster would make a lot more sense since a cloud is typically a very large collection of machines and more of a place than a specific configuration, while a Solr deployment is more typically a more modest number of machines, a cluster

Re: Solr Atomic Updates

Basically, I think about using SolrCloud whenever you have to split your corpus into more than one core (shard in SolrCloud terms). Or when you require fault tolerance in terms of machines going up and down. Despite the name, it does _not_ require AWS or similar, and you can run "SolrCloud" on a s

Re: Solr Atomic Updates

Upayavira, I'm using stand-alone Solr instances. I've not learnt SolrCloud yet. Please, give me some advice when SolrCloud is better then stand-alone Solr instances. Or when it is worth to choose SolrCloud. _ _ _ Batalova Kseniya If you are using stand-alone Solr instances, then it is your

Re: Solr Atomic Updates

I have to ask then why you're not using SolrCloud with multiple shards? It seems to me that that gives you the indexing throughput you need (be sure to use CloudSolrServer from your client). At 300M complex documents, you pretty much certainly will need to shard anyway so in some sense you're re-in

Re: Solr Atomic Updates

Jack, Decision of using several cores was made to increase indexing and searching performance (experimentally). In my project index is about 300-500 millions documents (each document has rather difficult structure) and it may be larger. So, while indexing the documents are being added in differe

Re: Solr Atomic Updates

Explain a little about why you have separate cores, and how you decide which core a new document should reside in. Your scenario still seems a bit odd, so help us understand. -- Jack Krupansky On Wed, Jun 3, 2015 at 3:15 AM, Ксения Баталова wrote: > Hi! > > Thanks for your quick reply. > > The

Re: Solr Atomic Updates

If you are using stand-alone Solr instances, then it is your responsibility to decide which node a document resides in, and thus to which core you will send your update request. If, however, you used SolrCloud, it would handle that for you - deciding which node should contain a document, and direc

Re: Solr Atomic Updates

Hi! Thanks for your quick reply. The problem that all my index is consists of several parts (several cores) and while updating I don't know in advance in which part updated id is lying (in which core the document with specified id is lying). For example, I have two cores (*Core1 *and *Core2*) a

Re: Solr Atomic Updates

What exactly is the problem? And why do you care about cores, per se - other than to send the update to the core/collection you are trying to update? You should specify the core/collection name in the URL. You should also be using the Solr reference guide rather than the (old) wiki: https://cwiki

Solr Atomic Updates

Hi! I'm using *SOLR 4.4.0* for searching in my project. Now I am facing a problem of atomic updates in multiple cores. >From wiki: curl *http://localhost:8983/solr/update *-H 'Content-type:application/json' -d ' [ { "*id*": "*TestDoc1*", "title"

Re: Solr atomic updates question

Right. Without atomic updates, the client needs to fetch the document (or rebuild it from the system of record), apply changes, and send the entire document to Solr, including fields that haven't changed. With atomic updates, the client sends a list of changes to Solr and the server handles the

Re: Solr atomic updates question

I see what you mean now. Thanks for the example. It makes things very clear. I have been thinking about the explanation in the original response more. According to that, both regular update with entire doc and atomic update involves a delete by id followed by a add. But both the Solr reference

Re: Solr atomic updates question

Take a look at this update XML: 05991 Steve McKay Walla Walla Python Let's say employeeId is the key. If there's a fourth field, salary, on the existing doc, should it be deleted or retained? With this update it will obviously be deleted: 05991 Steve McKay

Re: Solr atomic updates question

Thanks for that under-the-cover explanation. I am not sure what you mean by "mix atomic updates with regular field values". Can you give an example? Thanks. Bill On Tue, Jul 8, 2014 at 6:56 PM, Steve McKay wrote: > Atomic updates fetch the doc with RealTimeGet, apply the updates to the > fe

Re: Solr atomic updates question

Atomic updates fetch the doc with RealTimeGet, apply the updates to the fetched doc, then reindex. Whether you use atomic updates or send the entire doc to Solr, it has to deleteById then add. The perf difference between the atomic updates and "normal" updates is likely minimal. Atomic updates

Solr atomic updates question

Solr atomic update allows for changing only one or more fields of a document without having to re-index the entire document. But what about the case where I am sending in the entire document? In that case the whole document will be re-indexed anyway, right? So I assume that there will be no savi

Re: solr atomic updates stored="true", and copyField limitation

On 9/19/2013 6:47 AM, Tanguy Moal wrote: > Quoting http://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations : >> all fields in your SchemaXml must be configured as stored="true" except for >> fields which are destinations -- which must be configured as >> stored="false" For fields cre

solr atomic updates stored="true", and copyField limitation

Hello, I'm using solr 4.4. I have a solr core with a schema defining a bunch of different fields, and among them, a date field: - date: indexed and stored // the date used at search time In practice it's a TrieDateField but I think that's not relevant for the concern. It also has a multi