5 ms·

Why not PostgreSQL (PostGIS)?

sallen 11y ago
Agreed, this seems silly to build your own which likely performs worse than PosgGIS and has way more bugs. At least the article could have addressed why that would not work for their use case. edit: also now they have to classify polygons into groups that wholly fit into some "city" polygon. That seems like it becomes a pain to maintain since you may want to expand a region in the future and it happens to go outside of your previously defined "city". Or maybe you want a region that isn't in a "city", like a "country" or "mid-atlantic" region.
jjawssd 11y ago
NIH syndrome https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
Cyph0n 11y ago
Or MongoDB geospatial indexing? I used it for a project that required a similar approach (point in polygon). It was quite easy to setup and use, at least at a small scale.
meritt 11y ago
Modern tech companies have a penchant for solving the same problems less efficiently using the latest tech. shrugs
Zikes 11y ago
Increased latency, probably. They said they wanted 99% of queries to be 100ms or less. When I use the pgAdmin and run EXPLAIN ANALYZE SELECT 1; I get 0.025ms execution time, but it takes 62ms to send and recieve that.
- bhahn 11y ago
  Latency is not an issue. That your test took 62ms to send and receive that is an artifact of your setup. Eg. latency across availability zones in the same EC2 region is <2ms (and obviously even faster in the same AZ)
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
throwaway449 11y ago
Most things at Uber were first built in the natural "why don't you just" way. Python/Flask monolith, Postgres, haproxy, etc. They are being replaced with fancier distributed systems (microservices, Schemaless, Ringpop, etc) by necessity.
- TYPE_FASTER 11y ago
  Has the transaction rate surpassed what you can get out of Postgres? If not, what is the necessity for the change? Just curious. Thanks for any insight.

Agreed, this seems silly to build your own which likely performs worse than PosgGIS and has way more bugs. At least the article could have addressed why that would not work for their use case. edit: also now they have to classify polygons into groups that wholly fit into some "city" polygon. That seems like it becomes a pain to maintain since you may want to expand a region in the future and it happens to go outside of your previously defined "city". Or maybe you want a region that isn't in a "city", like a "country" or "mid-atlantic" region.

jjawssd 11y ago

NIH syndrome https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

Cyph0n 11y ago

Or MongoDB geospatial indexing? I used it for a project that required a similar approach (point in polygon). It was quite easy to setup and use, at least at a small scale.

meritt 11y ago

Modern tech companies have a penchant for solving the same problems less efficiently using the latest tech. shrugs

Zikes 11y ago

Increased latency, probably. They said they wanted 99% of queries to be 100ms or less. When I use the pgAdmin and run EXPLAIN ANALYZE SELECT 1; I get 0.025ms execution time, but it takes 62ms to send and recieve that.

bhahn 11y ago
Latency is not an issue. That your test took 62ms to send and receive that is an artifact of your setup. Eg. latency across availability zones in the same EC2 region is <2ms (and obviously even faster in the same AZ)

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

throwaway449 11y ago

Most things at Uber were first built in the natural "why don't you just" way. Python/Flask monolith, Postgres, haproxy, etc. They are being replaced with fancier distributed systems (microservices, Schemaless, Ringpop, etc) by necessity.

TYPE_FASTER 11y ago
Has the transaction rate surpassed what you can get out of Postgres? If not, what is the necessity for the change? Just curious. Thanks for any insight.