[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800518#action_12800518
]
Robert Muir commented on SOLR-1677:
---
bq. The implication i got from Robert was that there
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800514#action_12800514
]
Hoss Man commented on SOLR-1677:
{quote}
Yes. The whole point is to avoid Analyzer mismatche
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800484#action_12800484
]
Marvin Humphrey commented on SOLR-1677:
---
> I'd still like to clarify this whole issue
My definition of right is simple and modularized with minimal conceptual
upheaval.
As such, simply giving SOLR a good shard manager that broadcasts queries
without respect to content is a preferable solution than something very
fancy.
On Thu, Jan 14, 2010 at 4:31 PM, Lance Norskog wrote:
> Logi
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800471#action_12800471
]
Hoss Man commented on SOLR-1677:
bq. And I also can't see anyone really spending time to agg
Yonik spake-
I'm actually starting to lean toward "slice" instead of "logical shard".
In the future we'll want to enable overlapping shards I think (due to
an Amazon Dynamo type of replication, or due to merging shards, etc),v
and a separate word for a logical slice of the index seems
Shard has the interesting additional implication that it is part of a
composite index made up of many sub-indexes.
A lucene index could be a complete index or a shard. I would presume the
same of what might be called a core.
On Thu, Jan 14, 2010 at 3:21 PM, Jason Rutherglen <
jason.rutherg...@gm
Uri,
> "core" to represent a single index and "shard" to be
> represented by a single core
Can you elaborate on what you mean, isn't a core a single index
too? It seems like shard was used to represent a remote index
(perhaps?). Though here I'd prefer "remote core", because to the
uninitiated Sol
Although Jason has some valid points here, I'm with Yonik here. I do
believe that we've gotten used to the terms "core" to represent a single
index and "shard" to be represented by a single core. A "node" seems to
indicate a machine or a JVM. Changing any of these (informal perhaps)
definitions
> But I've kind of gotten used to thinking of shards as the
> actual physical queryable things...
I think a mistake was made referring to Solr cores as shards.
It's the same thing with 2 different names. Slices adds yet
another name which seems to imply the same thing yet again. I'd
rather see dis
I have found that users of the system like to use index as the composite of
all nodes/shards/slices that is searched in response to a query. It is the
ultimate logical entity. Really, this is the same abstraction that users
of Lucene have. They really don't want to care that a Lucene index is m
I saw some previous threads related to this subject, but on a slightly
different use case, so staring a new thread...
For reference, a related thread topic can be found here:
http://www.lucidimagination.com/search/document/2025d6670004838b/date_faceting_and_double_counting#2025d6670004838b
On Thu, Jan 14, 2010 at 1:38 PM, Yonik Seeley
wrote:
> On Thu, Jan 14, 2010 at 12:46 PM, Yonik Seeley
> wrote:
>> I'm actually starting to lean toward "slice" instead of "logical shard".
Alternate terminology could be "index" for the actual physical lucene
lindex (and also enough of the URL that
On Thu, Jan 14, 2010 at 1:58 PM, Chris Hostetter
wrote:
> : parameter we use for this. Suggestions? logicalshards=shard1,shard2?
> : lshards=shard1,shard2? slice=shard1,shard2? It doesn't seem like it
> : would be easy to reuse the "shards" parameter for this since it refers
> : to physical sha
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800318#action_12800318
]
Mark Miller commented on SOLR-1722:
---
I'll have to check it out a little more - Noble switc
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800311#action_12800311
]
Yonik Seeley commented on SOLR-1722:
I never really looked at the previous implementatio
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1722:
--
Attachment: SOLR-1722.patch
Quick patch whipped off to show the idea.
> Allowing changing the "special"
Allowing changing the "special" default core name, and as a default default
core name, switch to using collection1 rather than DEFAULT_CORE
---
: parameter we use for this. Suggestions? logicalshards=shard1,shard2?
: lshards=shard1,shard2? slice=shard1,shard2? It doesn't seem like it
: would be easy to reuse the "shards" parameter for this since it refers
: to physical shard addresses.
I haven't been following the SolrCloud stuff much
Chris Hostetter wrote:
> : The current way of allowing the omission of a core name in the URL is
> : to name the core DEFAULT_CORE.
> ...
> : 1) allow an optional flag in solr.xml to mark that any core is also
> : the default core
> : 2) rename DEFAULT_CORE to something nicer like "collection
: The current way of allowing the omission of a core name in the URL is
: to name the core DEFAULT_CORE.
...
: 1) allow an optional flag in solr.xml to mark that any core is also
: the default core
: 2) rename DEFAULT_CORE to something nicer like "collection1"
...having a default="true" a
I think that most of these complications go away to a remarkable degree if
you combine katta style random assignment of small shards.
The major simplifications there include:
- no need to move individual documents, nor to split or merge shards, no
need for search-server to search-server communica
On Thu, Jan 14, 2010 at 12:46 PM, Yonik Seeley
wrote:
> I'm actually starting to lean toward "slice" instead of "logical shard".
I've gone with this for now and updated http://wiki.apache.org/solr/SolrCloud
but it's certainly not written in stone if people want to try and come
up with better nami
On Thu, Jan 14, 2010 at 12:30 PM, Ted Dunning wrote:
> Another concept from Katta that is AFAIK missing from the Solr lexicon is
> the distinction between node and shard. In Katta, a node is a server worker
> instance that contains and queries physical shards.
I think it's sort of missing becaus
I'm actually starting to lean toward "slice" instead of "logical shard".
In the future we'll want to enable overlapping shards I think (due to
an Amazon Dynamo type of replication, or due to merging shards, etc),
and a separate word for a logical slice of the index seems desirable.
For instance, o
Logical shard sounds good as "the collection of all identical physical
shards"
Another concept from Katta that is AFAIK missing from the Solr lexicon is
the distinction between node and shard. In Katta, a node is a server worker
instance that contains and queries physical shards. There is usuall
On Thu, Jan 14, 2010 at 12:22 PM, Mark Miller wrote:
> I think we should do both - allow marking any core as the default and
> change our single core example solr.xml to use collection1 rather than
> DEFAULT_CORE.
+1
-Yonik
http://www.lucidimagination.com
Yonik Seeley wrote:
> The current way of allowing the omission of a core name in the URL is
> to name the core DEFAULT_CORE.
> While this functionality is great, and allows a multi-core setup to be
> back compat with existing URLs, if someone does want to also refer to
> the core by it's proper nam
The current way of allowing the omission of a core name in the URL is
to name the core DEFAULT_CORE.
While this functionality is great, and allows a multi-core setup to be
back compat with existing URLs, if someone does want to also refer to
the core by it's proper name, it looks pretty ugly. This
The shards parameter currently references physical shards.
There's also a concept of a logical shard (i.e. all physical shards
with identical index content share the same logical shards...
sometimes what I've also called a shard replica).
Should we use logical shard for this, or does anyone have an
Hi,
It has been a long time since the Woodstox jars have been updated. Is
this intentional, as in are there any issues if we use the latest jars
with Solr?
Thanks,
Kumar
31 matches
Mail list logo