First, as I mentioned in the post, the DynamoDB folks report that some large enterprises have been happy using geohashing solutions like dynamodb-geo. Not mentioned in the post, is that you can also add geospatial queries by using Elasticache in addition to DynamoDB. If you want to learn more about that option, check out this post on AWS Amplify and Elasticache: medium.com/@gerard.sans/finding-th.... So I think that the DynamoDB team feels like there are good enough solutions out there and there is not enough demand for an officially approved solution to justify the effort.
Which leads to point 2. I am not familiar with the underlying data model of MongoDB and how they implement geospatial indexes. In a more traditional RDBMS, doing a nearness query against a geospatial data type involves a scan, albeit on a potentially fast index.
On the DynamoDB side, the key to DynamoDB's consistent performance while scaling out is the use of partition keys to physically separate data, which keeps queries (by that key) performant, but means that scans can be quite slow and expensive. Simply adding some geospatial data types could encourage people to implement geospatial queries in DynamoDB with scans, leading to bad performance on these queries that may be frequently used in your application. AWS wants to lead us to successful patterns.
This technical complexity is likely another reason for not having geospatial data types in DynamoDB.
I definitely don't have any inside info on this, but those are my best guesses.
One last note here. You could use composite keys, for example MD#BETHESDA#20815 to allow for efficient searches within state, city and zip. Hat tip to the amazing Alex DeBrie and his DynamoDB Book for that one.
Hope this helps! Great question to think about.
Do you have any ideas on what exactly you'd like to see?
I know about the Dynamodb GEO package, but I see not many users are using it and the package hasn't been updated for a long time. I don't want to end up in a situation where I have build an App which will be used by many users with a not supported package.
And Elasticsearch provisioned by Amplify is an expensive solution when you are a startup and not doing much GEO queries yet, so I am looking to alternatives.
In the past I have worked with MongoDB and this worked great.
Nice post about Elasticsearch! Re: your concern, maybe try pinging James Beswick (@jbesw
) or Alex DeBrie (@alexbdebrie) on Twitter to ask for a rec for a supported option for GEO queries on DynamoDB? They both have responded to questions from me before. But I get it, a client might be pretty nervous about using an old/clanky library.
Two reasons I can think of.
First, as I mentioned in the post, the DynamoDB folks report that some large enterprises have been happy using geohashing solutions like dynamodb-geo. Not mentioned in the post, is that you can also add geospatial queries by using Elasticache in addition to DynamoDB. If you want to learn more about that option, check out this post on AWS Amplify and Elasticache: medium.com/@gerard.sans/finding-th.... So I think that the DynamoDB team feels like there are good enough solutions out there and there is not enough demand for an officially approved solution to justify the effort.
Which leads to point 2. I am not familiar with the underlying data model of MongoDB and how they implement geospatial indexes. In a more traditional RDBMS, doing a nearness query against a geospatial data type involves a scan, albeit on a potentially fast index.
On the DynamoDB side, the key to DynamoDB's consistent performance while scaling out is the use of partition keys to physically separate data, which keeps queries (by that key) performant, but means that scans can be quite slow and expensive. Simply adding some geospatial data types could encourage people to implement geospatial queries in DynamoDB with scans, leading to bad performance on these queries that may be frequently used in your application. AWS wants to lead us to successful patterns.
This technical complexity is likely another reason for not having geospatial data types in DynamoDB.
I definitely don't have any inside info on this, but those are my best guesses.
One last note here. You could use composite keys, for example MD#BETHESDA#20815 to allow for efficient searches within state, city and zip. Hat tip to the amazing Alex DeBrie and his DynamoDB Book for that one.
Hope this helps! Great question to think about.
Do you have any ideas on what exactly you'd like to see?
Thanks for your advanced answer.
I know about Elasticsearch. I have written an own blog about that: dev.to/rpostulart/the-guide-to-imp...
I know about the Dynamodb GEO package, but I see not many users are using it and the package hasn't been updated for a long time. I don't want to end up in a situation where I have build an App which will be used by many users with a not supported package.
And Elasticsearch provisioned by Amplify is an expensive solution when you are a startup and not doing much GEO queries yet, so I am looking to alternatives.
In the past I have worked with MongoDB and this worked great.
Nice post about Elasticsearch! Re: your concern, maybe try pinging James Beswick (@jbesw ) or Alex DeBrie (@alexbdebrie) on Twitter to ask for a rec for a supported option for GEO queries on DynamoDB? They both have responded to questions from me before. But I get it, a client might be pretty nervous about using an old/clanky library.
Thx, will do that