Live data from Hacker News

Geosharded Recommendations with Hilbert Curve at Tinder

tech.gotinder.com

41–47 of 47 posts

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#41

Is this an advertisement for S2? there is no description of alternatives, of how the choice was made, no comparison to any other system or provider, ... Redis has geo search for example, why not using it?

geo-indexing is different from geo-sharding, search indexes normally have geo-indexing, but it is still one big index handles every single search. The alternative(geohash) is mentioned in article, which has high distortion around earth poles.

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#42

Very interesting. Used to do something similar for a project I work on. Used geohash based sharding, instead of complex curves like that. Worked great, but with recent advances in ES its no longer needed. They don't seem to mention which version of ES they are on, and would be curious how it has changed over time in their experience.

Same strategy can be applied regardless of ES version. ES6 does has index sorting and other optimizations, but not as good as pre-sharding for location based services, cases like Tinder.

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#43
post #25

Why not Z-order curve instead? Hilbert is more complex to compute...

They mentioned the distortion near the poles when using geohashing (which uses z-order curves), but I doubt they have many users at the North or South Pole.

not just near the poles. Geohash distortion is already very obvious when you compare UK and countries in south Asia.

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#44
post #34

Let me share my experience building location based search at Qbix. All of it is available now for free in the Places plugin: https://github.com/Qbix/Platform/tree/master/platform/plugin... First of all, we normally do our sharding by the hash of the primary key. Typically it is the publisherId and hash of the name of a “stream”, which is our general dynamic data structure. What this does is essentially distribute the…

Thanks for sharing EGreg.

Elasticsearch has geo-indexing as well(based on geohash internally), and by default it does id hashing similar to what you said(murmurhash3), we actually leverages that for location based searches.

The challenge addressed in the blog is not in how to search/address(as said Elasticsearch handles it already), it is about how to distribute the load so calculation only happens on limited nodes, and reduce the index size so it can be more performant.

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#45
post #44
post #34

Let me share my experience building location based search at Qbix. All of it is available now for free in the Places plugin: https://github.com/Qbix/Platform/tree/master/platform/plugin... First of all, we normally do our sharding by the hash of the primary key. Typically it is the publisherId and hash of the name of a “stream”, which is our general dynamic data structure. What this does is essentially distribute the…

Thanks for sharing EGreg. Elasticsearch has geo-indexing as well(based on geohash internally), and by default it does id hashing similar to what you said(murmurhash3), we actually leverages that for location based searches. The challenge addressed in the blog is not in how to search/address(as said Elasticsearch handles it already), it is about how to distribute the load so calculation only happens on limited nodes,…

Ah, the goal makes sense. I would suggest that it’s not so bad to have a controller node fan-out and fan-in queries, as long as the database can handle many concurrent queries. Essentially you’re distributing the work evenly across nodes but you don’t have affinity for a particular node. Yes, there is more latency (it is as slow as the slowest connection) but it is endlessly scalable. But, I am sure I missed some benefits from localizing calculations to only a node or two.

In the scheme above, by the way, it DOES localize searches on one shard. Essentially all relations to a stream are on the same shard as the stream. And each center+radius has one associated stream and therefore the search takes place on one shard.

Re: Geosharded Recommendations with Hilbert Curve at Tinder

#46
post #19

Earlier quoted context omitted.

The bigger problem is when people comment and even discuss the title without reading the article. It's extremely common on Reddit but luckily less prevalent on Hacker News .

...if paywalled then at least you know some people at least tried to read the article because they comment about the paywall. Everyone else a) paid their way (as if), b) got a free pass as they don't generally read articles, c) used that new trick for bypassing the article that only people who read articles know about or d) just blurted their opinion without reading the article. I know there have been changes on the…

I don't mind when people only read the comments, honestly. As you say, sometimes the comments are more insightful than the article. But I do think that anyone making a comment related to the article should have read the article. Otherwise it's the blind leading the blind.
Post reply on HN