Thanks. We want to upgrade data structure of all old records... so,..., seems like the best way to do it is probably to build a completely new table instead of doing things in-place.
On Tue, Jun 16, 2009 at 12:55 PM, Ryan Rawson<[email protected]> wrote: > You don't "update" an old value, instead you insert the new value with a new > timestamp and then readers see that value instead. > > Multiple values at the same timestamp will always result in undeterminate > return order. If the ts are the same, how do we know which one is newer? > > Id avoid inserting with "random timestamps", conceptually it doesn't make > sense, since ts isn't just a 64 bit int but has specific semantic > interpretation, you risk getting nonsensicial results. > > On Jun 16, 2009 12:49 PM, "Xinan Wu" <[email protected]> wrote: > > I am aware that inserting data into hbase with random timestamp order > results indeterminate result. > > e.g. comments here > https://issues.apache.org/jira/browse/HBASE-1249#action_12682369 > > I've personally experienced indeterminate results before when I insert > in random timestamp order (i.e., multiple versions with same timestamp > in the same cell, out-of-order timestamp when getting multiple > versions). > > In other words, we don't want to go back in time in inserting cells. > Deletion is ok. But is updating pretty much the same story as > inserting? > > i.e., if I make sure the timestamp does exist in the cell, and then I > _update_ it with that timestamp (and same value length), sometimes > hbase still just inserts a new version without touching the old one, > and of course timestamps of this cell becomes out of order. Even if I > delete all versions in that cell and reinsert in the time order, the > result is still out of order. I assume if I do a major compact between > delete all and reinsert, it would be ok, but that's not a good > solution. Is there any good way to update a version of a cell in the > past? or that simply won't work? > > Thanks, >
