> I think there might be some confusion about what the value VERSIONS=X for. > > HBase allows one to store multiple version at a specific row/column. They > are distinguished by their timestamp, and provided in descending order - > largest timestamp first. Normally one does not specifically set a > timestamp, which then defaults to 'now' in millisecond accuracy as provided > by System.currentTimeMillis(). > > The per-column family setting "VERSIONS" indicates how many versions > (including the newest one) hbase should (a) retain (during compactions) and > (b) return at maximum (since delayed compactions can allow more than X > version temporarily). This is per row & column. > > One can always have unlimited rows and columns, but in the 'time dimention' > at each point, the number of versions allowed is restricted by this setting. > > Does that answer your questions?
Well, why? I don't question about the mechanism. Is there some reference from the bigtable paper? On Fri, May 22, 2009 at 5:09 PM, Ryan Rawson <[email protected]> wrote: > I think there might be some confusion about what the value VERSIONS=X for. > > HBase allows one to store multiple version at a specific row/column. They > are distinguished by their timestamp, and provided in descending order - > largest timestamp first. Normally one does not specifically set a > timestamp, which then defaults to 'now' in millisecond accuracy as provided > by System.currentTimeMillis(). > > The per-column family setting "VERSIONS" indicates how many versions > (including the newest one) hbase should (a) retain (during compactions) and > (b) return at maximum (since delayed compactions can allow more than X > version temporarily). This is per row & column. > > One can always have unlimited rows and columns, but in the 'time dimention' > at each point, the number of versions allowed is restricted by this setting. > > Does that answer your questions? > > > > On Fri, May 22, 2009 at 1:00 AM, Edward J. Yoon <[email protected]>wrote: > >> Hey, >> >> The different rows are in other table version. I think the 'versions' >> is the table property, not row property. >> >> On Fri, May 22, 2009 at 4:33 PM, Ryan Rawson <[email protected]> wrote: >> > Hey, >> > >> > those 2 entries have different rows ids, with different timestamps (same >> > column, same value). >> > >> > btw, setting timestamps in a non-monotonically increasing order may cause >> > performance and certain correctness issues on 0.20. Best to avoid it for >> > production code if you can. >> > >> > On Fri, May 22, 2009 at 12:27 AM, Edward J. Yoon <[email protected] >> >wrote: >> > >> >> OK, It's my typos, not my point. Result is same even if 'versions' is >> >> 1. Anyway, Do you think 'version mixed' table should be appeared? >> >> >> >> hbase(main):025:0> describe 't1' >> >> {NAME => 't1', IS_ROOT => 'false', IS_META => 'false', FAMILIES => >> >> [{NAME => 'f1', BLOOMFILTER => 'false', COM >> >> PRESSION => 'NONE', VERSIONS => '1', LENGTH => '2147483647', TTL => >> >> '-1', IN_MEMORY => 'false', BLOCKCACHE => >> >> 'false'}], INDEXES => []} >> >> 1 row(s) in 0.0230 seconds >> >> hbase(main):028:0> scan 't1' >> >> ROW COLUMN+CELL >> >> r1 column=f1:, timestamp=1, value=value >> >> r2 column=f1:, timestamp=3, value=value >> >> 2 row(s) in 0.0240 seconds >> >> >> >> On Fri, May 22, 2009 at 3:41 PM, Ryan Rawson <[email protected]> >> wrote: >> >> > Hey, >> >> > >> >> > I generally don't think of hbase entries like spreadsheets with >> 'nulls' >> >> in >> >> > the empty locations. Its really more like an adjacency list, where >> the >> >> data >> >> > is only there when it's there. >> >> > >> >> > But I was referring to your create, the key is 'VERSIONS' not >> 'VERSION'. >> >> > create 'table', {NAME=>'family', VERSIONS=>1} >> >> > >> >> > >> >> > >> >> > On Thu, May 21, 2009 at 11:35 PM, Edward J. Yoon < >> [email protected] >> >> >wrote: >> >> > >> >> >> Let's assume, there are two 2 * 2 sparse tables as below. >> >> >> >> >> >> t1 >> >> >> ---- >> >> >> null 2 >> >> >> -1 null >> >> >> >> >> >> t2 >> >> >> ---- >> >> >> -3 null >> >> >> null null >> >> >> >> >> >> I'll put these tables to table 'x'. And, The table 'x' will handle >> >> >> only one version. Then, 't2' should be appeared, not 't1' + 't2' >> >> >> table. >> >> >> >> >> >> Currently, Hbase shows the 't1' + 't2' table as below. >> >> >> ---- >> >> >> -3(t2) 2(t1) >> >> >> -1(t1) null (what is this?) >> >> >> >> >> >> Should I update the all 't1' entries? >> >> >> >> >> >> On Fri, May 22, 2009 at 3:11 PM, Ryan Rawson <[email protected]> >> >> wrote: >> >> >> > The key is 'VERSIONS'. Give it another shot. >> >> >> > >> >> >> > -ryan >> >> >> > >> >> >> > On Thu, May 21, 2009 at 11:07 PM, Edward J. Yoon < >> >> [email protected] >> >> >> >wrote: >> >> >> > >> >> >> >> hbase(main):001:0> create 't1', {NAME=> 'f1', VERSION => 1} >> >> >> >> hbase(main):002:0> put 't1', 'r1', 'f1' ,'value', 1 >> >> >> >> hbase(main):007:0> put 't1', 'r2', 'f1:' ,'value', 2 >> >> >> >> >> >> >> >> I made a table 't1' as above. And, When scan this, >> >> >> >> >> >> >> >> hbase(main):008:0> scan 't1' >> >> >> >> ROW COLUMN+CELL >> >> >> >> r1 column=f1:, timestamp=1, value=value >> >> >> >> r2 column=f1:, timestamp=2, value=value >> >> >> >> 2 row(s) in 0.0330 seconds >> >> >> >> >> >> >> >> I expected only one row 'r2' (sparse table for time t2) but there >> are >> >> >> >> two tables on time dimension. I think it's a logical bug. The 't1' >> >> >> >> should maintain only one version of time dimension table. >> >> >> >> >> >> >> >> What do you think? >> >> >> >> -- >> >> >> >> Best Regards, Edward J. Yoon @ NHN, corp. >> >> >> >> [email protected] >> >> >> >> http://blog.udanax.org >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best Regards, Edward J. Yoon @ NHN, corp. >> >> >> [email protected] >> >> >> http://blog.udanax.org >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Best Regards, Edward J. Yoon @ NHN, corp. >> >> [email protected] >> >> http://blog.udanax.org >> >> >> > >> >> >> >> -- >> Best Regards, Edward J. Yoon @ NHN, corp. >> [email protected] >> http://blog.udanax.org >> > -- Best Regards, Edward J. Yoon @ NHN, corp. [email protected] http://blog.udanax.org
