Oracle has a great feature called flashback query. This allows a user to (try to) query a row as it existed at some point in the past. It provides this functionality by trying to find the necessary UNDO to reconstruct the row as it existed at the time the user requested. If the necessary UNDO does not exist, an error is thrown. This feature is really cool.<\/p>\n
HBase has something similar, only you configure to store a certain number of versions of the the row. In some ways, this is better since you know you will have that number of rows available to query, rather than hoping you have enough UNDO to find the data in which you are interested.<\/p>\n
Below is a simple test case.<\/p>\n
We start by creating a simple table with one column family…<\/p>\n
\r\nhbase(main):058:0> create 'myxml', 'xmlfamily'\r\n0 row(s) in 1.1440 seconds\r\n<\/pre>\nWe can see that by default, HBase creates a table to store the most recent three versions of a cell (what you normally would think of as a row)<\/p>\n
\r\nhbase(main):060:0> describe 'myxml'\r\nDESCRIPTION ENABLED\r\n {NAME => 'myxml', FAMILIES => [{NAME => 'xmlfamily', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', COMPRESSION true\r\n => 'NONE', VERSIONS => '3', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true\r\n '}]}\r\n1 row(s) in 0.0240 seconds\r\n<\/pre>\nWe insert our first row…<\/p>\n
\r\nhbase(main):062:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'first version<\/x>'\r\n0 row(s) in 0.0140 seconds\r\n<\/pre>\n…and see our row was successfully inserted…<\/p>\n
\r\nhbase(main):063:0> get 'myxml', '1' COLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063719710, value=first version<\/x>\r\n1 row(s) in 0.0200 seconds\r\n<\/pre>\nWe proceed to re-insert the row (actually similar to a MERGE in Oracle since the row id is the same) and show that it is now the “current” version…<\/p>\n
\r\nhbase(main):064:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'second version<\/x>'\r\n0 row(s) in 0.0220 seconds\r\n\r\nhbase(main):065:0> get 'myxml', '1'\r\nCOLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063765017, value=second version<\/x>\r\n1 row(s) in 0.0150 seconds\r\n<\/pre>\nWe print all versions we have…<\/p>\n
\r\nhbase(main):070:0> get 'myxml', '1', {COLUMN => 'xmlfamily:mdata_xml', VERSIONS =>3}\r\nCOLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063765017, value=second version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063719710, value=first version<\/x>\r\n2 row(s) in 0.0160 seconds\r\n<\/pre>\nWe then insert a third version of the row, and see that we can still see all of our previous versions.<\/p>\n
\r\nhbase(main):071:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'third version<\/x>'\r\n0 row(s) in 0.0130 seconds\r\n\r\nhbase(main):072:0> get 'myxml', '1', {COLUMN => 'xmlfamily:mdata_xml', VERSIONS =>3}\r\nCOLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063851412, value=third version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063765017, value=second version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063719710, value=first version<\/x>\r\n3 row(s) in 0.0250 seconds\r\n<\/pre>\nHowever, as soon as we insert a fourth row, our first version can no longer be seen. This makes sense, since our table is configured to only have the most recent three versions.<\/p>\n
\r\nhbase(main):073:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'fourth version<\/x>'\r\n0 row(s) in 0.0090 seconds\r\n\r\nhbase(main):075:0> get 'myxml', '1', {COLUMN => 'xmlfamily:mdata_xml', VERSIONS =>10}\r\nCOLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063861477, value=fourth version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063851412, value=third version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063765017, value=second version<\/x>\r\n3 row(s) in 0.0170 seconds\r\n<\/pre>\nWe don’t like this, so we decide to keep more previous versions of a given row, 20 to be specific. As such, we disable the table (required for alterations)<\/p>\n
\r\nhbase(main):076:0> disable 'myxml'\r\n0 row(s) in 2.0380 seconds\r\n<\/pre>\nJust for grins, we try to insert a row, and find a Region exception is thrown. Please note that disabling a table would require an outage.<\/p>\n
\r\nhbase(main):078:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'fifth version<\/x>'\r\n\r\nERROR: org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1 action: NotServingRegionException: 1 time, servers with issues: dell11gr1:9002,\r\n<\/pre>\nWe proceed to make our VERSIONS change and the re-enable our table…<\/p>\n
\r\nhbase(main):080:0> alter 'myxml', {NAME => 'xmlfamily', VERSIONS=>20}\r\n0 row(s) in 0.0260 seconds\r\n\r\nhbase(main):081:0> enable 'myxml'\r\n0 row(s) in 2.0300 seconds\r\n<\/pre>\nWe find we can now insert our rows…<\/p>\n
\r\nhbase(main):082:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'fifth version<\/x>'\r\n0 row(s) in 0.0190 seconds\r\n\r\nhbase(main):083:0> put 'myxml', '1', 'xmlfamily:mdata_xml', 'sixth version<\/x>'\r\n0 row(s) in 0.0110 seconds\r\n<\/pre>\n…but we can also now see our first row. A major compaction is the only time “old” rows are physically removed, so this is the reason they are still visible. The compaction is documented to occur once per day.<\/p>\n
\r\nhbase(main):084:0> get 'myxml', '1', {COLUMN => 'xmlfamily:mdata_xml', VERSIONS =>10}\r\nCOLUMN CELL\r\n xmlfamily:mdata_xml timestamp=1310063963540, value=sixth version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063957685, value=fifth version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063861477, value=fourth version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063851412, value=third version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063765017, value=second version<\/x>\r\n xmlfamily:mdata_xml timestamp=1310063719710, value=first version<\/x>\r\n6 row(s) in 0.0190 seconds\r\n\r\nhbase(main):085:0>\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"Oracle has a great feature called flashback query. This allows a user to (try to) query a row as it existed at some point in the past. It provides this functionality by trying to find the necessary UNDO to reconstruct…<\/p>\n