What is the best way to manage thousands of geopoints per document?

(Laurent T.) #1

Referencing Would having thousands of geopoints for one index cause problems?


I'm trying to find what is the best way, performance-wise, to 1- index thousands of geopoints per document (point + radius) and 2- selecting one of these documents based on my query's geopoint matching with one of the document's.

Currently I use an Array of geopoint in each of my documents but that seems to become problematic when reaching high number of geopoints (100k+). The indexing process kills the real time performance of the document fetcher.

I'm thinking of defining my geopoints in an other type or maybe even an other index and use some kind of reference to query those. In most cases, I was thinking of having 1 to 10 geohash in each main document that summarizes all geopoints so i can use those as a pre-filter.
Then my options are:

  • Use application-side join on either:
    • An other index containing a type per main document containing one geopoint per document.
    • An other type containing one document per main document and per geopoint.
    • An other type containing one document per main document each containing an array of geopoints.
  • Use a child type containing one geopoint per document and referencing the parent main document.

In all those solutions, I would address the indexing part as the geopoint indexation would only occur when that list changes. What remains is the performance on the query's end. What would you say is the most performant ?
One thing to keep in mind is that the document may change often whereas the geopoint list will stay fixed most of the time.


(system) #2