Hi Chris, thanks for the answer.
the plan is that in lots of queries I just need faceted values and don't even do a fulltext search. And on the other hand I need the fulltext search for exactly one task in my application, which is search documents and returning them. Here no faceting at all is need, but only filtering with fields, which i also use for the other queries. So if 95% of the queries don't use the fulltext i thought it would make sense to split them. Your suggestion to have one main master index and several slave indexes sounds promising. Is it possible to have this replication in SolrCloud e.g with different kind of schemas etc? Thanks. Daniel On Thu, Jul 26, 2012 at 9:05 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : My thought was, that I could separate indexes. So for the facet queries > : where I don't need > : fulltext search (so also no indexed fulltext field) I can use a > completely > : new setup of a > : sharded Solr which doesn't include the indexed fulltext, so the index is > : kept small containing > : just the few fields I have. > : > : And for the fulltext queries I have the current Solr configuration which > : includes as mentioned > : above all the fields incl. the index fulltext field. > : > : Is this a normal way of handling these requirements. That there are > : different kind of > : Solr configurations for the different needs? Because the huge redundancy > > It's definitley doable -- one thing i'm not clear on is why, if your > "faceting" queries don't care about the full text, you would need to leave > those small fields in your "full index" ... is your plan to do > "faceting" and drill down using the smaller index, but then display docs > resulting from those queries by using the same "fq" params when querying > the "full index" ? > > if so then it should work, if not -- you may not need those fields in that > index. > > In general there is nothing wrong with having multiple indexes to solve > multiple usecases -- an index is usually an inverted denormalization of > some structured source data designed for fast queries/retrieval. If there > are multiple distinct ways you want to query/retrieve data that don't lend > themselves to the same denormalization, there's nothing wrong with > multiple denormalizations. > > Something else to consider is an approach i've used many times: having a > single index, but using special purpose replicas. You can have a master > index that you update at the rate of change, one set of slaves that are > used for one type of query pattern (faceting on X, Y, and Z for example) > and a differnet set of slaves that are used for a different query pattern > (faceting on A, B, and C) so each set of slaves gets a higher cahce hit > rate then if the queries were randomized across all machines > > -Hoss >
