Бұл тіпті әзіл емес, бұл нақты сурет осы дерекқорлардың мәнін дәл көрсететін сияқты және соңында неге екені белгілі болады:
DB-Engines Ranking мәліметтері бойынша NoSQL ең танымал екі бағаналы деректер базасы Cassandra (бұдан әрі CS) және HBase (HB) болып табылады.
Тағдырдың қалауымен Сбербанктегі деректерді жүктеуді басқару командасы қазірдің өзінде бар және HB-мен тығыз жұмыс істейді. Осы уақыт ішінде біз оның күшті және әлсіз жақтарын жақсы зерттеп, оны дайындауды үйрендік. Дегенмен, CS түріндегі баламаның болуы бізді әрқашан күмәнмен аздап қинауға мәжбүр етті: біз дұрыс таңдау жасадық па? Оның үстіне нәтижелер , DataStax орындаған, олар CS оңай дерлік ұсақтау ұпай HB жеңеді деді. Екінші жағынан, DataStax мүдделі тарап болып табылады және сіз бұл үшін олардың сөзін қабылдамауыңыз керек. Сондай-ақ тестілеу шарттары туралы ақпараттың өте аз мөлшері бізді шатастырды, сондықтан біз BigData NoSql патшасы кім екенін өз бетімізше білуге шешім қабылдадық және алынған нәтижелер өте қызықты болды.
Дегенмен, орындалған сынақтардың нәтижелеріне көшпес бұрын, қоршаған орта конфигурацияларының маңызды аспектілерін сипаттау қажет. Өйткені, CS деректерді жоғалтуға мүмкіндік беретін режимде қолданылуы мүмкін. Анау. бұл белгілі бір кілттің деректері үшін тек бір сервер (түйін) жауапты болған кезде және қандай да бір себептермен ол сәтсіз болса, онда бұл кілттің мәні жоғалады. Көптеген міндеттер үшін бұл маңызды емес, бірақ банк секторы үшін бұл ережеден гөрі ерекшелік. Біздің жағдайда сенімді сақтау үшін деректердің бірнеше көшірмелері болуы маңызды.
Сондықтан үш еселік репликация режимінде CS жұмыс режимі ғана қарастырылды, яғни. Істер кеңістігін құру келесі параметрлермен жүзеге асырылды:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
Әрі қарай, консистенцияның қажетті деңгейін қамтамасыз етудің екі жолы бар. Жалпы ереже:
NW + 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 секунд).
Мүмкін бұл ішінара DataStax for CS орындаған сәтті жүктеме сынауының құпиясы болса керек, өйткені біздің стендте HB үшін репликация коэффициентін 2-ден 3-ке өзгерту ешқандай нәтиже бермеді. Анау. дискілер біздің конфигурациямыз үшін HB кедергісі емес. Дегенмен, мұнда басқа да көптеген қателіктер бар, өйткені біздің HB нұсқамыз аздап түзетілген және түзетілген, орталар мүлдем басқаша және т.б. Айта кету керек, мен CS-ті қалай дұрыс дайындау керектігін білмеймін және онымен жұмыс істеудің тиімді әдістері бар, және біз түсініктемелерде білеміз деп үміттенемін. Бірақ бірінші нәрсе.
Барлық сынақтар әрқайсысы келесі конфигурацияға ие 4 серверден тұратын аппараттық кластерде орындалды:
Орталық процессор: Xeon E5-2680 v4 @ 2.40 ГГц 64 ағын.
Дискілер: 12 дана SATA HDD
java нұсқасы: 1.8.0_111
CS нұсқасы: 3.11.5
cassandra.yml параметрлерітаңбалар_саны: 256
hinted_handoff_enabled: шын
hinted_handoff_throttle_in_kb: 1024
максималды_кеңестер_жеткізу_ағындары: 2
hints_directory: /data10/cassandra/hints
кеңестер_тазалау_кезеңі_мс: 10000
максимум_кеңестер_файл_өлшемі_mb: 128
batchlog_replay_throttle_in_kb: 1024
аутентификация: AllowAllAuthenticator
авторизатор: AllowAllAuthorizer
role_manager: CassandraRoleManager
рөлдердің_жарамдылығы_мс: 2000
рұқсаттардың_жарамдылығы_мс: 2000
тіркелгі деректерінің_жарамдылығы_мс: 2000
бөлуші: org.apache.cassandra.dht.Murmur3Partitioner
деректер_файлының_каталогтары:
- /data1/cassandra/data # әрбір dataN каталогы жеке диск болып табылады
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_каталогы: /data9/cassandra/commitlog
cdc_enabled: жалған
disk_failure_policy: тоқтату
commit_failure_policy: тоқтату
hazırlanmış_statements_cache_size_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
кілт_кэшті_сақтау_кезеңі: 14400
жол_кэш_өлшемі_мб: 0
жолды_кэш_сақтау_кезеңі: 0
counter_cache_size_in_mb:
қарсы_кэшті_сақтау_кезеңі: 7200
сақталған_кэштер_каталогы: /data10/cassandra/saved_caches
commitlog_sync: мерзімді
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
тұқым_провайдері:
- сынып_атауы: org.apache.cassandra.locator.SimpleSeedProvider
параметрлер:
— тұқымдар: «*,*»
concurrent_reads: 256 # тырысты 64 - ешқандай айырмашылық байқалмады
concurrent_writes: 256 # тырысты 64 - ешқандай айырмашылық байқалмады
concurrent_counter_writes: 256 # тырысты 64 - ешқандай айырмашылық байқалмады
concurrent_materialized_view_writes: 32
memtable_heap_space_in_mb: 2048 # 16 ГБ қолданды - ол баяуырақ болды
memtable_allocation_type: heap_buffers
индекс_жинақтау_сыйымдылығы_мб:
индекс_жинақының_өлшемі_минуттағы_аралығы: 60
trickle_fsync: жалған
trickle_fsync_interval_kb: 10240
сақтау_порты: 7000
ssl_storage_port: 7001
тыңдау_мекенжайы: *
тарату_мекен-жайы: *
эфирде_тыңдау_мекенжайы: шын
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
бастау_нативті_тасымалдау: шын
жергілікті_көлік_порты: 9042
start_rpc: шын
rpc_адрес: *
rpc_порты: 9160
rpc_keepalive: шын
rpc_server_type: синхрондау
thrift_framed_transport_sele_in_mb: 15
қосымша_сақтық көшірмелер: жалған
нығыздаудың_алдыңғы_суреті: жалған
auto_snapshot: шын
баған_индекс_өлшемі_кб: 64
баған_индекс_кэш_өлшемі_кб: 2
concurrent_compactors: 4
нығыздау_өткізу_мб_секунд: 1600
sstable_preemptive_open_interval_mb: 50
оқу_сұранысының_уақыты_мсында: 100000
диапазон_сұраныс_уақытының_минутында: 200000
жазу_сұраныс_уақытының_мсында: 40000
counter_write_request_timeout_in_ms: 100000
cas_conttention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
сұрау_уақытының_минусы: 200000
slow_query_log_timeout_in_ms: 500
кросс_түйін_уақыты: жалған
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_in_ms: 100
dynamic_snitch_reset_interval_ms: 600000
dynamic_snitch_жамандық шегі: 0.1
сұрау_жоспарлаушысы: org.apache.cassandra.scheduler.NoScheduler
сервер_шифрлау_опциялары:
түйінаралық_шифрлау: жоқ
клиент_шифрлау_опциялары:
қосулы: жалған
түйінаралық_қысу: DC
inter_dc_tcp_nodelay: жалған
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: жалған
enable_scripted_user_defined_functions: false
windows_таймер_интервалы: 1
мөлдір_деректер_шифрлау_опциялары:
қосулы: жалған
құлпытас_ескерту шегі: 1000
құлпытас_сәтсіздігі_шегі: 100000
топтаманың_өлшемі_ескерту_шегі_кб: 200
топтаманың_өлшемі_сәтсіз_шегі_кб: 250
unlogged_patch_across_partitions_warn_threshold: 10
тығыздау_үлкен_бөлім_ескерту_шегі_мб: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: жалған
қосу_материалдандырылған_көріністер: шын
enable_sasi_indexes: шын
GC параметрлері:
### CMS параметрлері-XX:+UseParNewGC
-XX:+ConcMarkSweepGC пайдаланыңыз
-XX:+CMSParallelRemarkEnabled
-XX:Тірі қалу коэффициенті=8
-XX:MaxTenuring Threshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+CMSIinitiatingOccupancyOnly пайдаланыңыз
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
jvm.options жадына 16 Гб бөлінді (біз де 32 Гб қолданып көрдік, ешқандай айырмашылық байқалмады).
Кестелер келесі пәрменмен құрылды:
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 параметрлеріzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 минут(лар)
hbase.client.scanner.timeout.period: 2 минут(лар)
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 минут(лар)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.период: 4 сағат(лар)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 ГБ
hbase.hregion.memstore.block.көбейткіш: 6
hbase.hstore.compactionШегі: 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.optionalcacheflushinterval18000000
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:CMSIinitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 минут(лар)
hbase.snapshot.region.timeout: 2 минут(лар)
hbase.snapshot.master.timeout.millis: 2 минут(лар)
HBase REST серверінің ең үлкен журнал өлшемі: 100 МБ
HBase REST серверіндегі журнал файлының ең көп сақтық көшірмелері: 5
HBase Thrift Server журналының максималды өлшемі: 100 МБ
HBase Thrift серверіндегі журнал файлының ең көп сақтық көшірмелері: 5
Негізгі журналдың максималды өлшемі: 100 МБ
Негізгі ең көп журнал файлының сақтық көшірмелері: 5
RegionServer журналының максималды өлшемі: 100 МБ
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 үймесінің байттағы өлшемі: 1 ГБ
HBase REST серверінің әдепкі тобы: 3 ГБ
HBase Thrift серверінің әдепкі тобы: 3 ГБ
HBase Master бағдарламасының байттағы Java үйме өлшемі: 16 ГБ
HBase RegionServer серверінің байттағы Java үйме өлшемі: 32 ГБ
+ZooKeeper
maxClientCnxns: 601
maxSessionTimeout: 120000
Кестелерді құру:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
өзгерту 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', ҚЫСЫЛУ => 'GZ'}
Мұнда бір маңызды мәселе бар - DataStax сипаттамасында HB кестелерін жасау үшін қанша аймақ пайдаланылғаны айтылмайды, дегенмен бұл үлкен көлемдер үшін өте маңызды. Сондықтан, сынақтар үшін саны = 64 таңдалды, бұл 640 ГБ дейін сақтауға мүмкіндік береді, яғни. орташа өлшемді үстел.
Сынақ кезінде HBase-де 22 мың кесте және 67 мың аймақ болды (бұл жоғарыда аталған патч болмаса, 1.2.0 нұсқасы үшін өлімге әкелетін еді).
Енді код үшін. Белгілі бір дерекқор үшін қандай конфигурациялар тиімдірек екені белгісіз болғандықтан, сынақтар әртүрлі комбинацияларда жүргізілді. Анау. кейбір сынақтарда 4 кесте бір уақытта жүктелді (қосылу үшін барлық 4 түйін пайдаланылды). Басқа сынақтарда біз 8 түрлі кестемен жұмыс жасадық. Кейбір жағдайларда партия өлшемі 100, басқаларында 200 болды (пакет параметрі - төмендегі кодты қараңыз). Мәнге арналған деректер өлшемі 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 орнатуда қандай да бір кедергі бар деген күдік бар. Дегенмен, Google іздеу және ең айқын параметрлерді іздеу (мысалы, concurrent_writes немесе memtable_heap_space_in_mb) жұмысты тездетпеді. Сонымен қатар, бөренелер таза және ештеңеге ант бермейді.
Деректер түйіндер бойынша біркелкі таратылды, барлық түйіндердің статистикасы шамамен бірдей болды.
Түйіндердің бірінен кесте статистикасы осылай көрінедіПернелер кеңістігі: ks
Оқылған саны: 9383707
Оқу кідірісі: 0.04287025042448576 мс
Жазу саны: 15462012
Жазу кідірісі: 0.1350068438699957 мс
Күтудегі жуулар: 0
Кесте: t1
SSTable саны: 16
Пайдаланылған кеңістік (тірі): 148.59 МБ
Пайдаланылған кеңістік (барлығы): 148.59 МБ
Суреттер пайдаланатын кеңістік (барлығы): 0 байт
Пайдаланылған үйме жады (барлығы): 5.17 МБ
SSTable қысу коэффициенті: 0.5720989576459437
Бөлімдердің саны (бағалау): 3970323
Жадты ұяшықтар саны: 0
Memtable деректер өлшемі: 0 байт
Пайдаланылған жадыдан тыс үйме жады: 0 байт
Memtable қосқыштарының саны: 5
Жергілікті оқылғандар саны: 2346045
Жергілікті оқу кідірісі: NaN мс
Жергілікті жазу саны: 3865503
Жергілікті жазу кідірісі: NaN мс
Күтудегі тазартулар: 0
Жөндеу пайызы: 0.0
Блум сүзгісінің жалған позитивтері: 25
Блум сүзгісінің жалған коэффициенті: 0.00000
Пайдаланылған Блум сүзгі кеңістігі: 4.57 МБ
Блум сүзгісі пайдаланылған үйме жады: 4.57 МБ
Пайдаланылған үйме жады индексінің жиынтық сипаттамасы: 590.02 КБ
Пайдаланылған жинақтық жадты қысу метадеректері: 19.45 КБ
Тығыздалған бөлімнің минималды байттары: 36
Тығыздалған бөлімнің максималды байты: 42
Тығыздалған бөлімнің орташа байты: 42
Бір кесіндідегі орташа тірі жасушалар (соңғы бес минут): NaN
Бір кесіндідегі максималды тірі ұяшықтар (соңғы бес минут): 0
Бір кесіндідегі орташа құлпытастар (соңғы бес минут): NaN
Бір кесіндідегі ең көп құлпытастар (соңғы бес минут): 0
Түсірілген мутациялар: 0 байт
Топтаманың көлемін азайту әрекеті (тіпті оны жеке-жеке жіберу) ешқандай нәтиже бермеді, ол тек нашарлады. Бұл шын мәнінде CS үшін максималды өнімділік болуы мүмкін, өйткені CS үшін алынған нәтижелер DataStax үшін алынған нәтижелерге ұқсас - секундына жүздеген мың операциялар. Сонымен қатар, егер ресурстарды пайдалануды қарастыратын болсақ, біз CS әлдеқайда көп процессор мен дискілерді пайдаланатынын көреміз:
Суретте екі дерекқор үшін қатардағы барлық сынақтарды орындау кезінде пайдалану көрсетілген.
HB-тің күшті оқу артықшылығына қатысты. Мұнда екі дерекқор үшін де оқу кезінде дискіні пайдалану өте төмен екенін көруге болады (оқу сынақтары әрбір дерекқор үшін тестілеу циклінің соңғы бөлігі болып табылады, мысалы, CS үшін бұл 15:20-дан 15:40-қа дейін). HB жағдайында оның себебі анық - деректердің көпшілігі жадта, жад қоймасында, ал кейбіреулері блок кэште кэштелген. CS-ге келетін болсақ, оның қалай жұмыс істейтіні анық емес, бірақ дискіні қайта өңдеу де көрінбейді, бірақ бұл жағдайда кэшті қосу әрекеті жасалды row_cache_size_in_mb = 2048 және кэштеуді орнату = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, бірақ бұл жағдайды одан да нашарлатты.
Сондай-ақ, HB аймақтарының саны туралы маңызды мәселені тағы да атап өткен жөн. Біздің жағдайда, мән 64 ретінде көрсетілді. Егер сіз оны азайтып, оны, мысалы, 4-ке тең етсеңіз, онда оқу кезінде жылдамдық 2 есе төмендейді. Себебі, memstore тезірек толтырылады және файлдар жиі тазартылады және оқу кезінде көбірек файлдарды өңдеу қажет болады, бұл HB үшін өте күрделі операция. Нақты жағдайларда мұны алдын ала бөлу және ықшамдау стратегиясы арқылы ойлау арқылы емдеуге болады; атап айтқанда, біз қоқысты жинайтын және HFiles файлдарын үнемі фондық режимде қысатын өздігінен жазылған қызметтік бағдарламаны қолданамыз. DataStax сынақтары үшін олар кестеге тек 1 аймақты бөлген болуы мүмкін (бұл дұрыс емес) және бұл HB олардың оқу сынақтарында неге соншалықты төмен екенін түсіндіреді.
Бұдан мынадай алдын ала қорытындылар шығарылады. Тестілеу кезінде үлкен қателіктер жасалмады деп есептесек, Кассандра табандары саз балшықпен жасалған колоссқа ұқсайды. Дәлірек айтсақ, ол мақаланың басындағы суреттегідей бір аяғымен тепе-теңдікті ұстанған кезде, салыстырмалы түрде жақсы нәтиже көрсетеді, бірақ дәл осындай жағдайдағы жекпе-жекте ол бірден жеңіледі. Сонымен бірге, біздің аппараттық құралымызда CPU пайдаланудың төмендігін ескере отырып, біз бір хостқа екі RegionServer HB орнатуды үйрендік және осылайша өнімділікті екі есе арттырдық. Анау. Ресурстарды пайдалануды ескере отырып, КС үшін жағдай одан да аянышты.
Әрине, бұл сынақтар өте синтетикалық және мұнда қолданылған деректер мөлшері салыстырмалы түрде қарапайым. Мүмкін, егер біз терабайтқа ауыссақ, жағдай басқаша болар еді, бірақ HB үшін терабайттарды жүктей алатын болсақ, CS үшін бұл проблемалы болып шықты. Жауапты күту параметрлері әдепкімен салыстырғанда бірнеше есе ұлғайғанымен, ол осы көлемдермен бірге OperationTimedOutException жиі шығарды.
Бірлескен күш-жігердің арқасында біз CS кедергілерін табамыз деп үміттенемін және егер біз оны тездете алсақ, онда посттың соңында мен соңғы нәтижелер туралы ақпаратты міндетті түрде қосамын.
UPD: Жолдастардың кеңесінің арқасында мен оқуды тездете алдым. болды:
159 644 операция (4 кесте, 5 ағын, 100 топтама).
Қосқан:
.withLoadBalancingPolicy(жаңа TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Мен жіптердің санымен ойнадым. Нәтиже келесідей:
4 кесте, 100 жіп, партия = 1 (дана): 301 969 операция
4 кесте, 100 ағын, пакет = 10: 447 операция
4 кесте, 100 ағын, пакет = 100: 625 операция
Кейінірек мен басқа баптау бойынша кеңестерді қолданамын, толық сынақ циклін орындаймын және нәтижелерді посттың соңына қосамын.
Ақпарат көзі: www.habr.com