Atomic increment/add #265
Atomic increment/add #265
Conversation
|
I'll dig into this in a little bit and it could go into 2.1. Compaction and increments can be tricky. The best way to go about it might be to use a new qualifier heading (same format as annotations) for increments so that they aren't compacted, OR on a re-compaction, columns with the increment header could be added to existing compacted values. |
|
Yes, I have noticed that. :-) |
|
Great! Annotations use the 0x01 prefix so we could assign increments 0x02. They're always 8 byte unsigned ints in HBase so we don't need the length and type encoding in a qualifier so the other 2 or 4 bytes can be the offset. Using the prefix, compactions should be skipped in the same way they are for annotations. |
|
That is a wonderful idea! On Thu, Feb 27, 2014 at 9:15 AM, Chris Larsen notifications@github.comwrote:
|
| import net.opentsdb.uid.UniqueId; | ||
| import net.opentsdb.stats.Histogram; | ||
| import net.opentsdb.stats.StatsCollector; | ||
| import com.stumbleupon.async.Callback; |
There was a problem hiding this comment.
Avoid re-arranging imports if possible. Just clutters PRs.
|
Hi, what happend with this PR ? was merged? |
This is a new pull request for @KevinOrtman atomic increment feature (tsuna#2) that was made against 1.X code base and never added master.
Basically the same code, except minor changes for 2.0 code base and using add-keyword instead of inc. There was some discussion about this in above mentioned pull request.
Another thing done is that I have disabled scheduleForCompaction(...) within the increment. Does this mean that a row created by add will never be compacted?
I would guess that compaction and atomic increment for already compacted values is not good fit.
Would like to see a discussion if this could be incorporated into the project.