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.
