APSARADB for HBase performance/latency Full Lead Community Version _ database

Source: Internet
Author: User
Tags flush aliyun

Original address


HBase Test Report

This article will introduce the details of our tests for Aliyun HBase and HBase1.1.12, and will probably introduce the environment of the test, the test tool analysis and our selection of tools, the case of the test, and the analysis of the results of the test. 1. Test environment

1.1. Physical environment:

Service end: Single regionserver:8core,32g,4x250g SSD

Client:16core 64G, double Client pressure;

1.2. Software Environment:

client:hbase-1.1.2

SERVER:APSARADB for HBase, HBase1.1.12

jdk:ali-jdk-1.8

1.3. Test conditions:

2 Client Pressure server side, full server performance, server side is a single regionserver. Write operation 500w Data, a total of 10 million data, scan, read separate single-threaded operation 5k,5w data. Operation of a single value size of 1000B (1KB) 2. Test Step 2.1. Test Tool Analysis:

Test tools have been in the YCSB and hbase from the tool performanceevaluation the choice between the two, here probably introduced the difference between the two;

Introduction of 2.2.1.YCSB Tool principle and usage method

YCSB is the test platform developed by Yahoo, the main advantage is to compare the performance of each platform, he has the mainstream database test interface, including Mongodb,hbase,cassandra, and so on, using YCSB test HBase, when the basic environment of the test is ready, There are probably a few files below our YCSB Client folder:

[ycsb-hbase10-binding-0.12.0-snapshot]# ll-l
total dosage
drwxr-xr-x 2 root root   4096 September   5 11:38 bin
Drwxr-xr-x 2 root   4096 September   5 09:54 conf
drwxr-xr-x 2 root root   4096 September   4 22:26 lib
-rw-r--r-- 1  501 Games  8082 November  9 2016 LICENSE.txt
-rw-r--r--1 root root  15489 September   5 09:56 Longtimete St
-rw-r--r--1  501 Games   615 November  9 2016 NOTICE.txt
-rw-r--r--1  501 Games  5484 November  9 2016 readme.md
drwxr-xr-x 2  501 Games  4096 September   5 11:40 workloads

The above Conf folder is not originally, but here is the need to add the corresponding Conf folder, here, In the Conf folder is the need to put the Hbase-site.xml configuration file, or the best configuration file and server-side configuration file, if not the same at least to ensure that ZK's address is the same.

Each of the relevant test parameters required in the workloads is explained by the following 2 actual cases to explain the parameters of the test:

1.BIN/YCSB load  hbase10-p workloads/workloads  -P table=usertable-p columnfamily=cf-p  -P fieldlength=50- P fieldcount=1-s Threads
2.BIN/YCSB run  hbase10-p workloads/workloada-p table=usertable-p COLUMNFAMILY=CF- P fieldlength=1000-p fieldcount=1  -s-threads 50
[root@ ycsb-hbase10-binding-0.12.0-snapshot]# cat Workloads/workloada
recordcount=1000
operationcount= 1000
workload=com.yahoo.ycsb.workloads.coreworkload

readallfields=true

readproportion=0.5
updateproportion=0.5
scanproportion=0
insertproportion=0

Requestdistribution=zipfian

In the case above, (1) is the use of YCSB load-related information data to the HBase database, in fact, is to write part of the data into the HBase, after-p is generally followed by the attribute information, including table is usertable, Columnfamily is CF, the length of the file written is 50B, written to 1 files, that is, a column. The boot thread is 50 threads doing something like this; how much data to write altogether. In workloads/workloads this file will have a RecordCount, which represents the total number of writes written, of course, this parameter can also be transmitted at the command line;

(2) is to start the run operation, the type of run operation is mainly to see the Workload/workloada inside the "Readproportion", "Updateproportion", "Scanproportion", " Insertproportion "The proportion of occupancy, such as Insertproportion=1, that is written, if insertproportion=0.5,readproportion=0.5 is then read and write each 50%, In the same time, the configuration file will have a operationcount, indicating the number of operations required, which accounted for 50% of the number of reads and writes.

Requestdistribution represents the distribution type of the request, whether it is similar to a positive distribution, a 2/8 request distribution, or a different distribution. The Zipfian above represents 2/8 distributions.

In addition, YCSB also has a lot of parameters related to hbase configuration, such as: Write the time of the writebuffersize, read when there are setblockcache.
Introduction to the principle of 2.2.2.HBase performanceevaluation tool and its Application method

HBase performanceevaluation This tool is HBase, and the test case and the interface provided to the outside world are richer than the YCSB, for example: Randomwrite,sequencewrite,scan, Randomseekscan,scanrange10, scanRange100 and so on. The most intuitive CASE,YCSB of the intuitive scan case is not as rich as the above PE. The tools we use to test in this article are mainly hbase performance tools. We use the actual case of several tests to illustrate the usage and the corresponding principle:

 1.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation--nomapred--writetowal=false--table=xxx--rows=50000 Randomwrite 2.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation--nomapred--writetowal=false--table=xxx-- rows=50000 sequentialwrite 3.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation--nomapred--writetowal=true- -table=xxx--rows=50000 randomwrite 4.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation--nomapred-- Writetowal=true--table=xxx--rows=50000 sequentialwrite 5.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation-- nomapred--table=xxx--rows=50000 randomread 6.sh hbase org.apache.hadoop.hbase.PerformanceEvaluation--nomapred-- Table=xxx--rows=5000--caching=100 scanRange100

First to introduce the usage, the above 1-6 case we see the relevant parameters, Nomapred,writetowal, table, rows and each randomwrite,sequentialwrite,scanrange100, etc. ; The following table describes usage: parameter meaning nommapred default to use the local boot MapReduce method test, if this parameter indicates the use of a local boot thread, a non-Mr method to test the table name rows because the PE local boot multithreading mode is, Each thread needs to operate a certain number of keys, here followed by the number of key operations, the default is 1024*1024 startrow each thread operation key starting key, the default is 0; Of course, here's the key, actually to the final operation of the row key a little different, the following will say Compression table on the data compression strategy (Lzo,gz,snappy,lz4,zstd,none several strategies), is in the server side of the table does not, this parameter is meaningful, default is not compressed blockencoding table data Block's encoding strategy: NONE; PREFIX; DIFF; Fast_diff; Prefix_tree, the default none Writetowal write Hlog strategy, there are: Sync_wal and Skip_wal 2 kinds, but here we have added a new way of Async_wal in the test, marking the asynchronous flush WAL ; Here the original true flag Sync_wal,false flag Skip, we change to False flag bit Async_wal mode; multiget flag get multiple, get multiple required data at server end, then return; default is 0 ; a single get unaffected columns indicates how many columns, default is 1, we use the default case caching to indicate how much data is in the server cache, and then pull back at once; scan     Randomwrite It said that each thread sent the corresponding data amount of data, from the StartRow start to the end of the number of bars, each row key with a total of operations rows randomly out a number, row total number of threads *rows;row key 26byte Sequentialwrite The row key here starts with the star row, and this data is relevant, in order key RandomreadRead the key is Randowrite, with randomness scan given the specified start row, start scan, but it seems like the code is read only the first key to return, it should be a bug, we have changed, and the start row should be read each time need to change Randomseekscan compared to the above scan, each read of the star row is random, and here is the final data to be read; ScanRange10 randomly designated range of Scan,scan key between the start and end is 10 SCANRANG100 is 100, and so on.

The general principle of PE is: Client boot thread pool, thread pool of the upper threads is how many threads we pass the parameters, that is, the last 100 of each case. Then a number of threads are started, each thread concurrently performs the read/write/scan of rows, and of course the types of operations are different.

PE only statistics the entire process down to consume the average time and each thread's delay and so on information, does not have the statistic unit time this server processing RPS (request per second), our side modifies the code, the statistic this data, probably the idea is very simple, Is the count of all the operations recorded in parallel operation of all threads divided by the average time TS, which is the sever processing request per second; 2.2. Test Case: Write operation flag write operation type SW1 order Batch100,async_wal SW2 Order Batch100 , Sync_wal SW3 sequence Batch2, Async_wal sw4 sequence batch 2,sync_wal sw5 sequence write a, Async_wal SW6 sequence write a, Sync_wal rw1 random Batch100,async_wal R W2 Random Batch 100,sync_wal rw3 random batch 2,async_wal rw4 random Batch2,sync_wal rw5 random write one, Async_wal rw6 random write one, Sync_wal read operation sign read operation NR1 No cache hit, random read a NR2 no cache hit, scan100 YR1 cache hit nearly 100%, random read a yr2 cache hit near 100%,scan100 strip

Here explain the meaning of the above test case: sequential/random means: whether the law of the write row key is random or has sequential characteristics; Batch 100, 2 is the number of keys that are submitted to the server at a time. Async_wal/sync_wal means that each write operation, the server for the WAL log processing is asynchronous flush to the file system, or synchronous flush to the file system. No hit cache and hit cache mainly refers to this read/scan request whether there is a hit cahce.

To better compare the data, most of our two versions use the default parameters, such as the Blockcache use Lrucache,size is the default size. Our table does not turn on compression, our minor compaction thresholds do not change, and so on. Of course, these detailed parameter settings we will later have a separate article to introduce, tuning related. 2.3. Test methods

For write operations: by setting Writewal You can set how the write time operates write-ahead-logging. For a random or sequential setting key, the main is PE own this interface.

For read operations: whether there is cache hit, without Cahce, by setting a single table Blockcache option is true,false, the test sheet needs to modify the table's properties inside the cache or not to set whether to open cache; Cache hit rate is improved by reading many times, in the monitoring of the cache hit rate to make judgments. When observed in monitoring the phenomenon is CAHCE free size is large enough, and the cache hint percent is 0/nearly 100% of the scene, take the desired test results.

In addition, we tested with 2 client, 2 client is the same AZ, why use 2client, because the single client found the CPU easy to fill, this time the more threads for client and stress testing is not good, We use 2 client to test separately, found each 100 threads, sever performance is relatively good, in some scenarios can be the server's cpu/disk squeeze is relatively good; In addition, individuals think that single client Multithreading and multiple-client effects are not very different in distributed scenarios. 3. Test results 3.1. Column Chart of test results

The following gives a random write, sequential write and random read, scan 100 data in each background performance situation, the main output data has 3 dimensions: RPS (single second request requests), all requests average delay, 99 delay; PE is a multi-threaded request, The output data gives the 99 delay of each thread, we randomly sampled several threads of 99 delay data, where the main output of the information is concentrated in RPS and average latency, where the average latency is multiple threads concurrent request sever processing data after the average time of each thread. In addition there is a place to pay attention to, for scan words, a scan100, all our final statistics RPS is in the statistical number of good to 100 as the approximate RPS; but scan the following delay is each time the request delay, for the get/ Write request this delay does not have any effect, simple to scan operation make a comment; In addition cache hit also can not guarantee 100%, just through many times to read, reach the cache hit the possibility, so the above write is the hit rate of nearly 100%.

3.1.1 Random Write

From the results of the data, random write case, BATCH 2 performance and community comparison is good, performance has more than 30% of the upgrade, in this case, the network consumption will not be a lot, in addition, and will not like a single write like the consumption of disk performance.

3.1.2 Sequential Write

3.1.3. Read/scan operation


Scan when the hit rate is affected by the size of the cache and scan of the number of bars, where the default blockcachesize,scan100 bar data, where some data will request the possibility of file system, here need to explain.

The above figure distribution shows our test data for Aliyun HBase and HBase1.1.12, and we can see from the data that Aliyun HBase reads, writes, The performance of the scan scenario is much higher than that of the Community HBase (1.1.12), with performance exceeding 30% in most scenarios, or even more than 100% in some scenarios, and reading, writing, and scan of delayed data to see Aliyun hbase read/write/ Scan delay is generally faster than community hbase, and some scenes are nearly 1 time times faster. From the test performance above, Aliyun hbase performance is very good. In addition, the above test is a single RS under the reading and writing scan, the overall performance has linear expansion capability.

In addition, we are also testing the performance of APSARADB for HBase and HBase1.2.6, followed by a test report and detailed data for both.

Original address


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.