Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Ин ҳатто шӯхӣ нест, чунин ба назар мерасад, ки ин тасвири мушаххас моҳияти ин пойгоҳи додаҳоро дақиқтар инъикос мекунад ва дар ниҳоят маълум хоҳад шуд, ки чаро:

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Мувофиқи DB-Engines Ranking, ду пойгоҳи маъмултарини сутунии NoSQL инҳоянд Cassandra (минбаъд CS) ва HBase (HB).

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Бо хости тақдир, гурӯҳи идоракунии боркунии маълумотҳои мо дар Сбербанк аллакай давно ва бо HB зич кор мекунад. Дар ин муддат мо ҷиҳатҳои қавӣ ва сустии онро хеле хуб омӯхтем ва тарзи пухтани онро ёд гирифтем. Аммо, мавҷудияти алтернатива дар шакли CS ҳамеша моро маҷбур мекард, ки худро каме бо шубҳа азоб диҳем: оё мо интихоби дуруст кардем? Илова бар ин, натиҷаҳо муқоиса кардан, ки аз ҷониби DataStax иҷро шудааст, онҳо гуфтанд, ки CS ба осонӣ HB-ро бо тақрибан як хол мағлуб мекунад. Аз тарафи дигар, DataStax як тарафи манфиатдор аст ва шумо набояд суханони онҳоро қабул кунед. Мо инчунин аз миқдори ками маълумот дар бораи шароити санҷиш ошуфта будем, аз ин рӯ мо тасмим гирифтем, ки мустақилона фаҳмем, ки подшоҳи BigData NoSql кист ва натиҷаҳои бадастомада хеле ҷолиб буданд.

Бо вуҷуди ин, пеш аз гузаштан ба натиҷаҳои санҷишҳои гузаронидашуда, бояд ҷанбаҳои муҳими конфигуратсияҳои муҳити зистро тавсиф кард. Гап дар он аст, ки CS-ро метавон дар реҷае истифода бурд, ки имкон медиҳад талафоти маълумотро фароҳам орад. Онхое. ин вақтест, ки танҳо як сервер (гиреҳ) барои додаҳои калиди муайян масъул аст ва агар бо ягон сабаб кор накунад, арзиши ин калид гум мешавад. Барои бисёр вазифаҳо ин муҳим нест, аммо барои бахши бонкӣ ин истисно аст, на қоида. Дар ҳолати мо, барои нигоҳдории боэътимод доштани якчанд нусхаи маълумот муҳим аст.

Аз ин рӯ, танҳо реҷаи кори CS дар реҷаи такрори сегона баррасӣ шуд, яъне. Эҷоди фазои парвандаҳо бо параметрҳои зерин анҷом дода шуд:

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

Минбаъд, ду роҳи таъмини сатҳи зарурии мувофиқат вуҷуд дорад. Қоидаи умумӣ:
NW + NR > РФ

Ин маънои онро дорад, ки шумораи тасдиқҳо аз гиреҳҳо ҳангоми навиштан (NW) ва шумораи тасдиқҳо аз гиреҳҳо ҳангоми хондан (NR) бояд аз омили такрорӣ зиёдтар бошад. Дар ҳолати мо, RF = 3, яъне имконоти зерин мувофиқанд:
2 + 2 > 3
3 + 1 > 3

Азбаски барои мо то ҳадди имкон боэътимод нигоҳ доштани маълумот муҳим аст, нақшаи 3+1 интихоб карда шуд. Илова бар ин, HB аз рӯи принсипи шабеҳ кор мекунад, яъне. чунин мукоиса одилонатар мешавад.

Бояд қайд кард, ки DataStax дар омӯзиши худ баръакс кард, онҳо RF = 1-ро ҳам барои CS ва ҳам HB муқаррар карданд (барои охирин бо тағир додани танзимоти HDFS). Ин як ҷанбаи воқеан муҳим аст, зеро таъсир ба иҷрои CS дар ин ҳолат бузург аст. Масалан, дар расми зер афзоиши вақт барои боркунии маълумот ба CS нишон дода шудааст:

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Дар ин ҷо мо инҳоро мебинем: ҳар қадар риштаҳои рақобаткунанда маълумот менависанд, ҳамон қадар зиёдтар вақт мегирад. Ин табиист, аммо муҳим аст, ки таназзули иҷроиш барои RF=3 ба таври назаррас баландтар бошад. Ба ибораи дигар, агар мо ба 4 ҷадвал 5 ришта нависем (ҳамагӣ 20), он гоҳ RF=3 тақрибан 2 маротиба гум мешавад (150 сония барои RF=3 дар баробари 75 барои RF=1). Аммо агар мо сарбориро тавассути бор кардани маълумот ба 8 ҷадвал бо ҳар кадоми 5 ришта (ҷамъ 40) зиёд кунем, пас талафоти RF=3 аллакай 2,7 маротиба (375 сония нисбат ба 138) аст.

Шояд ин қисман сирри санҷиши бомуваффақияти сарборӣ аз ҷониби DataStax for CS бошад, зеро барои HB дар стенди мо тағир додани омили такрорӣ аз 2 ба 3 ҳеҷ таъсире надошт. Онхое. дискҳо монеаи HB барои конфигуратсияи мо нестанд. Бо вуҷуди ин, дар ин ҷо бисёр домҳои дигар мавҷуданд, зеро бояд қайд кард, ки версияи мо HB каме часпонда ва таҳрир карда шудааст, муҳитҳо тамоман дигаранд ва ғайра. Инчунин бояд қайд кард, ки шояд ман намедонам, ки чӣ гуна CS-ро дуруст омода созам ва роҳҳои самараноктари кор бо он вуҷуд доранд ва ман умедворам, ки мо дар шарҳҳо хоҳем ёфт. Аммо чизҳои аввал.

Ҳама санҷишҳо дар кластери сахтафзор, ки аз 4 сервер иборатанд, анҷом дода шуданд, ки ҳар кадоми онҳо конфигуратсияи зерин доранд:

CPU: 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
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
аутентификатор: AllowAllAuthenticator
авторизатор: AllowAllAuthorizer
role_meneger: CassandraRoleManager
нақшҳои_эътибор дар_ms: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
partitioner: 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_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:
Давраи_кэш_захира: 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_нависад: 32
memtable_heap_space_in_mb: 2048 # кӯшиш кард 16 ГБ - он сусттар буд
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_daqiqalar: 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: бардурӯғ
snapshot_pefore_compaction: бардурӯғ
auto_snapshot: дуруст
сутуни_индекс_андозаи_дар_кб: 64
сутуни_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_contential_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: GossipingPropertyFileSnitch
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
server_encryption_Options:
internode_encryption: ҳеҷ
мизоҷ_имконоти_encryption:
фаъол: бардурӯғ
фишурдани_байни гиреҳ: DC
inter_dc_tcp_nodelay: бардурӯғ
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: бардурӯғ
enable_scripted_user_defined_functions: бардурӯғ
фосилаи_таймер_windows: 1
имконоти_шаффоф_маълумот_рамзкунонӣ:
фаъол: бардурӯғ
Ҳадди_санги_огоҳӣ: 1000
Ҳадди_санги_нокомӣ: 100000
андозаи_бача_огоҳӣ_ҳадди_дар_кб: 200
Андозаи_партияи_нокоми_ҳадди_дар_кб: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_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: Таносуби наҷотёфта = 8
-XX: Ҳадди ҳадди аксар=1
-XX: CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-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 мо MetricsRegion-ро истисно кардем, ки боиси GC шуд, вақте ки шумораи минтақаҳо дар RegionServer зиёда аз 1000 буд)

Параметрҳои пешфарз HBasezookeeper.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.мултипликатор: 6
hbase.hstore.compaction Ҳадди: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 рӯз
Парчами конфигуратсияи Advanced Service HBase (Valve Safety) барои hbase-site.xml:
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
Имконоти конфигуратсияи Java барои HBase RegionServer:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=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 Андозаи макс: 100 МБ
Нусхаи эҳтиётии ҳадди аксар аз сервери HBase REST: 5
HBase Thrift Server Макс Андозаи Сабти: 100 МБ
Нусхаи ҳадди аксар захираҳои файли сервери HBase Thrift: 5
Мастер Макс Андозаи Сабти: 100 МБ
Мастер ҳадди аксар нусхабардории файлҳои сабт: 5
RegionServer Макс Андозаи Сабти: 100 МБ
Регионсервер ҳадди ниҳоии захираҳои файли журнал: 5
Равзанаи муайянкунии Master Active 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 ГБ
Андозаи Java Heap Master HBase дар байт: 16 ГБ
Андозаи Java Heap-и HBase RegionServer дар байт: 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', COMpression => '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);
}

Ҳоло қисми ҷолибтарин - натиҷаҳо:

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Ҳамин чиз дар шакли графикӣ:

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк

Бартарии HB он қадар тааҷҷубовар аст, ки шубҳае вуҷуд дорад, ки дар танзими CS як навъ монеа вуҷуд дорад. Бо вуҷуди ин, Google ва ҷустуҷӯи параметрҳои равшантарин (ба монанди concurrent_writes ё memtable_heap_space_in_mb) корҳоро суръат набахшид. Дар айни замон, чӯбҳо тозаанд ва ба ҳеҷ чиз қасам намехӯранд.

Маълумот дар саросари гиреҳҳо баробар тақсим карда шуд, омори ҳамаи гиреҳҳо тақрибан якхела буд.

Чунин аст омори ҷадвал аз яке аз гиреҳҳоФазои калидҳо: ks
Шумораи хондан: 9383707
Нигоҳдории хониш: 0.04287025042448576 ms
Шумораи навиштан: 15462012
Вақти навиштан: 0.1350068438699957 ms
Ҳодисаҳои интизорӣ: 0
Ҷадвали: t1
Шумораи SSTable: 16
Фазои истифодашуда (зинда): 148.59 МБ
Фазои истифодашуда (умумӣ): 148.59 МБ
Фазое, ки аз ҷониби аксҳо истифода мешавад (ҳамагӣ): 0 байт
Хотираи хомӯш истифодашаванда (умумӣ): 5.17 МБ
Таносуби фишурдани SSTable: 0.5720989576459437
Шумораи қисмҳо (сметаи): 3970323
Шумораи ҳуҷайраҳои хотиравӣ: 0
Андозаи маълумотҳои хотиравӣ: 0 байт
Хотираи хотираи ғайрифаъол истифодашаванда: 0 байт
Шумораи ивазкунандаи хотира: 5
Шумораи хониши маҳаллӣ: 2346045
Нигоҳдории хониши маҳаллӣ: NaN ms
Шумораи навиштаҳои маҳаллӣ: 3865503
Нигоҳубини навиштани маҳаллӣ: NaN ms
Андозаи интизорӣ: 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 ва дискҳои бештарро истифода мебарад:

Ҷанги ду якозуна ё Кассандра против HBase. Таҷрибаи дастаи Сбербанк
Дар расм истифодабарии ҳама санҷишҳо дар як саф барои ҳарду пойгоҳи додаҳо нишон дода шудааст.

Дар бораи бартарии пурқуввати хониши HB. Дар ин ҷо шумо мебинед, ки барои ҳарду пойгоҳи додаҳо, истифодаи диск ҳангоми хондан хеле паст аст (санҷишҳои хониш қисми ниҳоии давраи санҷиш барои ҳар як пойгоҳи додаҳо мебошанд, масалан барои CS ин аз 15:20 то 15:40). Дар мавриди HB, сабаб равшан аст - аксари маълумотҳо дар хотира, дар мағозаи хотира овезон мешаванд ва баъзеи онҳо дар блок кэш нигоҳ дошта мешаванд. Дар мавриди CS, он чандон равшан нест, ки он чӣ гуна кор мекунад, аммо коркарди такрории диск низ ба назар намерасад, аммо ба ҳар сурат, кӯшиш карда шуд, ки кэшро фаъол созад row_cache_size_in_mb = 2048 ва танзими кэш = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, аммо ин онро ҳатто каме бадтар кард.

Боз як нуктаи муҳимро дар бораи шумораи минтақаҳои ҲБ қайд кардан лозим аст. Дар ҳолати мо, арзиш ҳамчун 64 муайян карда шуд. Агар шумо онро кам кунед ва онро ба 4 баробар кунед, пас ҳангоми хондан суръат 2 маротиба коҳиш меёбад. Сабаб дар он аст, ки memstore тезтар пур мешавад ва файлҳо зуд-зуд тоза карда мешаванд ва ҳангоми хондан файлҳои бештарро коркард кардан лозим меояд, ки ин як амалиёти хеле мураккаб барои HB аст. Дар шароити воқеӣ, инро метавон тавассути андешаи стратегияи ҷудокунӣ ва паймонсозӣ ҳал кард; аз ҷумла, мо як утилитаи худнависиро истифода мебарем, ки партовҳоро ҷамъоварӣ мекунад ва HFiles-ро доимо дар замина фишурда мекунад. Ин комилан имконпазир аст, ки барои санҷишҳои DataStax онҳо барои ҳар як ҷадвал танҳо 1 минтақа ҷудо кардаанд (ки дуруст нест) ва ин то андозае фаҳмонад, ки чаро HB дар санҷишҳои хониши онҳо ин қадар пасттар буд.

Аз ин хулосахои пешакии зерин мебароянд. Агар фарз кунем, ки дар вақти санҷиш ягон хатогии ҷиддӣ содир нашудааст, пас Кассандра ба як колоссуи пойҳои гил монанд аст. Аниқтараш, дар ҳоле ки вай дар як пояш мувозинат мекунад, чун дар расми аввали мақола, ӯ натиҷаҳои нисбатан хуб нишон медиҳад, аммо дар мубориза дар ҳамон шароит вай комилан мағлуб мешавад. Ҳамзамон, бо назардошти истифодаи пасти CPU дар сахтафзори мо, мо шинондани ду RegionServer HB-ро дар як ҳост ёд гирифтем ва ба ин васила иҷроишро дучанд кард. Онхое. Бо назардошти истифодаи ресурсхо вазъияти СС боз хам гамгинтар аст.

Албатта, ин санҷишҳо хеле синтетикӣ мебошанд ва миқдори маълумоте, ки дар ин ҷо истифода шудааст, нисбатан хоксор аст. Мумкин аст, ки агар мо ба терабайт гузарем, вазъият дигар мешуд, аммо дар ҳоле, ки барои HB мо метавонем терабайтҳоро бор кунем, барои CS ин мушкил буд. Он аксар вақт OperationTimedOutExceptionро ҳатто бо ин ҳаҷмҳо мепартофт, гарчанде ки параметрҳои интизории посух дар муқоиса бо пешфарзҳо аллакай якчанд маротиба зиёд шуда буданд.

Умедворам, ки бо талошҳои муштарак мо монеаҳои CS-ро пайдо хоҳем кард ва агар онро суръат бахшем, пас дар охири мақола ҳатман дар бораи натиҷаҳои ниҳоӣ маълумот илова хоҳам кард.

УПД: Ба шарофати маслихати рафикон ба ман муяссар гардид, ки суръати хонишро тезонам. буд:
159 опсия (644 ҷадвал, 4 ҷараён, партия 5).
Иловаи:
.withLoadBalancingPolicy(нав TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
Ва ман бо шумораи риштаҳо бозӣ кардам. Натиҷа ин аст:
4 ҷадвал, 100 ришта, партия = 1 (порча ба порча): 301 опсия
4 ҷадвал, 100 ришта, партия = 10: 447 опсия
4 ҷадвал, 100 ришта, партия = 100: 625 опсия

Баъдтар ман маслиҳатҳои дигари танзимкуниро татбиқ мекунам, як давраи пурраи санҷишро иҷро мекунам ва натиҷаҳоро дар охири пост илова мекунам.

Манбаъ: will.com

Илова Эзоҳ