[ https://issues.apache.org/jira/browse/HBASE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HBASE-2959: ------------------------- Let me take back last comment. Ryan says it should be better than it has ever been. He's working on proving it. > Scanning always starts at the beginning of a row > ------------------------------------------------ > > Key: HBASE-2959 > URL: https://issues.apache.org/jira/browse/HBASE-2959 > Project: HBase > Issue Type: Bug > Components: regionserver > Affects Versions: 0.20.4, 0.20.5, 0.20.6, 0.89.20100621 > Reporter: Benoit Sigoure > Priority: Blocker > > In HBASE-2248, the code in {{HRegion#get}} was changed like so: > {code} > - private void get(final Store store, final Get get, > - final NavigableSet<byte []> qualifiers, List<KeyValue> result) > - throws IOException { > - store.get(get, qualifiers, result); > + /* > + * Do a get based on the get parameter. > + */ > + private List<KeyValue> get(final Get get) throws IOException { > + Scan scan = new Scan(get); > + > + List<KeyValue> results = new ArrayList<KeyValue>(); > + > + InternalScanner scanner = null; > + try { > + scanner = getScanner(scan); > + scanner.next(results); > + } finally { > + if (scanner != null) > + scanner.close(); > + } > + return results; > } > {code} > So instead of doing a {{get}} straight on the {{Store}}, we now open a > scanner. The problem is that we eventually end up in {{ScanQueryMatcher}} > where the constructor does: {{this.startKey = > KeyValue.createFirstOnRow(scan.getStartRow());}}. This entails that if we > have a very wide row (thousands of columns), the scanner will need to go > through thousands of {{KeyValue}}'s before finding the right entry, because > it always starts from the beginning of the row, whereas before it was much > more straightforward. > This problem was under the radar for a while because the overhead isn't too > unreasonable, but later on, {{incrementColumnValue}} was changed to do a > {{get}} under the hood. At StumbleUpon we do thousands of ICV per second, so > thousand of times per second we're scanning some really wide rows. When a > row is contented, this results in all the IPC threads being stuck on > acquiring a row lock, while one thread is doing the ICV (albeit slowly due to > the excessive scanning). When all IPC threads are stuck, the region server > is unable to serve more requests. > As a nice side effect, fixing this bug will make {{get}} and > {{incrementColumnValue}} faster, as well as the first call to {{next}} on a > scanner. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.