ຮົບຂອງສອງ yakozuna, ຫຼື Cassandra vs HBase. ປະສົບການທີມ Sberbank

ນີ້ບໍ່ແມ່ນເລື່ອງຕະຫລົກ, ມັນເບິ່ງຄືວ່າຮູບພາບສະເພາະນີ້ສະທ້ອນໃຫ້ເຫັນເຖິງຄວາມສໍາຄັນຂອງຖານຂໍ້ມູນເຫຼົ່ານີ້ຢ່າງຖືກຕ້ອງ, ແລະໃນທີ່ສຸດມັນຈະແຈ້ງວ່າ:

ອີງຕາມ DB-Engines Ranking, ສອງຖານຂໍ້ມູນ NoSQL columnar ທີ່ນິຍົມທີ່ສຸດແມ່ນ Cassandra (ຕໍ່ໄປນີ້ແມ່ນ CS) ແລະ HBase (HB).

ໂດຍຄວາມປະສົງຂອງໂຊກຊະຕາ, ທີມງານຄຸ້ມຄອງການໂຫຼດຂໍ້ມູນຂອງພວກເຮົາຢູ່ Sberbank ໄດ້ແລ້ວ ຍາວກ່ອນຫນ້ານີ້ ແລະເຮັດວຽກຢ່າງໃກ້ຊິດກັບ HB. ໃນເວລານີ້, ພວກເຮົາໄດ້ສຶກສາຈຸດແຂງແລະຈຸດອ່ອນຂອງມັນໄດ້ດີແລະຮຽນຮູ້ວິທີການປຸງແຕ່ງມັນ. ຢ່າງໃດກໍ່ຕາມ, ການມີທາງເລືອກໃນຮູບແບບຂອງ CS ສະເຫມີບັງຄັບໃຫ້ພວກເຮົາທໍລະມານຕົວເຮົາເອງເລັກນ້ອຍດ້ວຍຄວາມສົງໃສ: ພວກເຮົາເລືອກທີ່ຖືກຕ້ອງບໍ? ຍິ່ງໄປກວ່ານັ້ນ, ຜົນໄດ້ຮັບ ການປຽບທຽບ, ປະຕິບັດໂດຍ DataStax, ພວກເຂົາເວົ້າວ່າ CS ເອົາຊະນະ HB ໄດ້ຢ່າງງ່າຍດາຍດ້ວຍຄະແນນ crushing. ໃນທາງກົງກັນຂ້າມ, DataStax ແມ່ນພາກສ່ວນທີ່ສົນໃຈ, ແລະທ່ານບໍ່ຄວນໃຊ້ຄໍາເວົ້າຂອງພວກເຂົາສໍາລັບມັນ. ພວກເຮົາຍັງສັບສົນກັບຂໍ້ມູນຈໍານວນຫນ້ອຍກ່ຽວກັບເງື່ອນໄຂການທົດສອບ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຕັດສິນໃຈຄົ້ນຫາຕົວເອງວ່າໃຜເປັນກະສັດຂອງ BigData NoSql, ແລະຜົນໄດ້ຮັບທີ່ໄດ້ຮັບແມ່ນຫນ້າສົນໃຈຫຼາຍ.

ຢ່າງໃດກໍ່ຕາມ, ກ່ອນທີ່ຈະກ້າວໄປສູ່ຜົນຂອງການທົດສອບທີ່ດໍາເນີນ, ມັນຈໍາເປັນຕ້ອງອະທິບາຍລັກສະນະທີ່ສໍາຄັນຂອງການຕັ້ງຄ່າສະພາບແວດລ້ອມ. ຄວາມຈິງແລ້ວແມ່ນວ່າ CS ສາມາດຖືກນໍາໃຊ້ໃນຮູບແບບທີ່ອະນຸຍາດໃຫ້ການສູນເສຍຂໍ້ມູນ. ເຫຼົ່ານັ້ນ. ນີ້ແມ່ນເວລາທີ່ມີພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍ (node) ຮັບຜິດຊອບສໍາລັບຂໍ້ມູນຂອງລະຫັດທີ່ແນ່ນອນ, ແລະຖ້າສໍາລັບເຫດຜົນບາງຢ່າງມັນລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນມູນຄ່າຂອງລະຫັດນີ້ຈະສູນເສຍໄປ. ສໍາລັບວຽກງານຈໍານວນຫຼາຍ, ນີ້ບໍ່ແມ່ນຄວາມສໍາຄັນ, ແຕ່ສໍາລັບຂະແຫນງການທະນາຄານນີ້ແມ່ນຂໍ້ຍົກເວັ້ນແທນທີ່ຈະເປັນກົດລະບຽບ. ໃນກໍລະນີຂອງພວກເຮົາ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະມີສໍາເນົາຂໍ້ມູນຈໍານວນຫນຶ່ງສໍາລັບການເກັບຮັກສາທີ່ເຊື່ອຖືໄດ້.

ດັ່ງນັ້ນ, ພຽງແຕ່ຮູບແບບການເຮັດວຽກ CS ໃນໂຫມດ replication triple ໄດ້ຖືກພິຈາລະນາ, i.e. ການສ້າງ casespace ໄດ້ຖືກປະຕິບັດດ້ວຍຕົວກໍານົດການດັ່ງຕໍ່ໄປນີ້:

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

ຕໍ່ໄປ, ມີສອງວິທີເພື່ອຮັບປະກັນລະດັບຄວາມສອດຄ່ອງທີ່ຕ້ອງການ. ກົດ​ລະ​ບຽບ​ທົ່ວ​ໄປ​:
NW + NR > RF

ຊຶ່ງຫມາຍຄວາມວ່າຈໍານວນຂອງການຢືນຢັນຈາກ nodes ໃນເວລາທີ່ຂຽນ (NW) ບວກກັບຈໍານວນຂອງການຢືນຢັນຈາກ nodes ໃນເວລາທີ່ອ່ານ (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 threads ແຕ່ລະຄົນ (40 ໃນຈໍານວນທັງຫມົດ), ຫຼັງຈາກນັ້ນການສູນເສຍ RF = 3 ແມ່ນແລ້ວ 2,7 ເທົ່າ (375 ວິນາທີທຽບກັບ 138).

ບາງທີນີ້ແມ່ນບາງສ່ວນເປັນຄວາມລັບຂອງການທົດສອບການໂຫຼດທີ່ປະສົບຜົນສໍາເລັດທີ່ດໍາເນີນໂດຍ DataStax ສໍາລັບ CS, ເພາະວ່າສໍາລັບ HB ຢູ່ໃນຈຸດຢືນຂອງພວກເຮົາການປ່ຽນແປງປັດໄຈການຈໍາລອງຈາກ 2 ຫາ 3 ບໍ່ມີຜົນໃດໆ. ເຫຼົ່ານັ້ນ. ແຜ່ນບໍ່ແມ່ນຄໍຂວດ HB ສໍາລັບການຕັ້ງຄ່າຂອງພວກເຮົາ. ຢ່າງໃດກໍຕາມ, ມີຫຼາຍ pitfalls ທີ່ນີ້, ເນື່ອງຈາກວ່າມັນຄວນຈະສັງເກດວ່າສະບັບຂອງພວກເຮົາຂອງ HB ໄດ້ຖືກ patched ເລັກນ້ອຍແລະ tweaked, ສະພາບແວດລ້ອມແມ່ນແຕກຕ່າງກັນຫມົດ, ແລະອື່ນໆ. ມັນຍັງເປັນມູນຄ່າທີ່ສັງເກດວ່າບາງທີຂ້ອຍພຽງແຕ່ບໍ່ຮູ້ວິທີການກະກຽມ CS ຢ່າງຖືກຕ້ອງແລະມີບາງວິທີທີ່ມີປະສິດທິພາບກວ່າທີ່ຈະເຮັດວຽກກັບມັນ, ແລະຂ້ອຍຫວັງວ່າພວກເຮົາຈະຊອກຫາໃນຄໍາເຫັນ. ແຕ່ສິ່ງທໍາອິດທໍາອິດ.

ການ​ທົດ​ສອບ​ທັງ​ຫມົດ​ໄດ້​ປະ​ຕິ​ບັດ​ຢູ່​ໃນ​ກຸ່ມ​ຮາດ​ແວ​ປະ​ກອບ​ດ້ວຍ 4 ເຄື່ອງ​ແມ່​ຂ່າຍ​, ແຕ່​ລະ​ຄົນ​ມີ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ກະທູ້.
ແຜ່ນ: 12 ຊິ້ນ SATA HDD
java ເວີຊັ່ນ: 1.8.0_111

CS ເວີຊັ່ນ: 3.11.5

cassandra.yml ພາລາມິເຕີnum_tokens: 256
hinted_handoff_enabled: ຈິງ
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 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
authenticator: AllowAllAuthenticator
authorizer: 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: ຢຸດ
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: 32
ຜູ້ໃຫ້ແກ່ນ:
- class_name: 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 GB - ມັນຊ້າກວ່າ
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: ບໍ່ຖືກຕ້ອງ
trickle_fsync_interval_in_kb: 10240
storage_port: 7000
ssl_storage_port: 7001
ທີ່ຢູ່ຟັງ: *
ທີ່ຢູ່ອອກອາກາດ: *
listen_on_broadcast_address: ຈິງ
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: ຖືກ
native_transport_port: 9042
start_rpc: ແທ້
rpc_dress: *
rpc_port: 9160
rpc_keepalive: ຈິງ
rpc_server_type: sync
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
concurrent_compactors: 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:
ເປີດໃຊ້ງານ: false
internode_compression: dc
inter_dc_tcp_nodelay: false
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:
ເປີດໃຊ້ງານ: false
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 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: ຈິງ

ການຕັ້ງຄ່າ GC:

### ການຕັ້ງຄ່າ CMS-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+UseCMSSIinitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordສະເໝີ
-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: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
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.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: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 ບັນທຶກຂໍ້ມູນບັນທຶກສູງສຸດ: 5
HBase Thrift Server Max ຂະໜາດບັນທຶກ: 100 MiB
HBase Thrift Server Maximum Log File Backups: 5
ຂະໜາດບັນທຶກ Master Max: 100 MiB
Master ບັນທຶກໄຟລ໌ສໍາຮອງສູງສຸດ: 5
RegionServer Max Log Size: 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
Region Mover Threads: 6
Client Java Heap Size ໃນ Bytes: 1 GiB
HBase REST Server Default Group: 3 GiB
HBase Thrift Server Default Group: 3 GiB
Java Heap ຂະຫນາດຂອງ HBase Master ໃນ Bytes: 16 GiB
Java Heap ຂະຫນາດຂອງ HBase RegionServer ໃນ Bytes: 32 GiB

+ 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 GB, i.e. ຕາ​ຕະ​ລາງ​ຂະ​ຫນາດ​ກາງ​.

ໃນເວລາຂອງການທົດສອບ, HBase ມີ 22 ພັນຕາຕະລາງແລະ 67 ພັນພາກພື້ນ (ນີ້ຈະເປັນການຕາຍສໍາລັບສະບັບ 1.2.0 ຖ້າບໍ່ແມ່ນສໍາລັບ patch ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ).

ໃນປັດຈຸບັນສໍາລັບລະຫັດ. ເນື່ອງຈາກມັນບໍ່ຊັດເຈນວ່າການຕັ້ງຄ່າໃດມີປະໂຫຍດຫຼາຍສໍາລັບຖານຂໍ້ມູນສະເພາະ, ການທົດສອບໄດ້ຖືກປະຕິບັດໃນການປະສົມປະສານຕ່າງໆ. ເຫຼົ່ານັ້ນ. ໃນບາງການທົດສອບ, 4 ຕາຕະລາງໄດ້ຖືກໂຫລດພ້ອມໆກັນ (ທັງຫມົດ 4 nodes ໄດ້ຖືກນໍາໃຊ້ສໍາລັບການເຊື່ອມຕໍ່). ໃນການທົດສອບອື່ນໆພວກເຮົາໄດ້ເຮັດວຽກກັບ 8 ຕາຕະລາງທີ່ແຕກຕ່າງກັນ. ໃນບາງກໍລະນີ, ຂະຫນາດ batch ແມ່ນ 100, ໃນຄົນອື່ນ 200 (ພາລາມິເຕີ batch - ເບິ່ງລະຫັດຂ້າງລຸ່ມນີ້). ຂະໜາດຂໍ້ມູນສຳລັບຄ່າແມ່ນ 10 bytes ຫຼື 100 bytes (dataSize). ໃນຈໍານວນທັງຫມົດ, 5 ລ້ານບັນທຶກໄດ້ຖືກຂຽນແລະອ່ານເຂົ້າໄປໃນຕາຕະລາງແຕ່ລະຄັ້ງ. ໃນເວລາດຽວກັນ, 5 ກະທູ້ໄດ້ຖືກຂຽນ / ອ່ານໃສ່ແຕ່ລະຕາຕະລາງ (thread number - 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) ບໍ່ໄດ້ເລັ່ງສິ່ງຕ່າງໆ. ໃນເວລາດຽວກັນ, ໄມ້ທ່ອນແມ່ນສະອາດແລະບໍ່ສາບານໃດໆ.

ຂໍ້​ມູນ​ໄດ້​ຖືກ​ແຈກ​ຢາຍ​ເທົ່າ​ທຽມ​ກັນ​ໃນ​ທົ່ວ​ຂໍ້​, ສະ​ຖິ​ຕິ​ຈາກ​ຂໍ້​ມູນ​ທັງ​ຫມົດ​ແມ່ນ​ປະ​ມານ​ດຽວ​ກັນ​.

ນີ້ແມ່ນສິ່ງທີ່ສະຖິຕິຕາຕະລາງເບິ່ງຄືວ່າຈາກຫນຶ່ງໃນ nodesKeyspace: ks
ຈຳນວນອ່ານ: 9383707
ອ່ານ Latency: 0.04287025042448576 ms
ຂຽນຈໍານວນ: 15462012
ຂຽນ Latency: 0.1350068438699957 ms
Flushes ທີ່ຍັງຄ້າງ: 0
ຕາຕະລາງ: t1
ຈຳນວນ SSTable: 16
ພື້ນທີ່ນຳໃຊ້ (ສົດ): 148.59 MiB
ພື້ນທີ່ໃຊ້ສອຍ (ທັງໝົດ): 148.59 MiB
ພື້ນທີ່ທີ່ໃຊ້ໂດຍພາບຖ່າຍ (ທັງໝົດ): 0 bytes
ໜ່ວຍຄວາມຈຳນອກ heap ໃຊ້ (ທັງໝົດ): 5.17 MiB
ອັດຕາສ່ວນການບີບອັດ SSTable: 0.5720989576459437
ຈໍານວນການແບ່ງສ່ວນ (ຄາດຄະເນ): 3970323
ຈຳນວນຕາລາງ Memtable: 0
ຂະໜາດຂໍ້ມູນ Memtable: 0 bytes
Memtable off heap memory ທີ່ໃຊ້: 0 bytes
ຈຳນວນສະວິດ Memtable: 5
ຈໍານວນການອ່ານທ້ອງຖິ່ນ: 2346045
latency ອ່ານໃນທ້ອງຖິ່ນ: NaN ms
ຈໍານວນການຂຽນທ້ອງຖິ່ນ: 3865503
latency ການຂຽນທ້ອງຖິ່ນ: NaN ms
ກະແສໄຟທີ່ຄ້າງຢູ່: 0
ເປີເຊັນການສ້ອມແປງ: 0.0
Bloom ການກັ່ນຕອງຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ: 25
Bloom filter ອັດຕາສ່ວນທີ່ບໍ່ຖືກຕ້ອງ: 0.00000
Bloom filter space ໃຊ້: 4.57 MiB
Bloom filter off heap memory ໃຊ້: 4.57 MiB
ດັດຊະນີສະຫຼຸບປິດຫນ່ວຍຄວາມຈໍາ heap ໃຊ້: 590.02 KiB
ການບີບອັດເມຕາເດຕາອອກຈາກໜ່ວຍຄວາມຈຳ heap ໃຊ້ແລ້ວ: 19.45 KiB
Compacted partition bytes ຕໍາ່ສຸດທີ່: 36
Compacted partition bytes ສູງສຸດ: 42
Compacted partition mean bytes: 42
ເຊລທີ່ມີຊີວິດສະເລ່ຍຕໍ່ເມັດ (ຫ້ານາທີສຸດທ້າຍ): NaN
ຈຸລັງທີ່ມີຊີວິດສູງສຸດຕໍ່ຊອຍ (ຫ້ານາທີສຸດທ້າຍ): 0
ຂຸມຝັງສົບສະເລ່ຍຕໍ່ຕ່ອນ (ຫ້ານາທີສຸດທ້າຍ): NaN
ຂຸມຝັງສົບສູງສຸດຕໍ່ຊິ້ນ (ຫ້ານາທີສຸດທ້າຍ): 0
ການກາຍພັນທີ່ຫຼຸດລົງ: 0 bytes

ຄວາມພະຍາຍາມທີ່ຈະຫຼຸດຜ່ອນຂະຫນາດຂອງ batch (ເຖິງແມ່ນວ່າການສົ່ງມັນສ່ວນບຸກຄົນ) ບໍ່ມີຜົນ, ມັນພຽງແຕ່ຮ້າຍແຮງກວ່າເກົ່າ. ມັນເປັນໄປໄດ້ວ່າໃນຄວາມເປັນຈິງນີ້ແມ່ນການປະຕິບັດສູງສຸດສໍາລັບ CS, ເນື່ອງຈາກວ່າຜົນໄດ້ຮັບສໍາລັບ CS ແມ່ນຄ້າຍຄືກັນກັບຂໍ້ມູນທີ່ໄດ້ຮັບສໍາລັບ DataStax - ປະມານຫຼາຍຮ້ອຍພັນການດໍາເນີນງານຕໍ່ວິນາທີ. ນອກຈາກນັ້ນ, ຖ້າພວກເຮົາເບິ່ງການນໍາໃຊ້ຊັບພະຍາກອນ, ພວກເຮົາຈະເຫັນວ່າ CS ໃຊ້ CPU ແລະແຜ່ນຫຼາຍກວ່າເກົ່າ:

ຕົວເລກສະແດງໃຫ້ເຫັນການນໍາໃຊ້ໃນລະຫວ່າງການດໍາເນີນການທົດສອບທັງຫມົດຕິດຕໍ່ກັນສໍາລັບຖານຂໍ້ມູນທັງສອງ.

ກ່ຽວກັບຜົນປະໂຫຍດການອ່ານທີ່ມີປະສິດທິພາບຂອງ HB. ໃນທີ່ນີ້ທ່ານສາມາດເຫັນໄດ້ວ່າສໍາລັບຖານຂໍ້ມູນທັງສອງ, ການນໍາໃຊ້ແຜ່ນໃນລະຫວ່າງການອ່ານແມ່ນຕໍ່າທີ່ສຸດ (ການທົດສອບການອ່ານແມ່ນສ່ວນສຸດທ້າຍຂອງຮອບວຽນການທົດສອບສໍາລັບແຕ່ລະຖານຂໍ້ມູນ, ຕົວຢ່າງສໍາລັບ CS ນີ້ແມ່ນຈາກ 15: 20 ຫາ 15: 40). ໃນກໍລະນີຂອງ HB, ເຫດຜົນແມ່ນຈະແຈ້ງ - ຂໍ້ມູນສ່ວນໃຫຍ່ແມ່ນຫ້ອຍຢູ່ໃນຫນ່ວຍຄວາມຈໍາ, ໃນ memstore, ແລະບາງບ່ອນຖືກເກັບໄວ້ໃນ blockcache. ສໍາລັບ CS, ມັນບໍ່ຊັດເຈນຫຼາຍວ່າມັນເຮັດວຽກແນວໃດ, ແຕ່ການລີໄຊເຄີນແຜ່ນແມ່ນຍັງບໍ່ສາມາດເຫັນໄດ້, ແຕ່ໃນກໍລະນີ, ໄດ້ພະຍາຍາມເປີດໃຊ້ cache row_cache_size_in_mb = 2048 ແລະຕັ້ງ cache = {'keys': 'ALL', 'rows_per_partition': ' 2000000'}, ແຕ່ນັ້ນເຮັດໃຫ້ມັນຮ້າຍແຮງຂຶ້ນເລັກນ້ອຍ.

ມັນຍັງມີມູນຄ່າການກ່າວເຖິງອີກເທື່ອຫນຶ່ງຈຸດສໍາຄັນກ່ຽວກັບຈໍານວນພາກພື້ນໃນ HB. ໃນກໍລະນີຂອງພວກເຮົາ, ມູນຄ່າໄດ້ຖືກກໍານົດເປັນ 64. ຖ້າທ່ານຫຼຸດລົງແລະເຮັດໃຫ້ມັນເທົ່າກັບ, ສໍາລັບການຍົກຕົວຢ່າງ, 4, ຫຼັງຈາກນັ້ນ, ເມື່ອອ່ານ, ຄວາມໄວຫຼຸດລົງ 2 ເທື່ອ. ເຫດຜົນແມ່ນວ່າ memstore ຈະຕື່ມຂໍ້ມູນໄວຂຶ້ນແລະໄຟລ໌ຈະຖືກ flushed ເລື້ອຍໆແລະເມື່ອອ່ານ, ໄຟລ໌ຫຼາຍຈະຕ້ອງຖືກປຸງແຕ່ງ, ເຊິ່ງເປັນການດໍາເນີນງານທີ່ສັບສົນຫຼາຍສໍາລັບ HB. ໃນສະພາບຕົວຈິງ, ນີ້ສາມາດປະຕິບັດໄດ້ໂດຍການຄິດໂດຍຜ່ານຍຸດທະສາດ presplitting ແລະຫນາແຫນ້ນ; ໂດຍສະເພາະ, ພວກເຮົານໍາໃຊ້ຜົນປະໂຫຍດທີ່ຂຽນດ້ວຍຕົນເອງທີ່ເກັບກໍາຂີ້ເຫຍື້ອແລະບີບອັດ HFiles ຢ່າງຕໍ່ເນື່ອງໃນພື້ນຫລັງ. ມັນເປັນໄປໄດ້ຂ້ອນຂ້າງວ່າສໍາລັບການທົດສອບ DataStax ພວກເຂົາຈັດສັນພຽງແຕ່ 1 ພາກພື້ນຕໍ່ຕາຕະລາງ (ເຊິ່ງບໍ່ຖືກຕ້ອງ) ແລະນີ້ອາດຈະຊີ້ແຈງບາງຢ່າງວ່າເປັນຫຍັງ HB ຈຶ່ງຕໍ່າກວ່າໃນການທົດສອບການອ່ານຂອງພວກເຂົາ.

ບົດສະຫຼຸບເບື້ອງຕົ້ນຕໍ່ໄປນີ້ແມ່ນມາຈາກນີ້. ໂດຍສົມມຸດວ່າບໍ່ມີຄວາມຜິດພາດອັນໃຫຍ່ຫຼວງໃດໆເກີດຂຶ້ນໃນລະຫວ່າງການທົດສອບ, ຫຼັງຈາກນັ້ນ Cassandra ເບິ່ງຄືວ່າເປັນຮູບໄຂ່ທີ່ມີຕີນຂອງດິນເຜົາ. ຫຼາຍທີ່ຊັດເຈນ, ໃນຂະນະທີ່ນາງດຸ່ນດ່ຽງຂາຫນຶ່ງ, ດັ່ງໃນຮູບໃນຕອນຕົ້ນຂອງບົດຄວາມ, ນາງສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີ, ແຕ່ໃນການຕໍ່ສູ້ພາຍໃຕ້ເງື່ອນໄຂດຽວກັນ, ນາງສູນເສຍທັນທີ. ໃນເວລາດຽວກັນ, ພິຈາລະນາການນໍາໃຊ້ CPU ຕ່ໍາໃນຮາດແວຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຮຽນຮູ້ທີ່ຈະປູກສອງ RegionServer HBs ຕໍ່ເຈົ້າພາບແລະດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ການປະຕິບັດໄດ້ສອງເທົ່າ. ເຫຼົ່ານັ້ນ. ​ໂດຍ​ຖື​ເອົາ​ການ​ນຳ​ໃຊ້​ຊັບ​ພະ​ຍາ​ກອນ, ສະພາບ​ການ​ຂອງ CS ​ແມ່ນ​ໜ້າ​ເສຍ​ໃຈ​ກວ່າ.

ແນ່ນອນ, ການທົດສອບເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງສັງເຄາະແລະຈໍານວນຂໍ້ມູນທີ່ຖືກນໍາໃຊ້ຢູ່ທີ່ນີ້ແມ່ນຂ້ອນຂ້າງເລັກນ້ອຍ. ມັນເປັນໄປໄດ້ວ່າຖ້າພວກເຮົາປ່ຽນເປັນ terabytes, ສະຖານະການຈະແຕກຕ່າງກັນ, ແຕ່ໃນຂະນະທີ່ສໍາລັບ HB ພວກເຮົາສາມາດໂຫລດ terabytes, ສໍາລັບ CS ນີ້ໄດ້ກາຍເປັນບັນຫາ. ມັນມັກຈະຖິ້ມ OperationTimedOutException ເຖິງແມ່ນວ່າມີປະລິມານເຫຼົ່ານີ້, ເຖິງແມ່ນວ່າຕົວກໍານົດການລໍຖ້າການຕອບໂຕ້ໄດ້ເພີ່ມຂຶ້ນຫຼາຍຄັ້ງເມື່ອທຽບໃສ່ກັບຄ່າເລີ່ມຕົ້ນ.

ຂ້າພະເຈົ້າຫວັງວ່າໂດຍຜ່ານຄວາມພະຍາຍາມຮ່ວມກັນພວກເຮົາຈະຊອກຫາຂໍ້ບົກຜ່ອງຂອງ CS ແລະຖ້າພວກເຮົາສາມາດເລັ່ງມັນໄດ້, ຫຼັງຈາກນັ້ນ, ໃນຕອນທ້າຍຂອງການຕອບ, ຂ້າພະເຈົ້າຈະເພີ່ມຂໍ້ມູນກ່ຽວກັບຜົນໄດ້ຮັບສຸດທ້າຍຢ່າງແນ່ນອນ.

UPD: ຂໍຂອບໃຈກັບຄໍາແນະນໍາຂອງ comrades, ຂ້າພະເຈົ້າໄດ້ຈັດການເລັ່ງການອ່ານ. ແມ່ນ:
159 ops (644 ຕາຕະລາງ, 4 ສາຍ, batch 5).
ເພີ່ມ:
.withLoadBalancingPolicy(New TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
ແລະຂ້າພະເຈົ້າໄດ້ຫຼິ້ນປະມານກັບຈໍານວນຂອງກະທູ້. ຜົນໄດ້ຮັບແມ່ນດັ່ງຕໍ່ໄປນີ້:
4 ຕາຕະລາງ, 100 ກະທູ້, batch = 1 (ສິ້ນໂດຍສິ້ນ): 301 ops
4 ຕາຕະລາງ, 100 ກະທູ້, batch = 10: 447 ops
4 ຕາຕະລາງ, 100 ກະທູ້, batch = 100: 625 ops

ຕໍ່ມາຂ້າພະເຈົ້າຈະນໍາໃຊ້ຄໍາແນະນໍາການປັບແຕ່ງອື່ນໆ, ດໍາເນີນການຮອບວຽນການທົດສອບຢ່າງເຕັມທີ່ແລະເພີ່ມຜົນໄດ້ຮັບໃນຕອນທ້າຍຂອງການຕອບ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com