design yelp中的partition by locationId VS zipcode

在design yelp案例中，数组库分割partition by locationId vs zipcode中选择的是location id, 但是文中的解释没有看懂其用意。楼主的理解是，相比于by zipcode, partition by locationId这样可以避免single point of failure, 以及能够减少searching latency. 不知道理解是否正确。

应该还是geohash比较精确的， 你可以搜一下，他那个跟距离相关性更大。比如两个相邻城市一线之隔亮点，可能名字就判断不出距离了

资料链接： https://drive.google.com/file/d/ ... Ly/view?usp=sharing

如果zipcode作sharding key，假如同一个zipcode有非常多locationid（比如纽约旧金山等），会造成hot partition，使cluster里某个node接受到的request过多，我是这样理解的。

Partition by Zipcode 会有 hotshard 问题， Partition by Location ID 会做范围搜索时信息散落在很多不同 Shard 上，无法高效搜索。
正确的做法是四楼提出的 Geohash 以及类似的 Google S2。采取这样的做法也可能会有 Hotshard 问题，这时候我们需要调整每个 Shard 里所包含的地图区域，尽量保证一个 Shard 内地图区域是连续的，并且读写负载均衡。

我想要offer真的 发表于 2020-12-21 15:53
应该还是geohash比较精确的， 你可以搜一下，他那个跟距离相关性更大。比如两个相邻城市一线之隔亮点，可能 ...

我的理解是locationID跟地理位置是没有关系的, zip code才跟地理位置有关系

英伦十六世纪 发表于 2020-12-22 13:36
我的理解是locationID跟地理位置是没有关系的, zip code才跟地理位置有关系

他的意思应该是说，zipcode可以把一个region都放一起，但是可能有些城市很hot。locationId会sharding的很分散不好查。感觉这个一般还是用geohash比较好的。

zip code本身是个人为定义的不规则区域，横不平竖不直的。你每次还要先拿经纬度查出zip code。
另外zip code是人为定的，所以还可能会有变更的情况。如果zipcode改了你的系统怎么办？经纬度可是不会改的，你geohash永远都不会变。
总之就是完全看不出用zip code有什么好处。

有讲geohash比较好的文章吗？