Sharding and IDs at Instagram
instagram-engineering.tumblr.com
Sharding and IDs at Instagram
1–10 of 53 posts
Re: Sharding and IDs at Instagram
#2[deleted]
Re: Sharding and IDs at Instagram
#3This seems fairly neat. Is it possible to do something like this with MySQL?
Re: Sharding and IDs at Instagram
#4This seems fairly neat. Is it possible to do something like this with MySQL?
(author here) I think this should also be possible with MySQL's stored functions, but one huge benefit to PostgreSQL is the schema/tablespace feature, since it means all our logical shards all live inside one database (you could do something similar with MySQL, but it would mean multiple databases or prefixing table names with the shard ID).
Re: Sharding and IDs at Instagram
#5I've used the "snowflake" like approach in the past with great success. It's really not all that complicated. The reliance on time in the Instagram approach is a bit scary. A few ms off here and there could really hurt this scheme. How do you handle seamlessly transitioning these across machines when your shards move?
Re: Sharding and IDs at Instagram
#6I like it. Question, did you consider using composite keys of shard_id and id to make up a single primary key? If so what were the pros/cons you found with that approach?
btw, tambem sou brasileiro vivendo em san francisco (https://twitter.com/#!/artilheiro)
Re: Sharding and IDs at Instagram
#7What I'd be more curious to hear about, is how they deal with super nodes and if they're storing a map (or any kind of routing table) or simply using generic modulo hashing on a key.
Re: Sharding and IDs at Instagram
#8What I'd be more curious to hear about, is how they deal with super nodes and if they're storing a map (or any kind of routing table) or simply using generic modulo hashing on a key.
Right now, it's a lookup dict in our Django app--which involves brief downtime just to update the shard map when moving the data (more on this in another post). We hash on user ID (in most cases) and then look the shard # in the dict, then look up the shard # in a logical-to-physical dict.
By the way we use & love Sentry!
Re: Sharding and IDs at Instagram
#9What I'd be more curious to hear about, is how they deal with super nodes and if they're storing a map (or any kind of routing table) or simply using generic modulo hashing on a key.
Right now, it's a lookup dict in our Django app--which involves brief downtime just to update the shard map when moving the data (more on this in another post). We hash on user ID (in most cases) and then look the shard # in the dict, then look up the shard # in a logical-to-physical dict. By the way we use & love Sentry!
Ah so you don't actually have 1000 (or whatever) schemas set up right off the bat?
Or I might be misunderstanding, and you're saying that you're just mapping which physical server has the schemas
Re: Sharding and IDs at Instagram
#10I've used the "snowflake" like approach in the past with great success. It's really not all that complicated. The reliance on time in the Instagram approach is a bit scary. A few ms off here and there could really hurt this scheme. How do you handle seamlessly transitioning these across machines when your shards move?
Not really. Like MongoDB, the first four bytes of an ObjectId are a timestamp. That the timestamp is synced with other instances isn't paramount because the actual value of the timestamp does not matter. What does matter is that the timestamp is new and increasing every second. This is to retain sorting capabilities. With the 13 bits that represent the logical shard ID from this article, Instagram will guarantee uniqueness of an ID within the granularity of a second.