Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atomic increment/add #265

Open
wants to merge 2 commits into
base: next
Choose a base branch
from
Open

Atomic increment/add #265

wants to merge 2 commits into from

Conversation

jakeri
Copy link

@jakeri jakeri commented Dec 23, 2013

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.

@manolama
Copy link
Member

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.

@jakeri
Copy link
Author

jakeri commented Feb 27, 2014

Yes, I have noticed that. :-)
I tested my code change some more and noticed it. I'll see if I can come up with some ideas based on your thoughts.

@manolama
Copy link
Member

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.

@KevinOrtman
Copy link

That is a wonderful idea!

On Thu, Feb 27, 2014 at 9:15 AM, Chris Larsen [email protected]:

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.

Reply to this email directly or view it on GitHubhttps://github.com//pull/265#issuecomment-36251821
.

import net.opentsdb.uid.UniqueId;
import net.opentsdb.stats.Histogram;
import net.opentsdb.stats.StatsCollector;
import com.stumbleupon.async.Callback;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid re-arranging imports if possible. Just clutters PRs.

@farito
Copy link

farito commented Mar 7, 2019

Hi, what happend with this PR ? was merged?

@johann8384 johann8384 changed the base branch from master to next September 26, 2024 16:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants