Бул тамаша эмес, бул өзгөчө сүрөт бул маалымат базаларынын маңызын эң так чагылдырат окшойт, акыры эмне үчүн ачык болот:
DB-Engines Ranking ылайык, эки эң популярдуу NoSQL мамычалык маалымат базалары Кассандра (мындан ары CS) жана HBase (HB) болуп саналат.
Тагдырдын буйругу менен, биздин Сбербанктагы маалыматтарды жүктөө боюнча командабыз буга чейин эле бар жана HB менен тыгыз иштешет. Бул убакыттын ичинде биз анын күчтүү жана алсыз жактарын жакшылап изилдеп, тамак жасаганды үйрөндүк. Бирок, CS түрүндөгү альтернативанын болушу бизди ар дайым өзүбүздү бир аз шектенүүгө мажбурлады: биз туура тандоо жасадыкпы? Мындан тышкары, натыйжалар , DataStax тарабынан аткарылган, алар CS оной эле дээрлик талкаланган упай менен HB согот деп айтышкан. Башка жагынан алганда, DataStax кызыкдар тарап болуп саналат, жана бул үчүн алардын сөзүн кабыл албашыбыз керек. Ошондой эле тестирлөөнүн шарттары жөнүндө анча-мынча маалымат менен чаташтырдык, ошондуктан биз BigData NoSql падышасы ким экенин өз алдынча билүүнү чечтик жана алынган натыйжалар абдан кызыктуу болду.
Бирок, аткарылган сыноолордун натыйжаларына өтүүдөн мурун, айлана-чөйрөнүн конфигурацияларынын маанилүү аспектилерин сүрөттөп берүү зарыл. Чындыгында CS маалыматтарды жоготууга мүмкүндүк берген режимде колдонулушу мүмкүн. Ошол. бул белгилүү бир ачкычтын маалыматтары үчүн бир гана сервер (түйүн) жооптуу болгондо жана кандайдыр бир себептерден улам ал иштебей калса, анда бул ачкычтын мааниси жоголот. Көптөгөн тапшырмалар үчүн бул өтө маанилүү эмес, бирок банк сектору үчүн бул эреже эмес, өзгөчө жагдай. Биздин учурда, ишенимдүү сактоо үчүн маалыматтардын бир нече көчүрмөсү болушу маанилүү.
Ошондуктан, үч жолу кайталоо режиминде CS иштөө режими гана каралып, б.а. Case мейкиндигин түзүү төмөнкү параметрлер менен ишке ашырылган:
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 секунд) түзөт.
Балким, бул жарым-жартылай CS үчүн DataStax тарабынан ийгиликтүү жүктөө тестирлөөнүн сыры, анткени биздин стенддеги HB үчүн репликация коэффициентин 2ден 3кө өзгөртүү эч кандай натыйжа берген жок. Ошол. дисктер биздин конфигурациябыз үчүн HB тоскоолдуктары эмес. Бирок, бул жерде дагы көптөгөн тузактар бар, анткени биздин HB версиябыз бир аз жамаачыланган жана чыңдалган, чөйрөлөр такыр башкача, ж.б. Белгилей кетчү нерсе, балким, мен CSти кантип туура даярдоону билбейм жана аны менен иштөөнүн бир нече натыйжалуу жолдору бар, биз муну комментарийлерден табабыз деп үмүттөнөм. Бирок биринчи кезекте.
Бардык тесттер ар бири төмөнкү конфигурацияга ээ болгон 4 серверден турган аппараттык кластерде аткарылды:
CPU: Xeon E5-2680 v4 @ 2.40GHz 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
hints_flush_period_in_ms: 10000
максимум_кеңештер_файлдын_өлчөмү_mb: 128
batchlog_replay_throttle_in_kb: 1024
аутентификация: AllowAllAuthenticator
авторизатор: AllowAllAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
бөлүүчү: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /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_directory: /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:
key_cache_save_period: 14400
row_cache_size_in_mb: 0
сап_кэшти_сактоо_периоду: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /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_in_kb: 10240
сактоо_порту: 7000
ssl_storage_port: 7001
угуу_дареги: *
уктуруу_дареги: *
уктурууда_угуу_дареги: чын
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: чыныгы
жергиликтүү_транспорттук_порт: 9042
start_rpc: чын
rpc_дареги: *
rpc_port: 9160
rpc_keepalive: чындык
rpc_server_type: синхрондоштуруу
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
ныкталгандан мурун_сүрөт: жалган
auto_snapshot: true
мамычанын_индекс_өлчөмү_кб: 64
колонна_индекс_кэш_өлчөмү_кб: 2
concurrent_compactors: 4
ныктоо_өткөрүү_мб_секуна: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
diapazon_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contential_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
кайчылаш_түйүн_таймооту: жалган
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
динамикалык_жамандык_босогосу: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: жок
client_encryption_options:
иштетилген: жалган
internode_compression: DC
inter_dc_tcp_nodelay: жалган
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: false
enable_scripted_user_defined_functions: false
windows_таймер_аралыгы: 1
transparent_data_encryption_options:
иштетилген: жалган
мүрзөнүн_эскертүү_босогосу: 1000
мүрзө ташынын_жетпестигинин_босогосу: 100000
пакеттин_өлчөмү_эскертүү_босогосу_кб: 200
пакеттин_өлчөмү_кабыл алуу_босогосу_кб: 250
unlogged_batch_across_partitions_warn_threhold: 10
compaction_lorage_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: жалган
enable_materialized_views: чындык
enable_sasi_indexes: чындык
GC жөндөөлөрү:
### CMS орнотуулары-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX: SurvivorRatio=8
-XX:MaxTenuring Threshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+UseCMSIinitiatingOccupancyOnly
-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.period: 4 саат(лар)
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 ГБ
hbase.hregion.memstore.block.multiplier: 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=256м
hbase.snapshot.master.timeoutMillis: 2 мүнөт
hbase.snapshot.region.timeout: 2 мүнөт
hbase.snapshot.master.timeout.millis: 2 мүнөт
HBase REST Server Max Log көлөмү: 100 МБ
HBase REST Server максималдуу журнал файлынын камдык көчүрмөлөрү: 5
HBase Thrift Server Max Log көлөмү: 100 МБ
HBase Thrift Server максималдуу журнал файлынын камдык көчүрмөлөрү: 5
Master Max Log көлөмү: 100 МБ
Master максималдуу журнал файлынын камдык көчүрмөлөрү: 5
RegionServer Max Log көлөмү: 100 МБ
RegionServer журналынын максималдуу камдык көчүрмөлөрү: 5
HBase Active Master Detection терезеси: 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.кичинекей: 6
hbase.ipc.server.read.threadpool.size: 20
Регионду жылдыргыч темалар: 6
Кардардын Java үймөгү Байттагы көлөмү: 1 ГБ
HBase REST серверинин демейки тобу: 3 ГБ
HBase Thrift Server Демейки тобу: 3 ГБ
HBase Мастеринин 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 орнотууда кандайдыр бир тоскоолдук бар деген шектенүү бар. Бирок, Googling жана эң айкын параметрлерди издөө (мисалы 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
Memtable клеткалардын саны: 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 алда канча көп CPU жана дисктерди колдоноорун көрөбүз:
Сүрөт эки маалымат базасы үчүн катардагы бардык тесттерди иштетүү учурунда колдонулушун көрсөтөт.
HBнин күчтүү окуу артыкчылыгы жөнүндө. Бул жерде сиз эки база үчүн тең окуу учурунда дискти колдонуу өтө төмөн экенин көрө аласыз (окуу тесттери ар бир маалымат базасы үчүн тестирлөө циклинин акыркы бөлүгү, мисалы CS үчүн бул 15:20дан 15:40ка чейин). HB учурда, себеби түшүнүктүү - маалыматтардын көбү эстутумда, мемсттордо илинип турат, ал эми кээ бирлери блоккэште кэште сакталат. CSге келсек, анын кандайча иштегени так эмес, бирок дискти кайра иштетүү да көрүнбөйт, бирок row_cache_size_in_mb = 2048 кэшин иштетүүгө аракет жасалып, кэштөө = {'ачкычтар': 'ALL', 'rows_per_partition': ' 2000000'}, бирок бул аны бир аз ого бетер начарлатты.
Ошондой эле НБдагы аймактардын саны жөнүндө дагы бир маанилүү жагдайды белгилей кетүү керек. Биздин учурда, маани 64 деп көрсөтүлгөн. Эгер аны азайтып, мисалы, 4кө барабар кылсаңыз, анда окуганда ылдамдык 2 эсеге төмөндөйт. Себеби, memstore тезирээк толуп, файлдар тез-тез тазаланып турат жана окуганда көбүрөөк файлдарды иштетүү керек болот, бул HB үчүн өтө татаал операция. Чыныгы шарттарда муну алдын ала бөлүү жана компактификациялоо стратегиясы аркылуу ойлонуу аркылуу чечүүгө болот; атап айтканда, биз таштандыларды чогултуучу жана HFiles файлдарын дайыма фондо кысып турган өз алдынча жазылган утилитаны колдонобуз. DataStax тесттери үчүн алар бир таблицага 1 гана аймакты бөлүп бериши толук мүмкүн (бул туура эмес) жана бул HB эмне үчүн окуу тесттеринде ушунчалык төмөн болгонун бир аз түшүндүрөт.
Мындан төмөнкүдөй алдын ала жыйынтыктар чыгарылат. Сыноо учурунда эч кандай чоң ката кетирилген жок деп ойлосок, анда Кассандра чопо буттары бар колоссуска окшош. Тагыраак айтканда, ал макаланын башындагы сүрөттөгүдөй, бир буту менен тең салмактуулукту кармап турганда, салыштырмалуу жакшы жыйынтыктарды көрсөтөт, бирок ошол эле шарттарда күрөштө ал биротоло жеңилип калат. Ошол эле учурда, биздин аппараттык жабдыкта CPU аз колдонулушун эске алып, биз бир хостко эки RegionServer HB орнотууну үйрөндүк жана ошону менен өндүрүмдүүлүктү эки эсеге жогорулатты. Ошол. Ресурстарды пайдаланууну эске алсак, КС үчүн абал ого бетер кейиштүү.
Албетте, бул тесттер кыйла синтетикалык жана бул жерде колдонулган маалыматтардын көлөмү салыштырмалуу жөнөкөй. Мүмкүн, эгер биз терабайтка өтсөк, абал башкача болмок, бирок HB үчүн терабайт жүктөй алсак, CS үчүн бул көйгөйлүү болуп чыкты. Бул көп учурда OperationTimedOutException ыргытып жиберди, бирок жооп күтүү параметрлери демейкиге салыштырмалуу бир нече эсе көбөйтүлгөн.
Биргелешкен күч-аракеттер менен биз CSтин тоскоолдуктарын табабыз деп үмүттөнөм жана эгер биз аны тездете алсак, анда посттун аягында мен сөзсүз түрдө акыркы жыйынтыктар тууралуу маалымат кошом.
UPD: Жолдоштордун кеңеши аркасында окууну тездетүүгө жетиштим. болгон:
159 644 операция (4 таблица, 5 агым, 100 партия).
Posted:
.withLoadBalancingPolicy(жаңы TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Жана мен жиптердин саны менен ойнодум. Натыйжада төмөнкүдөй:
4 үстөл, 100 жип, партия = 1 (даана боюнча): 301 969 операция
4 үстөл, 100 жип, партия = 10: 447 операция
4 үстөл, 100 жип, партия = 100: 625 операция
Кийинчерээк мен башка тюнинг кеңештерин колдоном, толук сыноо циклин аткарам жана натыйжаларды посттун аягында кошом.
Source: www.habr.com