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 single machine, that is host multiple shards on a single physical machine to take advantage of the many CPU cores often available on modern hardware. Or you can host your "SolrCloud" in your own data center. Or, really, anywhere that you have one or more machines available that can talk to each other. I _really_ recommend you look at this option before pursuing your original question, it's vastly easier to let SolrCloud handle your routing, queries etc. than re-invent all that yourself. Best, Erick On Wed, Jun 3, 2015 at 11:23 AM, Ксения Баталова <batalova...@gmail.com> wrote: > 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 > 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 directing the update their all > behind the scenes for you. > > Upayavira > > On Wed, Jun 3, 2015, at 08:15 AM, Ксения Баталова wrote: >> 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*) and I want to >> update the document with id *Id1 *and I don't know where this document >> is lying. >> >> So, I have to do two select-queries to my cores to know where it is. >> >> And then generate update-query to necessary core. >> >> What am I doing wrong? >> >> I remind that I'm using SOLR 4.4.0. >> >> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> Best regards, >> Batalova Kseniya >> >> >> 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.apache.org/confluence/display/solr/Updating+Parts+of+Documents >> >> >> -- Jack Krupansky >> >> On Tue, Jun 2, 2015 at 10:15 AM, Ксения Баталова <batalova...@gmail.com> >> wrote: >> >> > 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 >> > <http://localhost:8983/solr/update> *-H >> > 'Content-type:application/json' -d ' >> > [ >> > { >> > "*id*" : "*TestDoc1*", >> > "title" : {"set":"test1"}, >> > "revision" : {"inc":3}, >> > "publisher" : {"add":"TestPublisher"} >> > }, >> > { >> > "id" : "TestDoc2", >> > "publisher" : {"add":"TestPublisher"} >> > } >> > ]' >> > >> > As well as I understand, this means that the document, for example, with id >> > *TestDoc1*, will be searched for updating *only in one core*. >> > And if there is no any document with id *TestDoc1*, the document will be >> > created. >> > Can I somehow to specify the* list of cores* for searching and then >> > updating necessary document with specific id? >> > >> > It's something like *shards *parameter in *select* query. >> > From wiki: >> > >> > #now do a distributed search across both servers with your browser or curl >> > curl ' >> > http://localhost:8983/solr/*select*?*shards*=localhost:8983/solr,localhost:7574/solr&indent=true&q=ipod+solr >> > ' >> > >> > Or is it planned in the future? >> > >> > Thanks in advance. >> > >> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ >> > >> > Best regards, >> > Batalova Kseniya >> >
