Używam Solr 3.6.1. Jaki jest poprawny typ pola do użycia w polu sortowania Solr zawierającym wartości całkowite? Potrzebuję tego pola tylko do sortowania i nigdy nie wykonuję zapytań dotyczących zakresu. Czy powinienem używać integer
lub sint
?Jaki jest poprawny typ pola Solr, który ma być używany do sortowania wartości całkowitych?
widzę, że w schema.xml istnieje sint
typ zadeklarowany jako:
<!-- Numeric field types that manipulate the value into
a string value that isn't human-readable in its internal form,
but with a lexicographic ordering the same as the numeric ordering,
so that range queries work correctly. -->
<fieldType name="sint" class="solr.SortableIntField" sortMissingLast="true" omitNorms="true"/>
natomiast integer
mówi co następuje:
<!-- numeric field types that store and index the text
value verbatim (and hence don't support range queries, since the
lexicographic ordering isn't equal to the numeric ordering) -->
<fieldType name="integer" class="solr.IntField" omitNorms="true"/>
Głównym powodem Pytam to dlatego każdy Solr sort ja robię na polu sint
(mam wiele z nich zadeklarowanych jako pola dynamiczne) zapełnia (nie konfigurowalne) lucene poleCache. Widzę na stronie statystyk (http: // host: port/solr/CORE/admin/stats.jsp) pod fieldCache że sint
rodzaju są przechowywane jako
org.apache.lucene.search.FieldCache$StringIndex
natomiast integer
rodzaju są przechowywane jako
org.apache.lucene.search.FieldCache.DEFAULT_INT_PARSER
które według mnie zajmuje mniej miejsca?
UPDATE: Solr 3.6.1 schema.xml jest int
zadeklarowane jako TrieIntField
czyli jak
<fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/>
Powyższy jeden był ze starszej wersji Solr.
Powinieneś zawsze używać TrieIntField zamiast IntField i SortableIntField: ta klasa ma ** dużo ** bardziej wydajną pamięć FieldCache imp – jpountz