Thanks for the suggestion, Erick. However here what we need is not a patch,
is a clarification from practice perspective.
I think solr replication is a great feature to scale reads, and kind of
increase reliability. However, on HDFS it is not as useful as just
sharding. Sharding can scale both
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
In simple words:
HDFS is good for file-oriented replication. Solr is good for index replication.
Consequently, if atomic file update operations of an application (like Solr)
are not atomic on a file level, HDFS is not adequate - like for Solr with live
index updates. Running Solr on HDFS (as a
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
Please see my response in line:
On Fri, Apr 17, 2015 at 10:59 PM Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
Some comments inline:
On Sat, Apr 18, 2015 at 2:12 PM, gengmao geng...@gmail.com wrote:
On Sat, Apr 18, 2015 at 12:20 AM Jürgen Wagner (DVT)
juergen.wag...@devoteam.com
Done and thanks!
The Reference Guide
(https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide)
is another place to look, it's getting considerable attention at this
point. It's curated a bit more than the Wiki however, so if you see
anything wrong there please make comments
Hi there!
I'd like to be added to the list of people who are able to edit the solr
wiki at https://wiki.apache.org/solr. I'm working as a Java developer for a
german company using Solr (and like it a lot) a lot and I would like to be
able to correct things as soon as I find them without going to
There are no nested schemas as such. It's only a superset schema that
includes all the fields for parents and children. Obviously, the
fields that are not common should be optional.
The rest depends on what parent/child relation you are trying to
setup. Whether it is explicit with block indexing
Thanks, Anshum. Looks like there's no way for this to work in 5.1 for us
so I'll just have to wait to for the fixes. Relieving to know it wasn't
just me, though.
--Ere
18.4.2015, 2.45, Anshum Gupta kirjoitti:
The other issue that would fix half of your problems is:
I assume you don't have much free space available in your disk. Notice that
during optimization (merge into a single segment) your shard replica space
usage may peak to 2x-3x of it's normal size until optimization completes.
Is it a problem? Not if optimization occurs over shards serially and your
10 matches
Mail list logo
