Status ids are currently strictly increasing -- that means they're globally unique. In the future, they will be generally increasing -- but still globally unique.
We'll be generating these unique ids in a fault-tolerant, highly-available, low-latency, and high-throughput service. If solving these sorts of challenges, and they aren't always easy, interest you: http://twitter.com/job.html?jvi=oAPbVfwf,Job -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Wed, Feb 17, 2010 at 11:16 PM, Quy <[email protected]> wrote: > Hi John, > > Does that mean that status_ids may not be unique across all users? For > example, one user could have status_id of 123 and another user can > have status_id of 123 so you have to uniquely identify them by their > user/status_id combination? > > On Feb 11, 11:40 pm, John Kalucki <[email protected]> wrote: > > In short, today, yes. Soon, no, but it might not matter. > > > > At the moment, status ids are strictly increasing. We can't keep > generating > > status ids from a single critical section forever though -- at some point > > soon we'll have a loosely-coupled distributed id generation system and > ids > > will be k-sorted. Perhaps the most significant bits will be monotonically > > increasing and the remainder of the precision will be opaque, and appear > > random. With any luck, the monotonically increasing precision will map, > > roughly, to time at a second resolution, so that the k-sorting will be > > within a second quantum. This would allow collation order based on the 1 > > second created_at and a collation order based on the most significant > bits > > will produce a similar, but not identical, ordering. Largely speculation. > > > > So, in the end, the date field remains the safest and the most > future-proof > > way to sort statuses. > > > > -John Kaluckihttp://twitter.com/jkalucki > > Infrastructure, Twitter Inc. > > > > On Thu, Feb 11, 2010 at 2:36 AM, Quy <[email protected]> wrote: > > > When I am sorting tweets, can I just do a simple sort DESC on > > > status_id instead of the creation date? I assume status_ids are > > > created sequentially going up so sorting on status_id would be more > > > efficient than trying to sort on the created_at field. >
