accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From els...@apache.org
Subject [11/12] accumulo git commit: Merge branch '1.6' into 1.7
Date Thu, 27 Aug 2015 16:06:20 GMT
Merge branch '1.6' into 1.7

Conflicts:
	core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java


Project: http://git-wip-us.apache.org/repos/asf/accumulo/repo
Commit: http://git-wip-us.apache.org/repos/asf/accumulo/commit/162acf2f
Tree: http://git-wip-us.apache.org/repos/asf/accumulo/tree/162acf2f
Diff: http://git-wip-us.apache.org/repos/asf/accumulo/diff/162acf2f

Branch: refs/heads/1.7
Commit: 162acf2f2223e25fa84921eb1fb15749599f7242
Parents: 388e48c 2906895
Author: Josh Elser <elserj@apache.org>
Authored: Thu Aug 27 11:54:25 2015 -0400
Committer: Josh Elser <elserj@apache.org>
Committed: Thu Aug 27 12:06:14 2015 -0400

----------------------------------------------------------------------
 .../accumulo/core/client/BatchScanner.java      | 24 ++++++++++++++------
 1 file changed, 17 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/accumulo/blob/162acf2f/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
----------------------------------------------------------------------
diff --cc core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
index 494bf56,af0fd85..0048c42
--- a/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
+++ b/core/src/main/java/org/apache/accumulo/core/client/BatchScanner.java
@@@ -19,20 -21,34 +21,28 @@@ import org.apache.accumulo.core.data.Ra
  import java.util.Collection;
  import java.util.concurrent.TimeUnit;
  
- import org.apache.accumulo.core.data.Range;
- 
  /**
-  * Implementations of BatchScanner support efficient lookups of many ranges in accumulo.
 - * In exchange for possibly <b>returning scanned entries out of order</b>,
 - * BatchScanner implementations may scan an Accumulo table more efficiently by
++ * In exchange for possibly <b>returning scanned entries out of order</b>, BatchScanner
implementations may scan an Accumulo table more efficiently by
+  * <ul>
 - *   <li>Looking up multiple ranges in parallel.
 - *   Parallelism is constrained by the number of threads available to the BatchScanner,
set in its constructor.</li>
 - *   <li>Breaking up large ranges into subranges.
 - *   Often the number and boundaries of subranges are determined by a table's split points.</li>
 - *   <li>Combining multiple ranges into a single RPC call to a tablet server.</li>
++ * <li>Looking up multiple ranges in parallel. Parallelism is constrained by the number
of threads available to the BatchScanner, set in its constructor.</li>
++ * <li>Breaking up large ranges into subranges. Often the number and boundaries of
subranges are determined by a table's split points.</li>
++ * <li>Combining multiple ranges into a single RPC call to a tablet server.</li>
+  * </ul>
   *
-  * Use this when looking up lots of ranges and you expect each range to contain a small
amount of data. Also only use this when you do not care about the
-  * returned data being in sorted order.
+  * The above techniques lead to better performance than a {@link Scanner} in use cases such
as
+  * <ul>
 - *   <li>Retrieving many small ranges</li>
 - *   <li>Scanning a large range that returns many entries</li>
 - *   <li>Running server-side iterators that perform computation,
 - *   even if few entries are returned from the scan itself</li>
++ * <li>Retrieving many small ranges</li>
++ * <li>Scanning a large range that returns many entries</li>
++ * <li>Running server-side iterators that perform computation, even if few entries
are returned from the scan itself</li>
+  * </ul>
   *
-  * If you want to lookup a few ranges and expect those ranges to contain a lot of data,
then use the Scanner instead. Also, the Scanner will return data in
-  * sorted order, this will not.
 - * To re-emphasize, only use a BatchScanner when you do not care whether returned data is
in sorted order.
 - * Use a {@link Scanner} instead when sorted order is important.
++ * To re-emphasize, only use a BatchScanner when you do not care whether returned data is
in sorted order. Use a {@link Scanner} instead when sorted order is
++ * important.
   *
+  * <p>
 - * A BatchScanner instance will use no more threads than provided in the construction of
the BatchScanner
 - * implementation. Multiple invocations of <code>iterator()</code> will all
share the same resources of the instance.
 - * A new BatchScanner instance should be created to use allocate additional threads.
 + * A BatchScanner instance will use no more threads than provided in the construction of
the BatchScanner implementation. Multiple invocations of
 + * <code>iterator()</code> will all share the same resources of the instance.
A new BatchScanner instance should be created to use allocate additional threads.
   */
 -
  public interface BatchScanner extends ScannerBase {
  
    /**


Mime
View raw message