Afraid I just took a sample set of data that was available to me at my last job, and ran the test. It kind of matched my expectations in terms of locallucene at the time, and what Ure predicted for Trie.
To give you an idea of it's performance in production, the bounding box retrieval for a single solr core of about 3million docs on a dual core 2.3ghz server with I think 8gb of ram, was about 8 - 12ms avg. And had ~ 3,000 results per result set. The slow part for geo search was always the distance calculation not the bounding box retrieval. I've seen feedback of where hilbert curve is meant to be faster again by an average of 40%, so say 4-6 ms for bounding box retrieval. But that still doesn't solve the long haul of distance calculations, which has been one of my focuses recently with a new projection and distance calculation based up that projection. On Tue, Dec 29, 2009 at 11:31 AM, Chris Male <gento...@gmail.com> wrote: > Hi, > > I had never done any experiments comparing them, that was what I was hoping > was going to be explored more and it seems you have done that. Do you have > more statistics by chance? Does the difference (which is pretty dramatic) > stay a constant ratio as you change the density and/or distances? > > On Tue, Dec 29, 2009 at 8:25 PM, patrick o'leary <pj...@pjaol.com> wrote: > > > Hmm, so it's faster to do 2 range searches than use the TermEnumerator to > > find maybe 4-6 individual CartesianTier id's? > > > > I had similar approaches in the past like 2 years ago, that just weren't > > fast enough, and I've even published comparisons with Trie data types, > and > > find CartesianTier id's > > > > > https://issues.apache.org/jira/browse/SOLR-773?focusedCommentId=12708605&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12708605 > > > > The speed of Trie match what Ure's expectations were about 100ms, but > > Cartesian is just 12ms. > > > > The custom code, well you'd have to have custom code to figure out the > > bounding box from a point, unless you want to user to figure that out? > > And the Cartesian stuff is pretty small, it's underlying structure can / > > and > > now does use Trie (simply because it's the only numeric field cache > > interface common between lucene and solr). > > > > P > > > > > > On Tue, Dec 29, 2009 at 11:11 AM, Chris Male (JIRA) <j...@apache.org> > > wrote: > > > > > > > > [ > > > > > > https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795112#action_12795112 > > ] > > > > > > Chris Male commented on SOLR-1586: > > > ---------------------------------- > > > > > > Ah yes sorry TrieFields. I don't see searching 2 fields as a downside > > > since that's just an implementation detail like the Spatial Tile (which > > > requires you to have upto 15 fields). Assuming you can use the Point > > > FieldType to index an x and y field, then it just becomes another > option > > > like Spatial Tile. The fact they are supported out of box is part of > the > > > attraction, as it would reduce how much custom code has to be > maintained. > > > > > > > Create Spatial Point FieldTypes > > > > ------------------------------- > > > > > > > > Key: SOLR-1586 > > > > URL: https://issues.apache.org/jira/browse/SOLR-1586 > > > > Project: Solr > > > > Issue Type: Improvement > > > > Reporter: Grant Ingersoll > > > > Assignee: Grant Ingersoll > > > > Priority: Minor > > > > Fix For: 1.5 > > > > > > > > Attachments: examplegeopointdoc.patch.txt, > > > SOLR-1586-geohash.patch, > > SOLR-1586.Mattmann.112209.geopointonly.patch.txt, > > > SOLR-1586.Mattmann.112209.geopointonly.patch.txt, > > > SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, > > > SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, > > > SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, > > > SOLR-1586.Mattmann.120709.geohashonly.patch.txt, > > > SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, > > > SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt, > > > SOLR-1586.Mattmann.122609.patch.txt, SOLR-1586.patch, SOLR-1586.patch > > > > > > > > > > > > Per SOLR-773, create field types that hid the details of creating > > tiers, > > > geohash and lat/lon fields. > > > > Fields should take in lat/lon points in a single form, as in: > > > > <field name="foo">lat lon</field> > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > You can reply to this email to add a comment to the issue online. > > > > > > > > > > > > -- > Chris Male | Software Developer | JTeam BV.| www.jteam.nl >
