On Thu, Jan 14, 2010 at 2:43 PM, Yonik Seeley
wrote:
> 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 "s
> The point I was trying to make is that I believe that if you start changing
> terminologies now people will be very confused
So shard -> remote core... Slice -> core group. Though semantically
they're synonyms. In any case, I need to spend some time looking at
the cloud branch, and less time
On Thu, Jan 14, 2010 at 1:38 PM, Ted Dunning wrote:
> 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 mer
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?).
Yes, a core is a single index and a shard is a conceptual idea which at
the moment concretely refers to a remote core (but not a specific one as
the same sha
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
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
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
: 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
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
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
20 matches
Mail list logo
