hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Trivial Update of "Hbase/JSONRest" by Michael Gottesman
Date Mon, 11 Aug 2008 01:08:22 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The following page has been changed by Michael Gottesman:
http://wiki.apache.org/hadoop/Hbase/JSONRest

------------------------------------------------------------------------------
  == Why JSON? ==
  This is a question that I get asked a lot. Why JSON? Why not Thrift? Why not Protocol Buffers?
The answer I give is simple: The Internet. JSON is native to the web and native to the browser.
By using JSON as your message format, you allow for easy interoperability with any/all platforms
currently in the marketplace. Thus you maximize your potential user base through familiarity,
ease of use, and parser availability for the end user.
  == What about the Old XML Rest Interface? ==
- It will be deprecated once JSONRest is completely finished. Its current wikipage is here:
{}. If you would like to contribute to the construction of JSONRest, please visit HBase Issue
XXXX, located at the following url: {}
+ It will be deprecated once JSONRest is completely finished. Its current wikipage is here:
[wiki:Hbase/HbaseRest HBase Rest]. If you would like to contribute to the construction of
JSONRest, please visit JIRA issue HBASE-814, located at the following url: http://issues.apache.org/jira/browse/HBASE-814
  == Important General Usage Notes *READ THIS* ==
  Please read this before you go further to the usage section. I envision two sorts of users
of JSONRest at the moment: the normal database user, and the timestamp database user.
  
  === For Normal Database Users ===
- I imagine that many people just want to use HBase as a normal database that can scale to
large loads. This does not necessarily require the usage of the timestamp side of HBase. In
this user's mind when he/she overwrites data, it is destroyed. REMEMBER IT IS NOT DESTROYED.
When you overwrite data in HBase through the usage of the non-timestamp part of the Client
API, all that you are doing is writing another Cell at a sooner timestamp. This will cover
up the older versions of the Cell. They are still there, just hidden if you use the non-timestamp
methods. They will still be there and be accessable via the timestamp methods until enough
old timestamp Cells accumulate that HBase cleans them up. This is done via a configuration
setting which allows you to set the number of different timestamp versions of a cell can exist
before HBase deletes the latest value.
+ I imagine that many people just want to use HBase as a normal database that can scale to
large loads. This does not necessarily require the usage of the timestamp side of HBase. In
this user's mind when he/she overwrites data, it is destroyed. REMEMBER IT IS NOT DESTROYED.
When you overwrite data in HBase through the usage of the non-timestamp part of the Client
API, all that you are doing is writing another Cell at a sooner timestamp. This will cover
up the older versions of the Cell. They are still there, just hidden if you use the non-timestamp
methods. They will still be there and be accessible via the timestamp methods until enough
old timestamp Cells accumulate that HBase cleans them up. This is done via a configuration
setting which allows you to set the number of different timestamp versions of a cell can exist
before HBase deletes the latest value.
  
  === For Timestamp Database Users ===
  All the methods without timestamps use HConstants.LatestTimestamp (sp?), so you can still
use them if you want to create a new entry with the latest timestamp or delete the latest
entry.

Mime
View raw message