accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: HDFS vs Accumulo Performance
Date Mon, 05 Dec 2016 16:59:29 GMT
If you're only ever doing sequential scans, IMO, it's expected that HDFS 
would be faster. Remember that, architecturally, Accumulo is designed 
for *random-read/write* workloads. This is where it would shine in 
comparison to HDFS. Accumulo is always going to have a hit in sequential 
read/write workloads over HDFS.

As to your question about the number of seeks, try playing with the 
value of "table.scan.max.memory" [1]. You should be able to easily 
twiddle the value in the Accumulo shell and re-run the test. Accumulo 
tears down these active scans because it expects that your client would 
be taking time to process the results it just sent and it would want to 
not hold onto those in memory (as your client may not come back). 
Increasing that property will increase the amount of data sent in one 
RPC which in turn will reduce the number of RPCs and seeks. Aside: I 
think this server-side "scanner" lifetime is something that'd we want to 
revisit sooner than later.

25MB/s seems like a pretty reasonable a read rate for one TabletServer 
(since you only have one tablet). Similarly, why a BatchScanner would 
have made no difference. BatchScanners parallelize access to multiple 
Tablets and would have nothing but overhead when you read from a single 
Tablet.

[1] 
http://accumulo.apache.org/1.7/accumulo_user_manual.html#_table_scan_max_memory

Mario Pastorelli wrote:
> We are trying to understand Accumulo performance to better plan our
> future products that use it and we noticed that the read speed of
> Accumulo tends to be way lower than what we would expect. We have a
> testing cluster with 4 HDFS+Accumulo nodes and we ran some tests. We
> wrote two programs to write to HDFS and Accumulo and two programs to
> read/scan from HDFS and Accumulo the same number of records containing
> random bytes. We run all the programs from outside the cluster, on
> another node of the rack that doesn’t have HDFS nor Accumulo.
>
> We also wrote all the HDFS blocks and Accumulo tablets on the same
> machine of the cluster.
>
>
> First of all, we wrote 10M entries to HDFS were each entry was 50 bytes
> each. This resulted in 4 blocks on HDFS. Reading this records with a
> FSDataInputStream takes around 5.7 seconds with an average speed of
> around 90MB per second.
>
>
> Then we wrote 10M entries to HDFS where each entry has a row of 50
> random bytes, no column and no value. Writing is as fast as writing to
> HDFS modulo the compaction that we run at the end. The generated table
> has 1 tablet and obviously 10M records all on the same cluster. We
> waited for the compaction to finish, then we opened a scanner without
> setting the range and we read all the records. This time, reading the
> data took around 20 seconds with average speed of 25MB/s and 500000
> records/s together with ~500 seeks/s. We have two questions about this
> result:
>
>
> 1 - is this kind of performance expected?
>
> 2 - Is there any configuration that we can change to improve the scan speed?
>
> 3 - why there are 500 seeks if there is only one tablet and we read
> sequentially all its bytes? What are those seeks doing?
>
>
> We tried to use a BatchScanner with 1, 5 and 10 threads but the speed
> was the same or even worse in some cases.
>
>
> I can provide the code that we used as well as information about our
> cluster configuration if you want.
>
> Thanks,
>
> Mario
>
> --
> Mario Pastorelli| TERALYTICS
>
> *software engineer*
>
> Teralytics AG | Zollstrasse 62 | 8005 Zurich | Switzerland
> phone:+41794381682
> email: mario.pastorelli@teralytics.ch
> <mailto:mario.pastorelli@teralytics.ch>
> www.teralytics.net <http://www.teralytics.net/>
>
> Company registration number: CH-020.3.037.709-7 | Trade register Canton
> Zurich
> Board of directors: Georg Polzer, Luciano Franceschina, Mark Schmitz,
> Yann de Vries
>
> This e-mail message contains confidential information which is for the
> sole attention and use of the intended recipient. Please notify us at
> once if you think that it may not be intended for you and delete it
> immediately.
>

Mime
View raw message