Hi We are doing a lat/lon look up query using ip address.
We have a 6.5 million document core of the following structure start ip block end ip block location id location_lat_lon the field defs are <types> <fieldType name="string" class="solr.StrField" sortMissingLast="true" omitNorms="true"/> <fieldType name="tlong" class="solr.TrieLongField" precisionStep="8" omitNorms="true" positionIncrementGap="0"/> <fieldType name="tfloat" class="solr.TrieFloatField" precisionStep="8" omitNorms="true" positionIncrementGap="0"/> <fieldType name="tdouble" class="solr.TrieDoubleField" precisionStep="8" omitNorms="true" positionIncrementGap="0"/> <fieldType name="location" class="solr.LatLonType" subFieldSuffix=" _coordinate"/> </types> <fields> <field name="startIp" type="string" indexed="true" stored="false" required=" true"/> <field name="startIpNum" type="tlong" indexed="true" stored="false" required ="true"/> <field name="endIpNum" type="tlong" indexed="true" stored="false" required=" true"/> <field name="locId" type="string" indexed="true" stored="true" required=" true"/> <field name="countryCode" type="string" indexed="true" stored="true" required="false"/> <field name="cityName" type="string" indexed="false" stored="true" required ="false"/> <field name="latLon" type="location" indexed="true" stored="true" required=" true"/> <field name="latitude" type="string" indexed="false" stored="true" required ="true"/> <field name="longitude" type="string" indexed="false" stored="true" required ="true"/> <dynamicField name="*_coordinate" type="tdouble" indexed="true" stored=" false"/> </fields> the query at the moment is simply a range query q=startIpNum:[* TO 180891652]AND endIpNum:[180891652 TO *] we are seeing a full query cache with a low hit rate 0.2 and a high eviction rate which makes sense given the use of ip address in the query. query time mean is 120. Is their a better way of structuring the core for this usecase ? I suspect our heap memory settings are conservative 1g but will need to convince our sys admins to change this (they are not ringing any resource alarm bells) just the query is a little slow
