Replication on the storage layer will provide a reliable storage for the
index and other data of Solr. In particular, this replication does not
guarantee your index files are consistent at any time as there may be
intermediate states that are only partially replicated. Replication is
only a converg
On Sat, Apr 18, 2015 at 12:20 AM "Jürgen Wagner (DVT)" <
juergen.wag...@devoteam.com> wrote:
> Replication on the storage layer will provide a reliable storage for the
> index and other data of Solr. In particular, this replication does not
> guarantee your index files are consistent at any time
Some comments inline:
On Sat, Apr 18, 2015 at 2:12 PM, gengmao wrote:
> On Sat, Apr 18, 2015 at 12:20 AM "Jürgen Wagner (DVT)" <
> juergen.wag...@devoteam.com> wrote:
>
> > Replication on the storage layer will provide a reliable storage for the
> > index and other data of Solr. In particular,
Thx Chris & Ahmet !
Le 17/04/2015 23:56, Chris Hostetter a écrit :
: df and q.op are the ones you are looking for.
: You can define them in defaults section.
specifically...
https://cwiki.apache.org/confluence/display/solr/InitParams+in+SolrConfig
:
: Ahmet
:
:
:
: On Friday, April 17, 2015
Thank you everyone for the feedback!
I've implemented and committed the flatter structure:
https://issues.apache.org/jira/browse/SOLR-7422
So either form can now be used (and I'll be switching to the flatter
method for examples when it actually reduces the levels).
For those who want to try it ou
Thanks Andrea and Erick. It helped my understanding.
Thanks & Regards
Vijay
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: 17 April 2015 17:27
To: solr-user@lucene.apache.org
Subject: Re: HttpSolrServer and CloudSolrServer
Additionally when indexing, Clou
Alther minor benefit to the flatter structure means that the "smart
merging" of multiple JSON parameters works a little better in
conjunction with facets.
For example, if you already had a "top_genre" facet, you could insert
a "top_author" facet more easily:
json.facet.top_genre.facet.top_author=
AFAIK, the HDFS replication of Solr indexes isn't something that was
designed, it just came along for the ride given HDFS replication.
Having a shard with 1 leader and two followers have 9 copies of the
index around _is_ overkill, nobody argues that at all.
I know the folks at Cloudera (who contri
Late here but let me add one more thing: IIRC the recommendation for JSON
is to never use data as a key in objects. One of the benefits of not using
data as a keys in JSON is easier validation using JSON schema. If one wants
to validate JSON query for Elasticsearch today it is necessary to implemen
Oh... and btw, I think the readability of the JSON will be less and less
important going forward. Queries will grow in size anyway (due to nested
facets) and the ability to quickly validate the query using some parser
will be more useful and practical than relying on human eye doing the check
inste
10 matches
Mail list logo