ბრძოლა ორი იაკოძუნა, ან კასანდრა vs HBase. სბერბანკის გუნდის გამოცდილება

ეს ხუმრობაც კი არ არის, როგორც ჩანს, ეს კონკრეტული სურათი ყველაზე ზუსტად ასახავს ამ მონაცემთა ბაზების არსს და საბოლოოდ გაირკვევა, რატომ:

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-მა საპირისპირო გააკეთა მათ კვლევაში, მათ დააყენეს RF = 1 როგორც CS-სთვის, ასევე HB-სთვის (ამ უკანასკნელისთვის HDFS პარამეტრების შეცვლით). ეს მართლაც მნიშვნელოვანი ასპექტია, რადგან გავლენა CS-ის შესრულებაზე ამ შემთხვევაში უზარმაზარია. მაგალითად, ქვემოთ მოყვანილი სურათი გვიჩვენებს CS-ში მონაცემების ჩასატვირთად საჭირო დროის ზრდას:

აქ ჩვენ ვხედავთ შემდეგს: რაც უფრო მეტი კონკურენტი ძაფები წერენ მონაცემებს, მით უფრო მეტი დრო სჭირდება. ეს ბუნებრივია, მაგრამ მნიშვნელოვანია, რომ RF=3-ის შესრულების დეგრადაცია მნიშვნელოვნად მაღალი იყოს. სხვა სიტყვებით რომ ვთქვათ, თუ ჩავწერთ 4 ძაფს 5 ცხრილში თითოეულში (სულ 20), მაშინ RF=3 კარგავს დაახლოებით 2-ჯერ (150 წამი RF=3-ისთვის 75-ისთვის RF=1-ისთვის). მაგრამ თუ გავზრდით დატვირთვას მონაცემების ჩატვირთვით 8 ცხრილში 5 ძაფით (სულ 40), მაშინ RF=3-ის დაკარგვა უკვე 2,7-ჯერ (375 წამი 138-ის წინააღმდეგ).

შესაძლოა, ნაწილობრივ ეს არის DataStax-ის მიერ CS-სთვის ჩატარებული წარმატებული დატვირთვის ტესტირების საიდუმლო, რადგან ჩვენს სტენდზე HB-სთვის რეპლიკაციის ფაქტორის 2-დან 3-მდე შეცვლას არანაირი ეფექტი არ მოჰყოლია. იმათ. დისკები არ არის ჩვენი კონფიგურაციის HB ბოთლი. თუმცა აქ ბევრი სხვა ხარვეზია, რადგან უნდა აღინიშნოს, რომ HB-ის ჩვენი ვერსია იყო ოდნავ დაყენებული და დამუშავებული, გარემო სრულიად განსხვავებული და ა.შ. აღსანიშნავია ისიც, რომ შესაძლოა უბრალოდ არ ვიცი როგორ მოვამზადო CS სწორად და არსებობს უფრო ეფექტური გზები მასთან მუშაობისთვის და იმედია კომენტარებში გავარკვევთ. მაგრამ პირველ რიგში.

ყველა ტესტი ჩატარდა ტექნიკის კლასტერზე, რომელიც შედგებოდა 4 სერვერისგან, თითოეული შემდეგი კონფიგურაციით:

პროცესორი: Xeon E5-2680 v4 @ 2.40 GHz 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
max_hints_delivery_threads: 2
hints_directory: /data10/cassandra/hints
მინიშნებები_flush_period_in_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
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
partitioner: 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: false
disk_failure_policy: გაჩერება
commit_failure_policy: შეჩერდი
ready_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
row_cache_save_period: 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
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
პარამეტრებით:
- თესლი: "*,*"
პარალელურად_წაკითხული: 256 # სცადა 64 - განსხვავება არ შეიმჩნევა
concurrent_წერს: 256 # ცდილობდა 64 - განსხვავება არ შეიმჩნევა
concurrent_counter_write: 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_წუთებში: 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: მართალია
მშობლიური_ტრანსპორტი_პორტი: 9042
start_rpc: მართალია
rpc_address: *
rpc_port: 9160
rpc_keepalive: მართალია
rpc_server_type: სინქრონიზაცია
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
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: 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: არცერთი
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_timer_interval: 1
transparent_data_encryption_options:
ჩართულია: ყალბი
საფლავის ქვა_გაფრთხილების_ზღურბლი: 1000
საფლავის ქვა_ჩავარდნის_ზღურბლი: 100000
batch_size_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_pressure_enabled: false
enable_materialized_views: მართალია
enable_sasi_indexes: true

GC პარამეტრები:

### CMS პარამეტრები-XX:+UseParNewGC
-XX:+გამოიყენეConcMarkSweepGC
-XX:+CMSParallelRemark ჩართულია
-XX:Survivor Ratio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiating OccupancyFraction=75
-XX:+UseCMSInitiating OccupancyOnly
-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-მდე, როდესაც რეგიონების რაოდენობა 1000-ზე მეტი იყო RegionServer-ზე)

არანაგულისხმევი HBase პარამეტრებიzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 წუთი
hbase.client.scanner.timeout.პერიოდი: 2 წუთი
hbase.master.handler.count: 10
hbase.regionserver.lease.period, 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.ზომა: 1 გიბაიტი
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.major compaction: 1 დღე(ები)
HBase Service Advanced Configuration Snippet (Safety Valve) 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:+CMSParallelRemark ჩართულია -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 წუთი
hbase.snapshot.region.timeout: 2 წუთი
hbase.snapshot.master.timeout.millis: 2 წუთი
HBase REST სერვერის მაქსიმალური ჟურნალის ზომა: 100 MiB
HBase REST სერვერის ლოგის ფაილის მაქსიმალური სარეზერვო ასლები: 5
HBase Thrift Server Max Log ზომა: 100 MiB
HBase Thrift სერვერის ლოგის ფაილის მაქსიმალური სარეზერვო ასლები: 5
Master Max Log ზომა: 100 MiB
ლოგის ფაილის სამაგისტრო მაქსიმალური მაქსიმალური სარეზერვო ასლები: 5
RegionServer Max Log ზომა: 100 MiB
RegionServer მაქსიმალური ჟურნალის ფაილების სარეზერვო ასლები: 5
HBase Active Master Detection Window: 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 Heap ზომა ბაიტებში: 1 გიბაიტი
HBase REST სერვერის ნაგულისხმევი ჯგუფი: 3 გიბაიტი
HBase Thrift სერვერის ნაგულისხმევი ჯგუფი: 3 გიბაიტი
Java Heap HBase Master-ის ზომა ბაიტებში: 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 ბაიტი (dataSize). საერთო ჯამში, ყოველ ჯერზე 100 მილიონი ჩანაწერი იწერებოდა და იკითხებოდა თითოეულ ცხრილში. ამავდროულად, თითოეულ მაგიდაზე დაიწერა/წაიკითხა 5 თემა (ძაფის ნომერი - thNum), რომელთაგან თითოეულმა გამოიყენა გასაღებების საკუთარი დიაპაზონი (თვლა = 5 მილიონი):

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) არ დააჩქარა მოვლენები. ამავდროულად, მორები სუფთაა და არაფერზე გეფიცები.

მონაცემები თანაბრად გადანაწილდა კვანძებში, სტატისტიკა ყველა კვანძიდან დაახლოებით ერთნაირი იყო.

ასე გამოიყურება ცხრილის სტატისტიკა ერთ-ერთი კვანძიდანKeyspace: ks
წაკითხვის რაოდენობა: 9383707
წაკითხვის შეყოვნება: 0.04287025042448576 ms
ჩაწერის რაოდენობა: 15462012
ჩაწერის შეყოვნება: 0.1350068438699957 ms
მომლოდინე გამოწურვები: 0
ცხრილი: t1
SST-ის რაოდენობა: 16
გამოყენებული ფართი (ლაივში): 148.59 MiB
გამოყენებული ფართი (სულ): 148.59 MiB
სნეპშოტების მიერ გამოყენებული სივრცე (სულ): 0 ბაიტი
გამოყენებული გამორთული მეხსიერება (სულ): 5.17 MiB
SSTable შეკუმშვის კოეფიციენტი: 0.5720989576459437
დანაყოფების რაოდენობა (შეფასება): 3970323
Memtable უჯრედების რაოდენობა: 0
Memtable მონაცემთა ზომა: 0 ბაიტი
გამოყენებული Memtable off heap მეხსიერება: 0 ბაიტი
Memtable გადამრთველის რაოდენობა: 5
წაკითხვის ადგილობრივი რაოდენობა: 2346045
ლოკალური წაკითხვის შეყოვნება: NaN ms
ადგილობრივი ჩაწერის რაოდენობა: 3865503
ჩაწერის ლოკალური შეყოვნება: NaN ms
მომლოდინე გამოწურვები: 0
პროცენტი გარემონტებული: 0.0
Bloom filter ცრუ დადებითი: 25
აყვავების ფილტრის ცრუ თანაფარდობა: 0.00000
გამოყენებული Bloom ფილტრის სივრცე: 4.57 MiB
Bloom filter off heap memory გამოყენებული: 4.57 MiB
გამოყენებული გროვის მეხსიერების ინდექსის შეჯამება: 590.02 KiB
გამოყენებული შეკუმშვის მეტამონაცემების გამორთვის გროვის მეხსიერება: 19.45 KiB
კომპაქტური დანაყოფის მინიმალური ბაიტი: 36
კომპაქტური დანაყოფის მაქსიმალური ბაიტი: 42
კომპაქტური დანაყოფის საშუალო ბაიტი: 42
საშუალო ცოცხალი უჯრედები თითო ნაჭერზე (ბოლო ხუთი წუთი): NaN
ცოცხალი უჯრედების მაქსიმალური რაოდენობა თითო ნაჭერზე (ბოლო ხუთი წუთი): 0
საშუალო საფლავის ქვები თითო ნაჭერზე (ბოლო ხუთი წუთი): NaN
საფლავის ქვების მაქსიმალური რაოდენობა თითო ნაჭერზე (ბოლო ხუთი წუთი): 0
ამოვარდნილი მუტაციები: 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 ასე დაბალი კითხვის ტესტებში.

აქედან გამომდინარეობს შემდეგი წინასწარი დასკვნები. თუ ვივარაუდებთ, რომ ტესტირების დროს მნიშვნელოვანი შეცდომები არ დაშვებულა, მაშინ კასანდრა ჰგავს კოლოსს თიხის ტერფებით. უფრო ზუსტად, როდესაც ის ერთ ფეხზე ბალანსს იკავებს, როგორც სტატიის დასაწყისში სურათზე, შედარებით კარგ შედეგს აჩვენებს, მაგრამ იმავე პირობებში ჩხუბის დროს ის აშკარად აგებს. ამავდროულად, ჩვენს აპარატურაზე CPU-ის დაბალი გამოყენების გათვალისწინებით, ვისწავლეთ ორი RegionServer HB-ის დაყენება თითო ჰოსტზე და ამით გავაორმაგეთ შესრულება. იმათ. რესურსების ათვისების გათვალისწინებით, CS-ის მდგომარეობა კიდევ უფრო სავალალოა.

რა თქმა უნდა, ეს ტესტები საკმაოდ სინთეზურია და აქ გამოყენებული მონაცემების რაოდენობა შედარებით მოკრძალებულია. შესაძლებელია, რომ ტერაბაიტებზე გადავიდეთ, სიტუაცია სხვაგვარად ყოფილიყო, მაგრამ სანამ HB-სთვის შეგვიძლია ტერაბაიტების ჩატვირთვა, CS-სთვის ეს პრობლემატური აღმოჩნდა. ის ხშირად აგდებდა OperationTimedOutException-ს ამ ტომებითაც, თუმცა პასუხის მოლოდინის პარამეტრები უკვე რამდენჯერმე გაიზარდა ნაგულისხმევთან შედარებით.

ვიმედოვნებ, რომ ერთობლივი ძალისხმევით ვიპოვით CS-ის ბოსტნეულს და თუ შევძელით მისი დაჩქარება, მაშინ პოსტის ბოლოს აუცილებლად დავამატებ ინფორმაციას საბოლოო შედეგების შესახებ.

UPD: ამხანაგების რჩევის წყალობით მოვახერხე კითხვის დაჩქარება. იყო:
159 ოპერაცია (644 მაგიდა, 4 ნაკადი, პარტია 5).
გამოგზავნილია:
.withLoadBalancingPolicy(new TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
და მე ვითამაშე ძაფების რაოდენობაზე. შედეგი შემდეგია:
4 მაგიდა, 100 ძაფი, პარტია = 1 (ცალი ცალი): 301 ოპ.
4 მაგიდა, 100 ძაფი, პარტია = 10: 447 ოპ.
4 მაგიდა, 100 ძაფი, პარტია = 100: 625 ოპ.

მოგვიანებით გამოვიყენებ სხვა ტიუნინგის რჩევებს, ჩავატარებ ტესტის სრულ ციკლს და დავამატებ შედეგებს პოსტის ბოლოს.

წყარო: www.habr.com