Thanks for the clear-up!! Ed
On 2011. 7. 22., at 오후 11:03, Ted Yu <[email protected]> wrote: > That's right. > > On Fri, Jul 22, 2011 at 7:01 AM, edward choi <[email protected]> wrote: > >> Thanks for the explanation. >> >> So if I don't care whether the newest row is on the top when doing a Scan, >> then I don't need to bother using Reverse Timestamp of the Row Key? >> >> For example, I am collecting news articles on a daily basis. >> And each article is stored in Hbase, "using YearMonthDate + Title Hash" as >> the Row Key. >> I don't care how the articles are sorted as long as they are grouped by >> YearMonthDate. >> In this case, I don't need Reverse Timestamp. >> Am I right on this one? >> >> Ed >> >> 2011/7/22 Doug Meil <[email protected]> >> >>> >>> It's so that you can get the most recent entry with a Scan. Assuming >> that >>> the key-structure (as explained in the book) is something like >>> <thing><rev-timestamp>. And you are trying to quickly find the most >>> recent entry for <thing>. >>> >>> >>> >>> >>> >>> >>> On 7/22/11 3:18 AM, "edward choi" <[email protected]> wrote: >>> >>>> Hi, >>>> I was studying Hbase with "Hadoop: The Definitive Guide". >>>> There was a schema example that had as the row key, "Group Id + Reverse >>>> Timestamp." >>>> This way the same groups will be located near one another in the table. >>>> Plus, within the same group, rows will be sorted so that the most >> recently >>>> inserted row will be located at the first. >>>> >>>> The part I don't understand is, what is the advantage of using "Reverse >>>> Timestamp" instead of just "Timestamp"? >>>> Why place the newest row on the top? >>>> I thought in Hbase, keys are searched by binary search. And in binary >>>> search, the chronological order has no effect (at least that's how I >>>> understand it). >>>> So why put an extra step to reverse the timestamp? >>>> >>>> Any explanation will be much appreciated. >>>> >>>> Ed. >>> >>> >>
