Hello Lee, I suppose caching isn't efficient for this type of searches. I can propose a kind of trick. if you index your docs in order by (STARTIP,ENDIP) tuple, it should make intersection faster. However it's rather theoretical consideration than practical one.
More real one is to encode ip range in a single field and search by special query. I'm aware of geospatial approach for this lucene.472066.n3.nabble.com/Modeling-openinghours-using-multipoints-td4025336.html Unfortunately I never did it. On Wed, Jan 9, 2013 at 8:13 PM, Lee Carroll <lee.a.carr...@googlemail.com>wrote: > Hi Otis > > The cache was modest 4096 with a hit rate of 0.23 after a 24hr period. > We doubled it and the hit rate went to 0.25. Our interpretation is ip is > pretty much a cache busting value ? and > cache size is not at play here. > > the q param is just startIpNum:[* TO 180891652]AND endIpNum:[180891652 TO > *] so again our > interpretation is its got little reuse > > Could we re-formulate the query to be more per-formant ? > > > On 9 January 2013 12:56, Otis Gospodnetic <otis.gospodne...@gmail.com > >wrote: > > > Hi, > > > > Maybe your cache is too small? How big is it and does the hit rate > change > > if you make it bigger? > > > > Do any parts of the query repeat a lot? Maybe there is room for fq. > > > > Otis > > Solr & ElasticSearch Support > > http://sematext.com/ > > On Jan 9, 2013 6:08 AM, "Lee Carroll" <lee.a.carr...@googlemail.com> > > wrote: > > > > > 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 > > > > > > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
