[
https://issues.apache.org/jira/browse/KAFKA-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350117#comment-17350117
]
Sagar Rao edited comment on KAFKA-8295 at 5/23/21, 6:54 PM:
------------------------------------------------------------
[~ableegoldman], So, I extended the rocksjava benchmarking code available on
github([https://github.com/facebook/rocksdb/wiki/RocksJava-Performance-on-Flash-Storage)]
and added a MergeRandomTask to it. The operator that I have benchmarked is
UInt64AddOperator. Here is the benchmarking task that I added:
[https://github.com/vamossagar12/rocksdb/blob/master/java/benchmark/src/main/java/org/rocksdb/benchmark/DbBenchmark.java#L310-L346]
(hope you can view my forked repo?)
This is how plugged in the mergeOperator:
[https://github.com/vamossagar12/rocksdb/blob/master/java/benchmark/src/main/java/org/rocksdb/benchmark/DbBenchmark.java#L645-L656]
I ran the tests on the following machine config:
*32 core, 256 GB RAM*
*Centos: 7.7*
*DB created on Disk attached to the VM. Azure IOPS2 Volume Type => 7000.*
Here are the config parameters passed:
*bpl=10485760;overlap=10;mcz=2;del=300000000;levels=6;ctrig=4; delay=8;
stop=12; mbc=20; r=50000000; t=10; vs=8; bs=65536; si=1000000; time
./jdb_bench.sh --benchmarks=mergerandom --merge_operator=uint64add
--mmap_read=0 --statistics=1 --histogram=1 --num=$r --threads=$t
--value_size=$vs --block_size=$bs --db=/data/sdb --disable_wal=1
--stats_interval=$si --max_background_compactions=$mbc
--level0_file_num_compaction_trigger=$ctrig
--level0_slowdown_writes_trigger=$delay --level0_stop_writes_trigger=$stop
--num_levels=$levels --delete_obsolete_files_period_micros=$del
--min_level_to_compress=$mcz --stats_per_interval=1
--max_bytes_for_level_base=$bpl*
The configs above, i picked from the rocksdb cpp merge operator benchmarking
page from here:
[https://github.com/facebook/rocksdb/wiki/Read-Modify-Write-Benchmarks]
Note that, snappy compression didn't work as i couldn't link the library. i
dont think that should be a deterrent anyways for the benchmarking. Finally,
here are the numbers that I got:
####################################################################
*Running benchmark in 64-Bit mode.*
*Unable to load snappy library:java.lang.UnsatisfiedLinkError: no snappy in
java.library.path*
*No compression is used.*
*Using database directory: /data/sdb*
*Keys: 16 bytes each*
*Values: 8 bytes each (4 bytes after compression)*
*Entries: 50000000*
*RawSize: 1144.4 MB (estimated)*
*FileSize: 953.7 MB (estimated)*
*Memtable Factory: SkipListFactory*
*Prefix: 0 bytes*
*Compression: none*
*------------------------------------------------*
*mergerandom : 5.17497 micros/op; 4.4 MB/s; 50000000 ops done; 1 /
1 task(s) finished.*
**
*real 4m19.249s*
*user 16m18.119s*
*sys 0m17.834s*
####################################################################
What do you make of these numbers? Wanted to understand any particular numbers
that are traditionally looked at in the Kafka streams landscape to be able to
decide? Or any particular configs?
I should be able to factor those in and republish the numbers. Plz let me know.
We can then decide later on based upon your feedback if the operator is worthy
of a KIP or not.
was (Author: sagarrao):
[~ableegoldman], So, I extended the rocksjava benchmarking code available on
github([https://github.com/facebook/rocksdb/wiki/RocksJava-Performance-on-Flash-Storage)]
and added a MergeRandomTask to it. The operator that I have benchmarked is
UInt64AddOperator. Here is the benchmarking task that I added:
[https://github.com/vamossagar12/rocksdb/blob/master/java/benchmark/src/main/java/org/rocksdb/benchmark/DbBenchmark.java#L310-L346]
(hope you can view my forked repo?)
This is how plugged in the mergeOperator:
[https://github.com/vamossagar12/rocksdb/blob/master/java/benchmark/src/main/java/org/rocksdb/benchmark/DbBenchmark.java#L645-L656]
I ran the tests on the following machine config:
*32 core, 256 GB RAM*
*Centos: 7.7*
*DB created on Disk attached to the VM. Azure IOPS2 Volume Type => 7000.*
Here are the config parameters passed:
*bpl=10485760;overlap=10;mcz=2;del=300000000;levels=6;ctrig=4; delay=8;
stop=12; mbc=20; r=50000000; t=10; vs=8; bs=65536; si=1000000; time
./jdb_bench.sh --benchmarks=mergerandom --merge_operator=uint64add
--mmap_read=0 --statistics=1 --histogram=1 --num=$r --threads=$t
--value_size=$vs --block_size=$bs --db=/data/sdb --disable_wal=1
--stats_interval=$si --max_background_compactions=$mbc
--level0_file_num_compaction_trigger=$ctrig
--level0_slowdown_writes_trigger=$delay --level0_stop_writes_trigger=$stop
--num_levels=$levels --delete_obsolete_files_period_micros=$del
--min_level_to_compress=$mcz --stats_per_interval=1
--max_bytes_for_level_base=$bpl*
The configs above, i picked from the rocksdb cpp merge operator benchmarking
page from here:
https://github.com/facebook/rocksdb/wiki/Read-Modify-Write-Benchmarks
Note that, snappy compression didn't work as i couldn't link the library. i
dont think that should be a deterrent anyways for the benchmarking. Finally,
here are the numbers that I got:
####################################################################
*Running benchmark in 64-Bit mode.*
*Unable to load snappy library:java.lang.UnsatisfiedLinkError: no snappy in
java.library.path*
*No compression is used.*
*Using database directory: /data/sdb*
*Keys: 16 bytes each*
*Values: 8 bytes each (4 bytes after compression)*
*Entries: 50000000*
*RawSize: 1144.4 MB (estimated)*
*FileSize: 953.7 MB (estimated)*
*Memtable Factory: SkipListFactory*
*Prefix: 0 bytes*
*Compression: none*
*------------------------------------------------*
*mergerandom : 5.17497 micros/op; 4.4 MB/s; 50000000 ops done; 1 /
1 task(s) finished.*
**
*real 4m19.249s*
*user 16m18.119s*
*sys 0m17.834s*
####################################################################
What do you make of these numbers? Wanted to understand any particular numbers
that are traditionally looked at in the Kafka streams landscape to be able to
decide? Or any particular configs?
I should be able to factor those in and republish the numbers. Plz let me know.
> Optimize count() using RocksDB merge operator
> ---------------------------------------------
>
> Key: KAFKA-8295
> URL: https://issues.apache.org/jira/browse/KAFKA-8295
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: A. Sophie Blee-Goldman
> Assignee: Sagar Rao
> Priority: Major
>
> In addition to regular put/get/delete RocksDB provides a fourth operation,
> merge. This essentially provides an optimized read/update/write path in a
> single operation. One of the built-in (C++) merge operators exposed over the
> Java API is a counter. We should be able to leverage this for a more
> efficient implementation of count()
>
> (Note: Unfortunately it seems unlikely we can use this to optimize general
> aggregations, even if RocksJava allowed for a custom merge operator, unless
> we provide a way for the user to specify and connect a C++ implemented
> aggregator – otherwise we incur too much cost crossing the jni for a net
> performance benefit)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
