f-the-box.
>
>
>
> -
> Thanks
> -K'Rider
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544p4003623.html
> Sent from the Solr - User mailing list arch
One other thing i forgot to mention is - multicore setup we have requires us
to be able to add cores dynamically and i am not sure if thats supported by
http solr out-of-the-box.
-
Thanks
-K'Rider
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Index-Concurren
27;Rider
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544p4003622.html
Sent from the Solr - User mailing list archive at Nabble.com.
gt; I am assuming this depends on the size of the doc and type of
>> analyzer/tokenizer/filters being used. Correct?
>> Can you please share (or point me to documentation) on how to get this
>> speed
>> for 1 mil docs.
>> >> - one million is a fairly small amount, in average it shou
lters being used. Correct?
> Can you please share (or point me to documentation) on how to get this
> speed
> for 1 mil docs.
> >> - one million is a fairly small amount, in average it should be indexed
> >> in few mins. I doubt that you really need to distribu
y need to distribute indexing
Thanks
-K
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544p4002776.html
Sent from the Solr - User mailing list archive at Nabble.com.
better
> alternatives to speed up indexing time?
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544.html
> Sent from the Solr - User ma
indexing time?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 5/10/07, joestelmach <[EMAIL PROTECTED]> wrote:
> Yes, coordination between the main index searcher, the index writer,
> and the index reader needed to delete other documents.
Can you point me to any documentation/code that describes this
implementation?
Look at SolrCore.getSearcher() and D
threads will serve to cover the latency and keep Solr busy.
I agree with your thinking here. My requirement for a large number of
threads is somewhat of an artifact of my current system design. I'm trying
not to serialize the system's processing at the point of indexing.
--
View
TED]>
To: solr-user@lucene.apache.org
Sent: Wednesday, May 9, 2007 6:32:33 PM
Subject: Re: Index Concurrency
On 5/9/07, joestelmach <[EMAIL PROTECTED]> wrote:
> My first intuition is to give each user their own index. My thinking here is
> that querying would be faster (since each use
On 5/9/07, joestelmach <[EMAIL PROTECTED]> wrote:
Does solr provide any additional concurrency control over what Lucene
provides?
Yes, coordination between the main index searcher, the index writer,
and the index reader needed to delete other documents.
In my simple testing of indexing 2,000
sequentially yields no problems at all. Actually, I'm
able churn through over 100,000 messages when no threads are involved. Am I
missing some concurrency settings?
Thanks,
Joe
--
View this message in context:
http://www.nabble.com/Index-Concurrency-tf3718634.html#a10406382
Sent from t
On 5/9/07, joestelmach <[EMAIL PROTECTED]> wrote:
My first intuition is to give each user their own index. My thinking here is
that querying would be faster (since each user's index would be much smaller
than one big index,) and, more importantly, that I would dodge any
concurrency issues stemmin
e greatly appreciated.
Thanks,
Joe
--
View this message in context:
http://www.nabble.com/Index-Concurrency-tf3718634.html#a10403918
Sent from the Solr - User mailing list archive at Nabble.com.
15 matches
Mail list logo
