Indice Solr vs stocké
Je suis un peu confus quant à la nature du comportement de l'index et des attributs stockés des champs Solr.
Par exemple, si j'ai les éléments suivants dans Schema.xml
<field name="test1" type="text" indexed="false"
stored="false" required="false" />
Le champ test1 ne sera-t-il pas stocké dans le document Solr, même si je crée un document avec ce champ, lui attribue une valeur et le valide dans Solr. Comme j'ai l'attribut stored=false, cela signifie-t-il que la valeur du champ est perdue dans Solr et n'est pas persistée?
C'est correct. En règle générale, vous souhaiterez que votre champ soit indexé ou stocké, ou les deux. Si vous définissez les deux sur false, ce champ ne sera pas disponible dans vos documents Solr (que ce soit pour la recherche ou pour l'affichage). Voir la réponse d'Alexandre pour les cas particuliers dans lesquels vous souhaitez définir les deux sur false.
Comme indiqué here : indexed=true rend un champ interrogeable (et pouvant être trié et facétable). Par exemple, si vous avez un champ nommé test1 avec indexed=true, vous pouvez le rechercher comme q=test1:foo, où foo est la valeur que vous recherchez. Si indexed=false pour le champ test1, cette requête ne renverra aucun résultat, même si vous avez un document dans Solr dont la valeur de test1 est foo.
stored=true signifie que vous pouvez récupérer le champ lorsque vous effectuez une recherche. Si vous souhaitez récupérer explicitement la valeur d'un champ dans votre requête, vous utiliserez le paramètre fl dans votre requête, comme fl=test1 (la valeur par défaut est fl=*, ce qui signifie extraire tous les champs stockés). Seulement si stored=true pour test1, la valeur sera renvoyée. Sinon, il ne sera pas retourné.
Pour que les deux soient définis sur false, il est essentiel de sauter explicitement ce champ particulier.
Par exemple, si vous avez un mappage de stockage/d'indexation dynamicField et que vous souhaitez ignorer un nom particulier qui tomberait sinon sous le modèle de dynamicField.
Vous pouvez également utiliser dynamicField pour ignorer tout un ensemble de champs avec le même préfixe/suffixe provenant d’une tierce partie. Par exemple, Tika vous enverra toute une série de champs de métadonnées que vous voudrez peut-être ignorer. Voir ceci défini dans l'exemple de Solr schema.xml et utilisé dans solrconfig.xml
Dans les versions ultérieures de Solr, vous pouvez également utiliser IgnoreFieldUpdateProcessorFactory (voir la liste complète pour les autres), ce qui éliminera ces champs même plus tôt dans le processus d'indexation.
Citant de this response dans le fil de discussion de Solr:
"indexé" et "stocké" sont des attributs orthogonaux indépendants - vous pouvez utiliser l'une des quatre combinaisons de vrai et de faux. "indexé" est utilisé pour la recherche ou requête, la partie "recherche" du traitement d'une requête. Une fois la la recherche/requête/recherche est terminée et un ensemble de documents est sélectionné, "stocké" est l'ensemble des champs dont les valeurs peuvent être affichées ou renvoyées avec la réponse de Solr.
Une partie de la raison de la séparation est que Solr/Lucene "analyse" ou transforme les données d'entrée en une forme plus efficace pour plus rapide et plus rapide recherche/recherche pertinente. Malheureusement, ces données analysées/transformées sont souvent ne convient plus pour l'affichage et la consommation humaine. En d'autre mots l'analyse/transformation n'est pas bidirectionnelle/réversible. Réglage "storage = true" garantit que les données d'origine peuvent être récupérées dans son forme originale.
Si les deux sont faux, vous perdez vos données dans ce champ. Si vrai indexé, les données sont consultables mais ne peuvent pas être affichées. Si vous définissez true sur stocké, vous ne pourrez pas effectuer de recherche sur ce champ, mais il pourra être affiché (dans ce cas, vous pouvez écrire une règle copyfield pour copier les informations de ce champ dans le champ de recherche par défaut). Les deux sont définis comme vrais -> vous pouvez rechercher et afficher.