Have a look at the bigtable paper, it should help you understand somewhat why things are the way they are.
The versioning of HBase is integral to the storage mechanism behind it (and also cassandra and all bigtable like systems). HBase stores it's data on HDFS which has immutable files. Thus "overwriting" old values just does not exist. So a versioning mechanism was introduced (all part of the original BT paper) to allow you to supersede and delete (via adding special delete markers) old values. A process known as 'compaction' removes excessive versions and deleted values - this compaction is run by default once a day (it is IO intensive). If you don't care about timestamp, you can just ignore them and use HBase like any storage system - with a small caveat: excessive version creation can cause issues (think hundreds of megs of versions in one row - a region would end up being 1 row and larger than the max size for a region and thus un-splittable). So avoid that. But other relational databases use versioning, for example the MVCC of Postgres cause multiple version of a value. Normally this is completely hidden and is used primarily to implement TX isolation, it also is operationally exposed to the administrator - the vacuum command. Looking at the wiki entry for Temporal database, I can say that HBase (and bigtable) are NOT temporal databases by their example. When you delete a row, it is removed and thus the data goes away. There is a time component, but I encourage people to think of it as versioning and backup against application bugs - excessive use of the time dimension can cause problems (by making a single row larger than the max size of a region). -ryan 2010/5/6 Takayuki Tsunakawa <tsunakawa.ta...@jp.fujitsu.com>: > Hello, > > I'm new to HBase, so excuse me if I make odd questions. > > I'm evaluating HBase from its documentation, and am attracted by its > broad functionality such as transaction support, secondary index, REST > API, MapReduce integration, etc. When I recommended HBase to my > colleagues for the internal project, I was asked a question about how > column timestamp (version) is useful. They said "One of the good > things of key-value stores is the simple and flexible data structure. > But HBase has more structural elements than RDB, column family and > timestamp, and those additional elements HBase a bit more difficult > than RDB. I understand the usefulness of column family, however, in > what situations is timestamp used? Is it really necessary?" > > I couldn't answer their question. Then I searched HBase web site, > HBase user mailing list archive, other web sites with keyword "HBase > timestamp", and Cassandra's web site for help. But I could not find > any information about how the column timestamp (versioning) is useful. > > Could you tell me in what situations the timestamp is absolutely > necessary or at least desirable? Some real world examples are much > appreciated. > From the search results, many people don't seem to use the timestamp > feature. However, the default maximum versions for each column is 3. > If versioning is rarely utilized, doesn't it mean that the storage > space for extra two versions is wasted and the default should be one? > Please give me your opinions. > > Is HBase's timestamp feature intended for the following "temporal > database"? If so, how do you structure the Person table in the > following page? > > http://en.wikipedia.org/wiki/Temporal_database > > > Regards > > >
