두 야코즈나 또는 카산드라 대 HBase의 전투. Sberbank 팀 경험

이것은 농담도 아닙니다. 이 특정 그림은 이러한 데이터베이스의 본질을 가장 정확하게 반영하는 것으로 보이며 결국 그 이유는 분명해질 것입니다.

DB-Engines Ranking에 따르면 가장 널리 사용되는 두 가지 NoSQL 컬럼형 데이터베이스는 Cassandra(이하 CS)와 HBase(HB)입니다.

운명의 뜻에 따라 Sberbank의 데이터 로딩 관리 팀은 이미 긴 HB와 긴밀하게 협력하고 있습니다. 그동안 우리는 그것의 장점과 단점을 꽤 잘 연구했고 요리하는 방법도 배웠습니다. 그러나 CS 형태의 대안이 존재하기 때문에 항상 우리는 의심으로 우리 자신을 조금 괴롭게 만들었습니다. 우리가 올바른 선택을 하였습니까? 게다가 결과는 비교, DataStax에서 수행한 결과 CS가 거의 압도적인 점수로 HB를 쉽게 이겼다고 말했습니다. 반면에 DataStax는 이해관계자이므로 그들의 말을 그대로 받아들여서는 안 됩니다. 저희도 테스트 조건에 대한 정보가 너무 적어서 혼란스러워서 누가 BigData NoSql의 왕인지 직접 알아보기로 했고, 얻은 결과는 매우 흥미로웠습니다.

그러나 수행된 테스트 결과로 넘어가기 전에 환경 구성의 중요한 측면을 설명하는 것이 필요합니다. 사실 CS는 데이터 손실이 허용되는 모드에서 사용될 수 있습니다. 저것들. 이는 하나의 서버(노드)만이 특정 키의 데이터를 담당하는 경우이며, 어떤 이유로든 실패하면 이 키의 값이 손실됩니다. 많은 업무에서 이는 중요하지 않지만, 은행 부문에서는 이것이 규칙이라기보다는 예외입니다. 우리의 경우 안정적인 저장을 위해 여러 개의 데이터 복사본을 보유하는 것이 중요합니다.

따라서 삼중 복제 모드에서는 CS 작동 모드만 고려되었습니다. 케이스 공간 생성은 다음 매개변수를 사용하여 수행되었습니다.

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};

다음으로, 필요한 수준의 일관성을 보장하는 두 가지 방법이 있습니다. 일반 규칙:
북서 + NR > RF

이는 쓰기(NW) 시 노드의 확인 수와 읽기(NR) 시 노드의 확인 수를 더한 값이 복제 인자보다 커야 함을 의미합니다. 우리의 경우 RF = 3이며 이는 다음 옵션이 적합함을 의미합니다.
2 + 2> 3
3 + 1> 3

데이터를 가능한 한 안정적으로 저장하는 것이 근본적으로 중요하기 때문에 3+1 방식이 선택되었습니다. 게다가 HB도 비슷한 원리로 작동합니다. 그러한 비교는 더 공정할 것입니다.

DataStax는 연구에서 그 반대를 수행했으며 CS와 HB 모두에 대해 RF = 1로 설정했습니다(후자의 경우 HDFS 설정을 변경하여). 이 경우 CS 성능에 미치는 영향이 크기 때문에 이는 매우 중요한 측면입니다. 예를 들어, 아래 그림은 CS에 데이터를 로드하는 데 필요한 시간의 증가를 보여줍니다.

여기서 우리는 다음을 볼 수 있습니다. 더 많은 경쟁 스레드가 데이터를 쓸수록 시간이 더 오래 걸립니다. 이는 당연하지만 RF=3의 성능 저하가 훨씬 더 높다는 것이 중요합니다. 즉, 4개의 스레드를 각각 5개의 테이블(총 20개)에 쓰면 RF=3은 약 2배(RF=150의 경우 3초, RF=75의 경우 1초) 손실됩니다. 그러나 각각 8개의 스레드(총 5개)가 있는 40개의 테이블에 데이터를 로드하여 로드를 늘리면 RF=3의 손실은 이미 2,7배(375초 대 138)입니다.

아마도 이것은 부분적으로 CS용 DataStax가 수행한 성공적인 로드 테스트의 비결일 것입니다. 왜냐하면 우리 스탠드의 HB에 대해 복제 인자를 2에서 3으로 변경해도 아무런 효과가 없었기 때문입니다. 저것들. 디스크는 우리 구성의 HB 병목 현상이 아닙니다. 그러나 여기에는 다른 많은 함정이 있습니다. 우리 버전의 HB가 약간 패치되고 조정되었으며 환경이 완전히 다르기 때문입니다. CS를 올바르게 준비하는 방법을 모르고 CS를 사용하는 더 효과적인 방법이 있을 수도 있다는 점도 주목할 가치가 있습니다. 댓글에서 알아낼 수 있기를 바랍니다. 하지만 가장 먼저 해야 할 일이 있습니다.

모든 테스트는 각각 다음 구성을 갖춘 4개의 서버로 구성된 하드웨어 클러스터에서 수행되었습니다.

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 스레드.
디스크: SATA HDD 12개
자바 버전: 1.8.0_111

CS 버전: 3.11.5

cassandra.yml 매개변수num_tokens: 256
Hinted_handoff_enabled: 참
Hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
힌트 디렉터리: /data10/cassandra/hints
힌트_플러시_기간_인_ms: 10000
max_hints_file_size_in_mb: 128
Batchlog_replay_throttle_in_kb: 1024
인증자: AllowAllAuthenticator
승인자: AllowAllAuthorizer
role_manager: CassandraRoleManager
Roles_validity_in_ms: 2000
허가_유효성_in_ms: 2000
credential_validity_in_ms: 2000
파티셔너: org.apache.cassandra.dht.Murmur3Partitioner
데이터_파일_디렉터리:
- /data1/cassandra/data # 각 dataN 디렉터리는 별도의 디스크입니다.
- /data2/카산드라/데이터
- /data3/카산드라/데이터
- /data4/카산드라/데이터
- /data5/카산드라/데이터
- /data6/카산드라/데이터
- /data7/카산드라/데이터
- /data8/카산드라/데이터
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: 거짓
disk_failure_policy: 중지
commit_failure_policy: 중지
prepare_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_기간: 14400
row_cache_size_in_mb: 0
row_cache_save_기간: 0
counter_cache_size_in_mb:
counter_cache_save_기간: 7200
save_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: 주기적
commitlog_sync_기간_in_ms: 10000
commitlog_segment_size_in_mb: 32
종자 공급자:
- 클래스 이름: org.apache.cassandra.locator.SimpleSeedProvider
매개 변수 :
— 시드: "*,*"
동시_읽기: 256 # 시도 64 - 차이점이 발견되지 않았습니다.
Concurrent_writes: 256 # 시도 64 - 차이점이 발견되지 않았습니다.
동시_counter_writes: 256 # 시도 64 - 차이점이 발견되지 않았습니다.
Concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16GB를 시도했는데 속도가 느렸습니다.
memtable_allocation_type: 힙_버퍼
index_summary_capacity_in_mb:
index_summary_resize_interval_in_분: 60
trickle_fsync: 거짓
trickle_fsync_interval_in_kb: 10240
스토리지 포트: 7000
SSL_storage_port: 7001
Listen_address: *
방송_주소: *
Listen_on_broadcast_address: 사실
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: 사실
Native_transport_port: 9042
start_rpc: 참
rpc_주소: *
rpc_port: 9160
rpc_keepalive: 참
rpc_server_type: 동기화
thrift_framed_transport_size_in_mb: 15
Incremental_backups: 거짓
snapshot_before_compaction: 거짓
auto_snapshot: 참
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
동시 압축기: 4
Compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
Slow_query_log_timeout_in_ms: 500
cross_node_timeout: 거짓
Endpoint_snitch: 험담하는PropertyFileSnitch
Dynamic_snitch_update_interval_in_ms: 100
Dynamic_snitch_reset_interval_in_ms: 600000
Dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
서버_암호화_옵션:
노드 간 암호화: 없음
클라이언트_암호화_옵션:
사용 : 거짓
internode_compression: dc
inter_dc_tcp_nodelay: 거짓
Tracetype_query_ttl: 86400
Tracetype_repair_ttl: 604800
활성화_사용자_정의_함수: 거짓
활성화_스크립트_사용자_정의_함수: 거짓
windows_timer_interval: 1
transparent_data_encryption_options:
사용 : 거짓
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
배치_크기_warn_threshold_in_kb: 200
Batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
Compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_press_enabled: 거짓
활성화_materialized_views: true
활성화_sasi_indexes: true

GC 설정:

### CMS 설정-XX:+ParNewGC 사용
-XX:+ConcMarkSweepGC 사용
-XX:+CMSParallelRemarkEnabled
-XX:생존자 비율=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+CMMSInitiatingOccupancyOnly 사용
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

jvm.options 메모리에는 16Gb가 할당되었습니다(32Gb도 시도했지만 차이는 발견되지 않았습니다).

테이블은 다음 명령으로 생성되었습니다.

CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};

HB 버전: 1.2.0-cdh5.14.2(org.apache.hadoop.hbase.regionserver.HRegion 클래스에서 RegionServer에서 지역 수가 1000개를 초과할 때 GC로 이어지는 MetricsRegion을 제외했습니다.)

기본값이 아닌 HBase 매개변수사육사.session.timeout: 120000
hbase.rpc.timeout: 2분
hbase.client.scanner.timeout.기간: 2분
hbase.master.handler.count: 10
hbase.regionserver.lease.기간, hbase.client.scanner.timeout.기간: 2분
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.기간: 4시간
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1일
hbase-site.xml용 HBase 서비스 고급 구성 조각(안전 밸브):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.ionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer에 대한 Java 구성 옵션:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2분
hbase.snapshot.region.timeout: 2분
hbase.snapshot.master.timeout.millis: 2분
HBase REST 서버 최대 로그 크기: 100MiB
HBase REST 서버 최대 로그 파일 백업: 5
HBase Thrift 서버 최대 로그 크기: 100MiB
HBase Thrift 서버 최대 로그 파일 백업: 5
마스터 최대 로그 크기: 100MiB
마스터 최대 로그 파일 백업: 5
RegionServer 최대 로그 크기: 100MiB
RegionServer 최대 로그 파일 백업: 5
HBase 활성 마스터 감지 기간: 4분
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10밀리초
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
최대 프로세스 파일 설명자: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads: 30
hbase.master.executor.closeregion.threads: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.size: 20
지역 이동 스레드: 6
클라이언트 Java 힙 크기(바이트): 1GiB
HBase REST 서버 기본 그룹: 3GiB
HBase Thrift 서버 기본 그룹: 3GiB
HBase 마스터의 Java 힙 크기(바이트): 16GiB
HBase RegionServer의 Java 힙 크기(바이트): 32GiB

+동물원 사육사
maxClientCnxns: 601
maxSessionTimeout: 120000
테이블 생성:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 균일 분할 -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

여기에는 한 가지 중요한 점이 있습니다. DataStax 설명에는 HB 테이블을 생성하는 데 사용된 영역 수는 나와 있지 않지만 이는 대용량의 경우 매우 중요합니다. 따라서 테스트를 위해 최대 64GB까지 저장할 수 있는 수량 = 640가 선택되었습니다. 중간 크기의 테이블.

테스트 당시 HBase에는 22개의 테이블과 67개의 지역이 있었습니다(위에서 언급한 패치가 아니었다면 버전 1.2.0에서는 치명적이었을 것입니다).

이제 코드입니다. 특정 데이터베이스에 대해 어떤 구성이 더 유리한지 명확하지 않았기 때문에 다양한 조합으로 테스트가 수행되었습니다. 저것들. 일부 테스트에서는 4개의 테이블이 동시에 로드되었습니다(4개의 노드가 모두 연결에 사용되었습니다). 다른 테스트에서는 8개의 서로 다른 테이블을 사용하여 작업했습니다. 배치 크기가 100인 경우도 있었고, 200인 경우도 있었습니다(배치 매개변수 - 아래 코드 참조). value의 데이터 크기는 10바이트 또는 100바이트(dataSize)입니다. 매번 총 5만 개의 레코드가 각 테이블에 기록되고 읽혀졌습니다. 동시에 5개의 스레드가 각 테이블에 쓰거나 읽혔으며(스레드 번호 - thNum), 각 스레드는 자체 키 범위(개수 = 1만)를 사용했습니다.

if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("BEGIN BATCH ");
        for (int i = 0; i < batch; i++) {
            String value = RandomStringUtils.random(dataSize, true, true);
            sb.append("INSERT INTO ")
                    .append(tableName)
                    .append("(id, title) ")
                    .append("VALUES (")
                    .append(key)
                    .append(", '")
                    .append(value)
                    .append("');");
            key++;
        }
        sb.append("APPLY BATCH;");
        final String query = sb.toString();
        session.execute(query);
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("SELECT * FROM ").append(tableName).append(" WHERE id IN (");
        for (int i = 0; i < batch; i++) {
            sb = sb.append(key);
            if (i+1 < batch)
                sb.append(",");
            key++;
        }
        sb = sb.append(");");
        final String query = sb.toString();
        ResultSet rs = session.execute(query);
    }
}

따라서 HB에도 유사한 기능이 제공되었습니다.

Configuration conf = getConf();
HTable table = new HTable(conf, keyspace + ":" + tableName);
table.setAutoFlush(false, false);
List<Get> lGet = new ArrayList<>();
List<Put> lPut = new ArrayList<>();
byte[] cf = Bytes.toBytes("cf");
byte[] qf = Bytes.toBytes("value");
if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lPut.clear();
        for (int i = 0; i < batch; i++) {
            Put p = new Put(makeHbaseRowKey(key));
            String value = RandomStringUtils.random(dataSize, true, true);
            p.addColumn(cf, qf, value.getBytes());
            lPut.add(p);
            key++;
        }
        table.put(lPut);
        table.flushCommits();
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lGet.clear();
        for (int i = 0; i < batch; i++) {
            Get g = new Get(makeHbaseRowKey(key));
            lGet.add(g);
            key++;
        }
        Result[] rs = table.get(lGet);
    }
}

HB에서는 클라이언트가 데이터의 균일한 분포를 관리해야 하므로 주요 솔팅 기능은 다음과 같습니다.

public static byte[] makeHbaseRowKey(long key) {
    byte[] nonSaltedRowKey = Bytes.toBytes(key);
    CRC32 crc32 = new CRC32();
    crc32.update(nonSaltedRowKey);
    long crc32Value = crc32.getValue();
    byte[] salt = Arrays.copyOfRange(Bytes.toBytes(crc32Value), 5, 7);
    return ArrayUtils.addAll(salt, nonSaltedRowKey);
}

이제 가장 흥미로운 부분은 결과입니다.

그래프 형식에서도 마찬가지입니다.

HB의 장점은 너무 놀라워서 CS 설정에 일종의 병목 현상이 있다는 의혹이 있습니다. 그러나 인터넷 검색과 가장 확실한 매개변수(concurrent_writes 또는 memtable_heap_space_in_mb 등)를 검색해도 속도가 빨라지지 않았습니다. 동시에 통나무는 깨끗하고 아무것도 맹세하지 않습니다.

데이터는 노드 전체에 고르게 분산되었으며 모든 노드의 통계는 거의 동일했습니다.

다음은 노드 중 하나의 테이블 통계입니다.키스페이스: ks
읽기 횟수: 9383707
읽기 지연 시간: 0.04287025042448576ms
쓰기 횟수: 15462012
쓰기 지연 시간: 0.1350068438699957ms
보류 중인 플러시: 0
테이블: t1
SS테이블 수: 16
사용된 공간(라이브): 148.59MiB
사용된 공간(총): 148.59MiB
스냅샷에 사용된 공간(총계): 0바이트
사용된 오프 힙 메모리(총계): 5.17MiB
SSTable 압축 비율: 0.5720989576459437
파티션 수(추정): 3970323
메모리 가능한 셀 수: 0
메모리 테이블 크기: 0바이트
사용된 메모리 오프 힙 메모리: 0바이트
메모리 가능한 스위치 수: 5
로컬 읽기 횟수: 2346045
로컬 읽기 대기 시간: NaN ms
로컬 쓰기 횟수: 3865503
로컬 쓰기 대기 시간: NaN ms
보류 중인 플러시: 0
수리된 비율: 0.0
블룸 필터 오탐: 25
블룸 필터 거짓 비율: 0.00000
사용된 블룸 필터 공간: 4.57MiB
사용된 블룸 필터 오프 힙 메모리: 4.57MiB
사용된 힙 메모리에 대한 인덱스 요약: 590.02 KiB
사용된 힙 메모리의 압축 메타데이터: 19.45KiB
압축된 파티션 최소 바이트: 36
압축된 파티션 최대 바이트: 42
압축된 파티션 평균 바이트: 42
슬라이스당 평균 살아있는 세포(마지막 XNUMX분): NaN
슬라이스당 최대 라이브 셀(지난 0분): XNUMX
조각당 평균 삭제 표시(지난 XNUMX분): NaN
조각당 최대 삭제 표시(지난 0분): XNUMX
삭제된 돌연변이: 0바이트

배치 크기를 줄이려는 시도(개별적으로 전송하는 경우에도)는 효과가 없었고 상황은 더욱 악화되었습니다. 실제로 이것은 CS의 최대 성능일 가능성이 있습니다. 왜냐하면 CS에 대해 얻은 결과는 DataStax에서 얻은 결과와 유사하기 때문입니다(초당 약 수십만 개의 작업). 또한 리소스 활용도를 살펴보면 CS가 훨씬 더 많은 CPU와 디스크를 사용한다는 것을 알 수 있습니다.

그림은 두 데이터베이스에 대해 연속으로 모든 테스트를 실행하는 동안의 활용도를 보여줍니다.

HB의 강력한 독서 이점에 대해. 여기서 두 데이터베이스 모두 읽기 중 디스크 활용도가 매우 낮다는 것을 알 수 있습니다. 읽기 테스트는 각 데이터베이스에 대한 테스트 주기의 마지막 부분입니다. 예를 들어 CS의 경우 15:20부터 15:40까지입니다. HB의 경우 이유는 분명합니다. 대부분의 데이터가 메모리, memstore에 정지되고 일부는 블록 캐시에 캐시됩니다. CS의 경우 어떻게 작동하는지 명확하지 않지만 디스크 재활용도 보이지 않지만 혹시라도 캐시 row_cache_size_in_mb = 2048을 활성화하고 캐싱 = {'keys': 'ALL'을 설정하려고 시도했습니다. 'rows_per_partition': ' 2000000'}, 하지만 이로 인해 상황이 더욱 악화되었습니다.

HB의 지역 수에 관한 중요한 점을 다시 한 번 언급할 가치가 있습니다. 우리의 경우 값은 64로 지정되었습니다. 이를 줄여서 예를 들어 4와 같게 만들면 읽을 때 속도가 2배로 떨어집니다. 그 이유는 memstore가 더 빨리 채워지고 파일이 더 자주 플러시되며 읽을 때 더 많은 파일을 처리해야 하기 때문입니다. 이는 HB의 경우 다소 복잡한 작업입니다. 실제 상황에서는 사전 분할 및 압축 전략을 통해 이를 처리할 수 있으며, 특히 백그라운드에서 지속적으로 가비지를 수집하고 HFiles를 압축하는 자체 작성 유틸리티를 사용합니다. DataStax 테스트의 경우 테이블당 1개의 영역만 할당했을 가능성이 있으며(올바르지 않음) 이는 HB가 읽기 테스트에서 그토록 열등한 이유를 어느 정도 명확하게 해줍니다.

이것으로부터 다음과 같은 예비 결론이 도출된다. 테스트 중에 큰 실수가 없었다고 가정하면 Cassandra는 점토 발을 가진 거인처럼 보입니다. 좀 더 정확히 말하자면, 기사 앞부분의 사진처럼 한쪽 다리로 균형을 잡고 있는 동안 비교적 좋은 결과를 보여주지만, 같은 조건에서의 싸움에서는 완전히 패배한다. 동시에 하드웨어의 낮은 CPU 사용률을 고려하여 호스트당 XNUMX개의 RegionServer HB를 설치하여 성능을 두 배로 높이는 방법을 배웠습니다. 저것들. 자원 활용을 고려하면 CS의 상황은 더욱 안타깝다.

물론 이러한 테스트는 상당히 종합적이며 여기에 사용된 데이터의 양은 상대적으로 적습니다. 테라바이트로 전환하면 상황이 달라질 수 있지만 HB에서는 테라바이트를 로드할 수 있지만 CS에서는 이것이 문제가 되는 것으로 나타났습니다. 응답을 기다리는 매개변수가 이미 기본 매개변수에 비해 여러 배 증가했음에도 불구하고 이러한 볼륨에서도 종종 OperationTimedOutException이 발생했습니다.

공동의 노력을 통해 CS의 병목 현상을 찾아내고 속도를 높일 수 있다면 게시물 마지막에 최종 결과에 대한 정보를 반드시 추가하겠습니다.

UPD: 동료들의 조언 덕분에 읽는 속도를 높일 수 있었습니다. 였다:
159개의 작업(테이블 644개, 스트림 4개, 배치 5).
작성자 :
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
그리고 나는 스레드 수를 가지고 놀았습니다. 결과는 다음과 같습니다.
테이블 4개, 스레드 100개, 배치 = 1(개별): 301 ops
테이블 4개, 스레드 100개, 배치 = 10: 447 작업
테이블 4개, 스레드 100개, 배치 = 100: 625 작업

나중에 다른 튜닝 팁을 적용하고 전체 테스트 주기를 실행한 후 게시물 끝에 결과를 추가하겠습니다.

출처 : habr.com