On 11/27/2017 2:58 AM, Leo Prince wrote:
> Actually I have two major cores. One I have primary document store as MySQL
> and I can populate and re-index data from MySQL. However the other core
> with 40mil, is keeping as primary store (with stored=true), I get the fact
> that it's not a good practi
Leo
Your low priority data could be accumulated in a Couchbase DB or just in JSONL.
Then it would be easy to re-index.
Cheers -- Rick
--
Sorry for being brief. Alternate email is rickleir at yahoo dot com
Hi Daniel,
Thanks for the help.
Actually I have two major cores. One I have primary document store as MySQL
and I can populate and re-index data from MySQL. However the other core
with 40mil, is keeping as primary store (with stored=true), I get the fact
that it's not a good practice, however due
Leo, the general rule of thumb here is that the Solr index should *not* be
your main document store. It is the index to your document store, but if
it needs to be re-indexed, you should use your document store as the place
to index from.
Your index will not have the full source data (unless ALL y
Hi Shawn,
Thanks for the help.
I hate to burst your bubble here ... but 4 million docs is pretty small for
> a Solr index. I have one index that's a hundred times larger, and there
> are people with *billions* of documents in SolrCloud.
>
Sorry I missed a "0" there. It's actually 40 Millions, s
On 11/23/2017 11:31 PM, Leo Prince wrote:
We were using bit older version Solr 4.10.2 and upgrading to Solr7.
We have like 4mil records in one of the core which is of course pretty
huge, hence re-sourcing the index is nearly impossible and re-querying from
source Solr to Solr7 is also going to b
Hi,
We were using bit older version Solr 4.10.2 and upgrading to Solr7.
We have like 4mil records in one of the core which is of course pretty
huge, hence re-sourcing the index is nearly impossible and re-querying from
source Solr to Solr7 is also going to be an exhausting effort.
Hence, I tried
