mysql: why this partition strategy could resolve twitter's two query patern?

I am reading the slides shared by Mr. Kallen, i dont understand one of the slides:

Mr. Kallen claims that this partition strategy can work for both query pattern:

1. get the t开发者_高级运维weets of a given user.
2. get the tweets by a given id.

I can understand that it works for "get the tweets for a given user", but how it works for "get the tweets by a given id"?

I didn't grow through the hour long video but maybe it would help you to understand that the API response for a given Tweet ID also contains the user info which can also be drilled down and queried to get that users tweets "based" on a given tweet I.D. Also the same goes for a given user I.D., this will be tied into the users name, their latest tweets, etc. Every response has at least these pieces of information.

I would thoroughly go through the Twitter API documentation or the Streaming API documentation depending on what you want to learn more about.

https://dev.twitter.com/docs

he says(~17:30) that they replicated the db as well ( in addition to partitioning).. one of copies (of data) is partitioned by tweet id and the other is partitioned by user id .. However this creates additional problem of keeping the two copies consistent

may be the PK of the 1st partition is user_id but the other is id.

I think it's a key-value mechanism to map a user_id to a tweet id. It's reasonable to get a certain tweet with the person who post this tweet or retweet somewhat. So using this way can quickly locate the user_id which is related to a certain tweet id.