សមរភូមិយ៉ាកូហ្សូណាពីរ ឬ Cassandra vs HBase ។ បទពិសោធន៍ក្រុម Sberbank

នេះមិនមែនជារឿងកំប្លែងនោះទេ វាហាក់បីដូចជារូបភាពពិសេសនេះឆ្លុះបញ្ចាំងយ៉ាងត្រឹមត្រូវបំផុតអំពីខ្លឹមសារនៃមូលដ្ឋានទិន្នន័យទាំងនេះ ហើយនៅទីបញ្ចប់វានឹងច្បាស់ថាហេតុអ្វីបានជា៖

យោងតាម ​​DB-Engines Ranking មូលដ្ឋានទិន្នន័យ NoSQL columnar ដែលពេញនិយមបំផុតគឺ Cassandra (តទៅនេះ CS) និង HBase (HB) ។

តាមឆន្ទៈនៃជោគវាសនា ក្រុមគ្រប់គ្រងការផ្ទុកទិន្នន័យរបស់យើងនៅ Sberbank មានរួចហើយ давно និងធ្វើការយ៉ាងជិតស្និទ្ធជាមួយ HB ។ ក្នុងអំឡុងពេលនេះ យើងបានសិក្សាពីចំណុចខ្លាំង និងចំណុចខ្សោយរបស់វាយ៉ាងល្អ ហើយរៀនពីរបៀបចំអិនវា។ ទោះជាយ៉ាងណាក៏ដោយ វត្តមាននៃជម្រើសមួយនៅក្នុងទម្រង់នៃ CS តែងតែបង្ខំយើងឱ្យធ្វើទារុណកម្មខ្លួនយើងបន្តិចជាមួយនឹងការសង្ស័យថា តើយើងបានជ្រើសរើសត្រឹមត្រូវទេ? លើសពីនេះទៅទៀតលទ្ធផល ការប្រៀបធៀបដែលអនុវត្តដោយ DataStax ពួកគេបាននិយាយថា CS ងាយនឹងយកឈ្នះ HB ដោយស្ទើរតែពិន្ទុកំទេច។ ម្យ៉ាងវិញទៀត DataStax គឺជាភាគីដែលចាប់អារម្មណ៍ ហើយអ្នកមិនគួរយកពាក្យរបស់ពួកគេសម្រាប់វាទេ។ យើងក៏មានការភ័ន្តច្រឡំផងដែរដោយចំនួនព័ត៌មានតិចតួចអំពីលក្ខខណ្ឌនៃការធ្វើតេស្ត ដូច្នេះយើងសម្រេចចិត្តស្វែងរកដោយខ្លួនឯងថានរណាជាស្តេច BigData NoSql ហើយលទ្ធផលដែលទទួលបានគឺគួរឱ្យចាប់អារម្មណ៍ណាស់។

ទោះជាយ៉ាងណាក៏ដោយ មុននឹងបន្តទៅលទ្ធផលនៃការធ្វើតេស្តដែលបានអនុវត្ត វាចាំបាច់ត្រូវពណ៌នាអំពីទិដ្ឋភាពសំខាន់ៗនៃការកំណត់រចនាសម្ព័ន្ធបរិស្ថាន។ ការពិតគឺថា CS អាចត្រូវបានប្រើនៅក្នុងរបៀបដែលអនុញ្ញាតឱ្យបាត់បង់ទិន្នន័យ។ ទាំងនោះ។ នេះគឺជាពេលដែលម៉ាស៊ីនមេតែមួយ (ថ្នាំង) ទទួលខុសត្រូវចំពោះទិន្នន័យនៃសោជាក់លាក់មួយ ហើយប្រសិនបើហេតុផលមួយចំនួនវាបរាជ័យ នោះតម្លៃនៃសោនេះនឹងបាត់បង់។ សម្រាប់ការងារជាច្រើននេះមិនសំខាន់ទេ ប៉ុន្តែសម្រាប់វិស័យធនាគារ នេះគឺជាការលើកលែងជាជាងច្បាប់។ ក្នុងករណីរបស់យើង វាមានសារៈសំខាន់ណាស់ក្នុងការមានច្បាប់ចម្លងទិន្នន័យជាច្រើនសម្រាប់ការផ្ទុកដែលអាចទុកចិត្តបាន។

ដូច្នេះមានតែរបៀបប្រតិបត្តិការ CS នៅក្នុងរបៀបចម្លងបីដងប៉ុណ្ណោះដែលត្រូវបានពិចារណា ពោលគឺឧ។ ការបង្កើត casespace ត្រូវបានអនុវត្តជាមួយនឹងប៉ារ៉ាម៉ែត្រដូចខាងក្រោម:

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 ធ្វើការលើគោលការណ៍ស្រដៀងគ្នា i.e. ការប្រៀបធៀបបែបនេះនឹងមានភាពយុត្តិធម៌ជាង។

វាគួរតែត្រូវបានកត់សម្គាល់ថា 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.40GHz 64 ខ្សែ។
ថាស: 12 បំណែក SATA HDD
កំណែ java៖ 1.8.0_111

កំណែ CS: 3.11.5

ប៉ារ៉ាម៉ែត្រ cassandra.ymlnum_tokens៖ ២៥៦
hinted_handoff_enabled៖ ពិត
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads៖ ២
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
អ្នកគ្រប់គ្រងតួនាទី៖ CassandraRoleManager
តួនាទី_សុពលភាព_ក្នុង_ms៖ ២០០០
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៖ បញ្ឈប់
Prepare_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៖ ៣២
អ្នកផ្តល់គ្រាប់ពូជ៖
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
ប៉ារ៉ាម៉ែត្រ:
- គ្រាប់៖ "*,*"
concurrent_reads: 256 # ព្យាយាម 64 - មិនមានភាពខុសគ្នាត្រូវបានកត់សម្គាល់ទេ។
concurrent_writes: 256 # ព្យាយាម 64 - មិនមានភាពខុសគ្នាត្រូវបានកត់សម្គាល់ទេ។
concurrent_counter_writes: 256 # ព្យាយាម 64 - មិនមានភាពខុសគ្នាត្រូវបានកត់សម្គាល់ទេ។
concurrent_materialized_view_writes៖ ៣២
memtable_heap_space_in_mb: 2048 # ព្យាយាម 16 GB - វាយឺតជាង
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb៖
index_summary_resize_interval_in_minutes៖ ៦០
trickle_fsync៖ មិនពិត
trickle_fsync_interval_in_kb: 10240
storage_port: 7000
ssl_storage_port: 7001
listen_អាសយដ្ឋាន៖ *
អាសយដ្ឋានផ្សាយ៖ *
listen_on_broadcast_អាសយដ្ឋាន៖ ពិត
internode_authenticator៖ org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport៖ ពិត
native_transport_port៖ ៩០៤២
start_rpc៖ ពិត
rpc_អាសយដ្ឋាន៖ *
rpc_port: 9160
rpc_keepalive៖ ពិត
rpc_server_type៖ ធ្វើសមកាលកម្ម
thrift_framed_transport_size_in_mb: ១៥
incremental_backups៖ មិនពិត
snapshot_before_compaction៖ មិនពិត
auto_snapshot៖ ពិត
column_index_size_in_kb៖ ៦៤
column_index_cache_size_in_kb៖ ២
concurrent_compactors៖ ៤
compaction_throughput_mb_per_sec៖ ១៦០០
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៖ មិនពិត
enable_scripted_user_defined_functions៖ មិនពិត
windows_timer_interval៖ ១
transparent_data_encryption_options៖
បានបើក៖ មិនពិត
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
batch_size_warn_threshold_in_kb៖ ២០០
batch_size_fail_threshold_in_kb៖ ២៥០
unlogged_batch_across_partitions_warn_threshold៖ ១០
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms៖ ១០០០
back_pressure_enabled៖ មិនពិត
enable_materialized_views៖ ពិត
enable_sasi_indexes៖ ពិត

ការកំណត់ GC៖

### ការកំណត់ CMS-XX:+UseParNewGC
-XX:+ប្រើConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+ប្រើCSI InitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

អង្គចងចាំ jvm.options ត្រូវបានបែងចែក 16Gb (យើងក៏បានសាកល្បង 32 Gb ដែរ វាមិនមានអ្វីប្លែកទេ)។

តារាងត្រូវបានបង្កើតឡើងដោយពាក្យបញ្ជា៖

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.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៖ ២០០
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier៖ ៦
hbase.hstore.compactionThreshold៖ ៥
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 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.timeout 3600000
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: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 MiB
ម៉ាស៊ីនមេ HBase REST ការបម្រុងទុកឯកសារកំណត់ហេតុអតិបរមា៖ ៥
ទំហំកំណត់ហេតុអតិបរមារបស់ម៉ាស៊ីនមេ HBase Thrift: 100 MiB
ម៉ាស៊ីនមេ HBase Thrift ការបម្រុងទុកឯកសារកំណត់ហេតុអតិបរមា៖ ៥
ទំហំ Master Max Log: 100 MiB
ការបម្រុងទុកឯកសារកំណត់ហេតុអតិបរមា Master: 5
RegionServer Max Log Size: 100 MiB
RegionServer ការបម្រុងទុកឯកសារកំណត់ហេតុអតិបរមា៖ ៥
HBase Active Master Detection Window: 4 នាទី
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 មិល្លីវិនាទី
hbase.rest.threads.min: ៨
hbase.rest.threads.max: 150
ការពិពណ៌នាឯកសារដំណើរការអតិបរមា៖ 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads៖ ៣០
hbase.master.executor.closeregion.threads៖ ៣០
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: ៦
hbase.ipc.server.read.threadpool.size: 20
ខ្សែស្រឡាយផ្លាស់ប្តូរតំបន់៖ ៦
Client Java Heap ទំហំគិតជាបៃ៖ 1 GiB
HBase REST Server Default Group: 3 GiB
HBase Thrift Server Default Group: 3 GiB
ទំហំ Java Heap នៃ HBase Master ជាបៃ: 16 GiB
ទំហំ Java Heap នៃ HBase RegionServer ជាបៃ: 32 GiB

+ ZooKeeper
maxClientCnxns៖ ៦០១
អតិបរមាSessionTimeout៖ 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 GB ពោលគឺឧ។ តារាងទំហំមធ្យម។

នៅពេលធ្វើតេស្ត HBase មានតុចំនួន 22 ពាន់ និងតំបន់ចំនួន 67 ពាន់ (វានឹងមានគ្រោះថ្នាក់សម្រាប់កំណែ 1.2.0 ប្រសិនបើមិនមែនសម្រាប់បំណះដែលបានរៀបរាប់ខាងលើ) ។

ឥឡូវនេះសម្រាប់លេខកូដ។ ដោយសារវាមិនច្បាស់ថាការកំណត់រចនាសម្ព័ន្ធណាដែលមានប្រយោជន៍ជាងសម្រាប់មូលដ្ឋានទិន្នន័យជាក់លាក់ ការធ្វើតេស្តត្រូវបានអនុវត្តនៅក្នុងបន្សំផ្សេងៗ។ ទាំងនោះ។ នៅក្នុងការធ្វើតេស្តមួយចំនួន តារាងចំនួន 4 ត្រូវបានផ្ទុកក្នុងពេលដំណាលគ្នា (ថ្នាំងទាំង 4 ត្រូវបានប្រើសម្រាប់ការតភ្ជាប់) ។ នៅក្នុងការធ្វើតេស្តផ្សេងទៀត យើងបានធ្វើការជាមួយតុចំនួន 8 ផ្សេងគ្នា។ ក្នុងករណីខ្លះទំហំបាច់គឺ 100 និងផ្សេងទៀត 200 (ប៉ារ៉ាម៉ែត្របាច់ - សូមមើលកូដខាងក្រោម)។ ទំហំទិន្នន័យសម្រាប់តម្លៃគឺ 10 បៃ ឬ 100 បៃ (ទំហំទិន្នន័យ)។ ជាសរុប កំណត់ត្រាចំនួន 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.04287025042448576 ms
ចំនួនសរសេរ: 15462012
សរសេរ Latency៖ 0.1350068438699957 ms
ទឹកហូរមិនទាន់សម្រេច៖ ០
តារាង: t1
ចំនួន SSTable: 16
ទំហំដែលបានប្រើ (ផ្ទាល់)៖ 148.59 MiB
ទំហំដែលបានប្រើ (សរុប): 148.59 MiB
ចន្លោះដែលប្រើដោយរូបថត (សរុប)៖ 0 បៃ
អង្គ​ចងចាំ​បិទ​ហ៊ាប​បាន​ប្រើ (សរុប)៖ 5.17 មេកាបៃ
សមាមាត្រការបង្ហាប់ SSTable: 0.5720989576459437
ចំនួនភាគថាស (ប៉ាន់ស្មាន): 3970323
ចំនួន​ក្រឡា Memtable៖ 0
ទំហំទិន្នន័យដែលអាចចងចាំបាន៖ 0 បៃ
Memtable off heap memory បានប្រើ៖ 0 bytes
ចំនួនកុងតាក់ Memtable៖ ៥
ចំនួនអានក្នុងស្រុក៖ 2346045
ភាពយឺតនៃការអានក្នុងស្រុក៖ NaN ms
ចំនួនសរសេរក្នុងស្រុក៖ 3865503
ភាពយឺតនៃការសរសេរក្នុងស្រុក៖ NaN ms
ទឹកហូរមិនទាន់សម្រេច៖ ០
ភាគរយជួសជុល៖ 0.0
Bloom ច្រោះផលវិជ្ជមានមិនពិត៖ ២៥
Bloom filter ratio មិនពិត៖ 0.00000
ទំហំតម្រង Bloom បានប្រើ៖ 4.57 MiB
Bloom filter off heap memory ដែលប្រើ៖ 4.57 MiB
លិបិក្រមសង្ខេបបិទអង្គចងចាំ heap បានប្រើ៖ 590.02 KiB
ទិន្នន័យមេតានៃការបង្ហាប់បិទអង្គចងចាំ heap បានប្រើ៖ 19.45 KiB
ភាគថាសបង្រួមអប្បបរមា៖ ៣៦
បង្រួមភាគថាសអតិបរមា៖ ៤២
ភាគថាសបង្រួមមធ្យម៖ ៤២
កោសិកាបន្តផ្ទាល់ជាមធ្យមក្នុងមួយចំណិត (ប្រាំនាទីចុងក្រោយ): NaN
កោសិកាបន្តផ្ទាល់អតិបរមាក្នុងមួយចំណិត (ប្រាំនាទីចុងក្រោយ)៖ 0
ថ្មផ្នូរជាមធ្យមក្នុងមួយចំណិត (ប្រាំនាទីចុងក្រោយ): NaN
ថ្មផ្នូរអតិបរមាក្នុងមួយចំណិត (ប្រាំនាទីចុងក្រោយ): 0
ការផ្លាស់ប្តូរដែលបានទម្លាក់៖ 0 បៃ

ការប៉ុនប៉ងដើម្បីកាត់បន្ថយទំហំនៃបាច់ (សូម្បីតែបញ្ជូនវាដោយឡែកពីគ្នា) មិនមានផលប៉ះពាល់ទេ វាកាន់តែអាក្រក់ទៅៗ។ វាអាចទៅរួចដែលថាតាមពិតនេះគឺពិតជាដំណើរការអតិបរមាសម្រាប់ CS ចាប់តាំងពីលទ្ធផលដែលទទួលបានសម្រាប់ CS គឺស្រដៀងគ្នាទៅនឹងលទ្ធផលដែលទទួលបានសម្រាប់ DataStax - ប្រហែលរាប់រយរាប់ពាន់ប្រតិបត្តិការក្នុងមួយវិនាទី។ លើសពីនេះ ប្រសិនបើយើងក្រឡេកមើលការប្រើប្រាស់ធនធាន យើងនឹងឃើញថា CS ប្រើប្រាស់ CPU និង Disk ជាច្រើនទៀត៖

តួលេខបង្ហាញពីការប្រើប្រាស់ក្នុងអំឡុងពេលដំណើរការនៃការធ្វើតេស្តទាំងអស់ក្នុងមួយជួរសម្រាប់មូលដ្ឋានទិន្នន័យទាំងពីរ។

ទាក់ទងនឹងអត្ថប្រយោជន៍នៃការអានដ៏មានឥទ្ធិពលរបស់ HB ។ នៅទីនេះអ្នកអាចមើលឃើញថាសម្រាប់មូលដ្ឋានទិន្នន័យទាំងពីរ ការប្រើប្រាស់ថាសកំឡុងពេលអានគឺទាបខ្លាំង (ការធ្វើតេស្តអានគឺជាផ្នែកចុងក្រោយនៃវដ្តសាកល្បងសម្រាប់មូលដ្ឋានទិន្នន័យនីមួយៗ ឧទាហរណ៍សម្រាប់ CS នេះគឺចាប់ពីម៉ោង 15:20 ដល់ម៉ោង 15:40)។ ក្នុងករណី HB ហេតុផលគឺច្បាស់ - ទិន្នន័យភាគច្រើនព្យួរនៅក្នុងអង្គចងចាំក្នុង memstore ហើយខ្លះត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ក្នុង blockcache ។ ចំពោះ CS វាមិនច្បាស់ថាវាដំណើរការយ៉ាងណានោះទេ ប៉ុន្តែការកែច្នៃថាសក៏មិនអាចមើលឃើញដែរ ប៉ុន្តែក្នុងករណីមានការប៉ុនប៉ងមួយត្រូវបានធ្វើឡើងដើម្បីបើកដំណើរការឃ្លាំងសម្ងាត់ row_cache_size_in_mb = 2048 ហើយកំណត់ឃ្លាំងសម្ងាត់ = {'keys': 'ALL', 'rows_per_partition': ' 2000000'} ប៉ុន្តែវាបានធ្វើឱ្យវាកាន់តែអាក្រក់បន្តិច។

វាក៏មានតម្លៃផងដែរក្នុងការនិយាយម្តងទៀតនូវចំណុចសំខាន់មួយអំពីចំនួនតំបន់នៅក្នុង HB ។ ក្នុងករណីរបស់យើងតម្លៃត្រូវបានបញ្ជាក់ជា 64 ។ ប្រសិនបើយើងបន្ថយវាហើយធ្វើឱ្យវាស្មើនឹងឧទាហរណ៍ 4 បន្ទាប់មកនៅពេលអានល្បឿនធ្លាក់ចុះ 2 ដង។ ហេតុផលគឺថា memstore នឹងបំពេញលឿនជាងមុន ហើយឯកសារនឹងត្រូវបានហូរញឹកញាប់ជាងមុន ហើយនៅពេលអាន ឯកសារកាន់តែច្រើននឹងត្រូវដំណើរការ ដែលជាប្រតិបត្តិការដ៏ស្មុគស្មាញសម្រាប់ HB ។ នៅក្នុងលក្ខខណ្ឌជាក់ស្តែង វាអាចត្រូវបានព្យាបាលដោយការគិតតាមរយៈយុទ្ធសាស្ត្រកំណត់ជាមុន និងបង្រួម ជាពិសេសយើងប្រើឧបករណ៍ប្រើប្រាស់ដែលសរសេរដោយខ្លួនឯងដែលប្រមូលសំរាម និងបង្រួម HFiles ជានិច្ចនៅក្នុងផ្ទៃខាងក្រោយ។ វាអាចទៅរួចដែលថាសម្រាប់ការធ្វើតេស្ត DataStax ពួកគេបានបែងចែកតែ 1 តំបន់ក្នុងមួយតារាង (ដែលមិនត្រឹមត្រូវ) ហើយនេះនឹងបញ្ជាក់បានខ្លះថាហេតុអ្វីបានជា HB អន់ជាងក្នុងការធ្វើតេស្តអានរបស់ពួកគេ។

ការសន្និដ្ឋានបឋមខាងក្រោមត្រូវបានដកចេញពីនេះ។ ដោយសន្មតថាមិនមានកំហុសធំណាមួយត្រូវបានធ្វើឡើងក្នុងអំឡុងពេលធ្វើតេស្តនោះ Cassandra មើលទៅដូចជា colossus ជាមួយនឹងជើងនៃដីឥដ្ឋ។ ច្បាស់ជាងនេះទៅទៀត ខណៈពេលដែលនាងមានតុល្យភាពនៅលើជើងម្ខាង ដូចនៅក្នុងរូបភាពនៅដើមអត្ថបទ នាងបង្ហាញលទ្ធផលល្អ ប៉ុន្តែនៅក្នុងការប្រយុទ្ធក្រោមលក្ខខណ្ឌដូចគ្នា នាងចាញ់ទាំងស្រុង។ ក្នុងពេលជាមួយគ្នានេះ ដោយគិតពីការប្រើប្រាស់ស៊ីភីយូទាបនៅលើផ្នែករឹងរបស់យើង យើងបានរៀនដាំ RegionServer HBs ពីរក្នុងមួយម៉ាស៊ីន ហើយដោយហេតុនេះអាចបង្កើនប្រសិទ្ធភាពទ្វេដង។ ទាំងនោះ។ ដោយគិតពីការប្រើប្រាស់ធនធាន ស្ថានភាពសម្រាប់ CS គឺកាន់តែអាក្រក់ទៅៗ។

ជាការពិតណាស់ ការធ្វើតេស្តទាំងនេះគឺពិតជាសំយោគ ហើយចំនួនទិន្នន័យដែលត្រូវបានប្រើនៅទីនេះគឺតិចតួច។ វាអាចទៅរួចដែលថាប្រសិនបើយើងប្តូរទៅ terabytes នោះស្ថានភាពនឹងខុសគ្នា ប៉ុន្តែសម្រាប់ HB យើងអាចផ្ទុក terabytes សម្រាប់ CS វាប្រែជាមានបញ្ហា។ ជារឿយៗវាបានបោះចោល OperationTimedOutException ទោះបីជាមានភាគទាំងនេះក៏ដោយ ទោះបីជាប៉ារ៉ាម៉ែត្រសម្រាប់ការរង់ចាំការឆ្លើយតបត្រូវបានកើនឡើងច្រើនដងរួចមកហើយ បើប្រៀបធៀបទៅនឹងលំនាំដើមក៏ដោយ។

ខ្ញុំសង្ឃឹមថា តាមរយៈកិច្ចខិតខំប្រឹងប្រែងរួមគ្នា យើងនឹងរកឃើញការរាំងស្ទះរបស់ CS ហើយប្រសិនបើយើងអាចពន្លឿនវា នោះនៅចុងបញ្ចប់នៃប្រកាស ខ្ញុំនឹងបន្ថែមព័ត៌មានអំពីលទ្ធផលចុងក្រោយ។

UPD: អរគុណចំពោះការណែនាំរបស់សមមិត្ត ខ្ញុំបានគ្រប់គ្រងការអានលឿនជាងមុន។ គឺ៖
159 ops (644 តារាង, 4 ស្ទ្រីម, បាច់ 5) ។
:обавлено:
.withLoadBalancingPolicy(New TokenAwarePolicy(DCAwareRoundRobinPolicy.builder(.build())))
ហើយខ្ញុំបានលេងជុំវិញជាមួយនឹងចំនួននៃខ្សែស្រឡាយ។ លទ្ធផលមានដូចខាងក្រោម៖
4 តុ, 100 ខ្សែស្រឡាយ, បាច់ = 1 (ដុំមួយដុំ): 301 ops
4 តារាង, 100 ខ្សែស្រឡាយ, បាច់ = 10: 447 ops
4 តារាង, 100 ខ្សែស្រឡាយ, បាច់ = 100: 625 ops

ក្រោយមកខ្ញុំនឹងអនុវត្តគន្លឹះកែសំរួលផ្សេងទៀត ដំណើរការវដ្តសាកល្បងពេញលេញ និងបន្ថែមលទ្ធផលនៅចុងបញ្ចប់នៃប្រកាស។

ប្រភព: www.habr.com