0

I'm working with Geofire on Firebase, and based on the documentation I see that most people split the geohash and location nodes, like the image below

enter image description here

In this case, the geohash and location are joined by the key. The index is on the field geofire/geohash.

But when the location data is not user data but instead static map data, and the location data will always be queried after finding the geohashed keys, is it really necessary to split into geofire and location groups? My geofire dataset will eventually have 5+ million keys, so scaling and performance is definitely an issue.

Here's my suggested data model:

geofire
  - key_1234
    -- geohash: "abcd"
    -- latitude: "50.0"
    -- longitude: "8.0"
    -- name: "test point 1"
  - key_5678
    -- geohash: "defg"
    -- latitude: "70.0"
    -- longitude: "-1.0"
    -- name: "test point 2"
philshem
  • 24,761
  • 8
  • 61
  • 127

1 Answers1

0

is it really necessary to split into geofire and location groups?

Geofire currently completely manages the location where it stores the geohashes and keys. It doesn't support combining the geohashes and keys with other data.

If you want to combine the two types of data, you can fork Geofire and make that happen. But it's not provided by the default library.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Based on your [answer](https://stackoverflow.com/a/38341118/2327328), *Trying to store them in one node is a bad idea, since you're mixing mostly static data ...*. I was thinking because my data is never static (only the query point is dynamic), I could cheat a bit and combine data and geohash. Thanks for your help. – philshem Mar 01 '18 at 08:14