দুই ইয়াকোজুনার যুদ্ধ, বা ক্যাসান্দ্রা বনাম এইচবেস। Sberbank দলের অভিজ্ঞতা

এটি এমনকি একটি রসিকতাও নয়, মনে হচ্ছে এই বিশেষ ছবিটি সবচেয়ে সঠিকভাবে এই ডাটাবেসের সারমর্মকে প্রতিফলিত করে এবং শেষ পর্যন্ত এটি পরিষ্কার হবে কেন:

ডিবি-ইঞ্জিন র‍্যাঙ্কিং অনুসারে, দুটি সর্বাধিক জনপ্রিয় নোএসকিউএল কলামার ডেটাবেস হল ক্যাসান্ড্রা (এর পরে সিএস) এবং এইচবেস (এইচবি)।

ভাগ্যের ইচ্ছায়, Sberbank-এ আমাদের ডেটা লোডিং ম্যানেজমেন্ট টিম ইতিমধ্যেই কাজ করেছে অনেক আগে এবং HB এর সাথে ঘনিষ্ঠভাবে কাজ করে। এই সময়ে, আমরা এর শক্তি এবং দুর্বলতাগুলি বেশ ভালভাবে অধ্যয়ন করেছি এবং কীভাবে এটি রান্না করতে হয় তা শিখেছি। যাইহোক, CS আকারে একটি বিকল্পের উপস্থিতি সর্বদা আমাদের সন্দেহের সাথে নিজেদেরকে একটু কষ্ট দিতে বাধ্য করে: আমরা কি সঠিক পছন্দ করেছি? তাছাড়া ফলাফল তুলনা, DataStax দ্বারা সঞ্চালিত, তারা বলে যে CS সহজেই প্রায় একটি নিষ্পেষণ স্কোর সহ HB কে হারায়। অন্যদিকে, DataStax একটি আগ্রহী পক্ষ, এবং আপনার এটির জন্য তাদের কথা নেওয়া উচিত নয়। আমরা পরীক্ষার শর্তগুলি সম্পর্কে অল্প পরিমাণে তথ্য দ্বারাও বিভ্রান্ত হয়েছিলাম, তাই আমরা নিজেরাই খুঁজে বের করার সিদ্ধান্ত নিয়েছিলাম যে BigData NoSql-এর রাজা কে, এবং প্রাপ্ত ফলাফলগুলি খুব আকর্ষণীয় বলে প্রমাণিত হয়েছিল।

যাইহোক, সম্পাদিত পরীক্ষার ফলাফলের দিকে এগিয়ে যাওয়ার আগে, পরিবেশ কনফিগারেশনের উল্লেখযোগ্য দিকগুলি বর্ণনা করা প্রয়োজন। আসল বিষয়টি হ'ল সিএস এমন একটি মোডে ব্যবহার করা যেতে পারে যা ডেটা ক্ষতির অনুমতি দেয়। সেগুলো. এটি হল যখন শুধুমাত্র একটি সার্ভার (নোড) একটি নির্দিষ্ট কী-এর ডেটার জন্য দায়ী, এবং যদি কোনও কারণে এটি ব্যর্থ হয়, তাহলে এই কীটির মান হারিয়ে যাবে। অনেক কাজের জন্য এটি সমালোচনামূলক নয়, তবে ব্যাংকিং সেক্টরের জন্য এটি নিয়মের পরিবর্তে ব্যতিক্রম। আমাদের ক্ষেত্রে, নির্ভরযোগ্য স্টোরেজের জন্য ডেটার বেশ কয়েকটি কপি থাকা গুরুত্বপূর্ণ।

অতএব, ট্রিপল রেপ্লিকেশন মোডে শুধুমাত্র সিএস অপারেটিং মোড বিবেচনা করা হয়েছিল, যেমন নিম্নলিখিত পরামিতিগুলির সাথে কেসস্পেস তৈরি করা হয়েছিল:

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
জাভা সংস্করণ: 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
ভূমিকা_ব্যবস্থাপক: ক্যাসান্ড্রারোল ম্যানেজার
ভূমিকা_বৈধতা_এ_এমএস: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
বিভাজনকারী: org.apache.cassandra.dht.Murmur3Partitioner
ডেটা_ফাইল_ডিরেক্টরি:
- /data1/cassandra/data # প্রতিটি dataN ডিরেক্টরি একটি পৃথক ডিস্ক
- /ডেটা2/ক্যাসান্ড্রা/ডেটা
- /ডেটা3/ক্যাসান্ড্রা/ডেটা
- /ডেটা4/ক্যাসান্ড্রা/ডেটা
- /ডেটা5/ক্যাসান্ড্রা/ডেটা
- /ডেটা6/ক্যাসান্ড্রা/ডেটা
- /ডেটা7/ক্যাসান্ড্রা/ডেটা
- /ডেটা8/ক্যাসান্ড্রা/ডেটা
কমিটলগ_ডিরেক্টরি: /ডাটা9/ক্যাসান্ড্রা/কমিটলগ
cdc_enabled: মিথ্যা
disk_failure_policy: থামুন
কমিট_ব্যর্থতা_নীতি: থামুন
প্রস্তুত_বিবৃতি_ক্যাশে_সাইজ_এমবি:
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_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 চেষ্টা করেছে - কোন পার্থক্য লক্ষ্য করা যায়নি
সমবর্তী_বস্তুকৃত_দর্শন_লেখা: 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
স্টোরেজ_পোর্ট: 7000
ssl_storage_port: 7001
শোনার_ঠিকানা: *
সম্প্রচার_ঠিকানা: *
শোনা_অন_সম্প্রচার_ঠিকানা: সত্য
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: মিথ্যা
snapshot_before_compaction: মিথ্যা
auto_snapshot: সত্য
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
concurrent_compactors: 4
কমপ্যাকশন_থ্রুপুট_এমবি_পার_সেকেন্ড: 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
সার্ভার_এনক্রিপশন_বিকল্পসমূহ:
ইন্টারনোড_এনক্রিপশন: কোনোটিই নয়
ক্লায়েন্ট_এনক্রিপশন_বিকল্প:
সক্রিয়: মিথ্যা
ইন্টারনোড_কম্প্রেশন: ডিসি
inter_dc_tcp_nodelay: মিথ্যা
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: মিথ্যা
enable_scripted_user_defined_functions: মিথ্যা
windows_timer_interval: 1
স্বচ্ছ_ডেটা_এনক্রিপশন_বিকল্প:
সক্রিয়: মিথ্যা
সমাধিপাথর_ওয়ার্ন_থ্রেশহোল্ড: 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: মিথ্যা
enable_materialized_views: সত্য
enable_sasi_indexes: সত্য

GC সেটিংস:

### CMS সেটিংস-XX:+UseParNewGC
-XX:+ConcMarkSweepGC ব্যবহার করুন
-XX:+CMSParallelRemark সক্ষম
-XX:সারভাইভার রেশিও=8
-XX:MaxTenuringThreshold=1
-XX: CMSI শুরু করা অকুপেন্সি ফ্র্যাকশন=75
-XX:+UseCMSIশুরু করা শুধুমাত্র দখল
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMark সক্ষম
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSC ক্লাস আনলোডিং সক্ষম

jvm.options মেমরি 16Gb বরাদ্দ করা হয়েছিল (আমরা 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-এর বেশি ছিল)

অ-ডিফল্ট HBase পরামিতিzookeeper.session.timeout: 120000
hbase.rpc.টাইমআউট: 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-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-এর জন্য জাভা কনফিগারেশন বিকল্প:
-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 থ্রিফট সার্ভার সর্বোচ্চ লগ সাইজ: 100 MiB
HBase থ্রিফ্ট সার্ভার সর্বাধিক লগ ফাইল ব্যাকআপ: 5
মাস্টার ম্যাক্স লগ সাইজ: 100 MiB
মাস্টার সর্বোচ্চ লগ ফাইল ব্যাকআপ: 5
অঞ্চল সার্ভার সর্বোচ্চ লগ সাইজ: 100 MiB
RegionServer সর্বোচ্চ লগ ফাইল ব্যাকআপ: 5
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
ক্লায়েন্ট জাভা হিপ সাইজ বাইটে: 1 GiB
HBase REST সার্ভার ডিফল্ট গ্রুপ: 3 GiB
HBase থ্রিফট সার্ভার ডিফল্ট গ্রুপ: 3 GiB
বাইটে এইচবেস মাস্টারের জাভা হিপ সাইজ: 16 গিবি
বাইটে HBase RegionServer-এর জাভা হিপ সাইজ: 32 GiB

+চিড়িয়াখানার রক্ষক
maxClientCnxns: 601
maxSessionTimeout: 120000
টেবিল তৈরি করা:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', কম্প্রেশন => 'GZ'}

এখানে একটি গুরুত্বপূর্ণ বিষয় রয়েছে - ডেটাস্ট্যাক্সের বিবরণ HB টেবিল তৈরি করতে কতগুলি অঞ্চল ব্যবহার করা হয়েছিল তা বলে না, যদিও এটি বড় আয়তনের জন্য গুরুত্বপূর্ণ। অতএব, পরীক্ষার জন্য, পরিমাণ = 64 বেছে নেওয়া হয়েছিল, যা 640 গিগাবাইট পর্যন্ত সংরক্ষণের অনুমতি দেয়, যেমন মাঝারি আকারের টেবিল।

পরীক্ষার সময়, 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-এর সুবিধা এতটাই আশ্চর্যজনক যে সিএস সেটআপে কোনো ধরনের বাধা আছে বলে সন্দেহ রয়েছে। যাইহোক, গুগলিং এবং সবচেয়ে সুস্পষ্ট প্যারামিটার (যেমন সমবর্তী_লিখন বা মেমটেবল_হিপ_স্পেস_ইন_এমবি) অনুসন্ধান করা জিনিসগুলিকে গতি দেয়নি। একই সময়ে, লগগুলি পরিষ্কার এবং কিছুতেই শপথ করে না।

ডেটা নোড জুড়ে সমানভাবে বিতরণ করা হয়েছিল, সমস্ত নোডের পরিসংখ্যান প্রায় একই ছিল।

টেবিলের পরিসংখ্যান নোডগুলির একটি থেকে এটি দেখতে কেমনকীস্পেস: ks
পড়ার সংখ্যা: 9383707
লেটেন্সি পড়ুন: 0.04287025042448576 ms
সংখ্যা লিখুন: 15462012
লেটেন্সি লিখুন: 0.1350068438699957 ms
মুলতুবি ফ্লাশ: 0
টেবিল: t1
SSTable গণনা: 16
ব্যবহৃত স্থান (লাইভ): 148.59 MiB
ব্যবহৃত স্থান (মোট): 148.59 MiB
স্ন্যাপশট দ্বারা ব্যবহৃত স্থান (মোট): 0 বাইট
অফ হিপ মেমরি ব্যবহৃত (মোট): 5.17 MiB
SSTable কম্প্রেশন অনুপাত: 0.5720989576459437
পার্টিশনের সংখ্যা (আনুমানিক): 3970323
মেমেটেবল কোষের সংখ্যা: 0
মেমেটেবল ডেটা সাইজ: 0 বাইট
মেমটেবল অফ হিপ মেমরি ব্যবহৃত: 0 বাইট
মেমেটেবল সুইচের সংখ্যা: 5
স্থানীয় পঠিত সংখ্যা: 2346045
স্থানীয় পঠিত বিলম্বিতা: NaN ms
স্থানীয় লেখার সংখ্যা: 3865503
স্থানীয় লেখার বিলম্বিতা: NaN ms
মুলতুবি ফ্লাশ: 0
মেরামত করা শতাংশ: 0.0
ব্লুম ফিল্টার মিথ্যা ইতিবাচক: 25
ব্লুম ফিল্টার মিথ্যা অনুপাত: 0.00000
ব্লুম ফিল্টার স্পেস ব্যবহৃত: 4.57 MiB
ব্লুম ফিল্টার অফ হিপ মেমরি ব্যবহৃত: 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 এর ক্ষেত্রে, কারণটি পরিষ্কার - বেশিরভাগ ডেটা মেমরিতে, মেমস্টোরে হ্যাং হয় এবং কিছু ব্লকক্যাশে ক্যাশে থাকে। CS হিসাবে, এটি কীভাবে কাজ করে তা খুব স্পষ্ট নয়, তবে ডিস্ক পুনর্ব্যবহার করাও দৃশ্যমান নয়, তবে কেবলমাত্র, ক্যাশে row_cache_size_in_mb = 2048 সক্ষম করার চেষ্টা করা হয়েছিল এবং ক্যাশিং = {'keys': 'ALL', সেট করা হয়েছিল। 'rows_per_partition': '2000000'}, কিন্তু এটি এটিকে আরও খারাপ করেছে।

HB-তে অঞ্চলের সংখ্যা সম্পর্কে আবারও একটি গুরুত্বপূর্ণ বিষয় উল্লেখ করার মতো। আমাদের ক্ষেত্রে, মানটি 64 হিসাবে নির্দিষ্ট করা হয়েছিল। আপনি যদি এটি হ্রাস করেন এবং এটিকে সমান করেন, উদাহরণস্বরূপ, 4, তখন পড়ার সময়, গতি 2 গুণ কমে যায়। কারণ হল মেমস্টোর দ্রুত পূর্ণ হবে এবং ফাইলগুলি প্রায়শই ফ্লাশ করা হবে এবং পড়ার সময়, আরও ফাইলগুলিকে প্রক্রিয়া করতে হবে, যা HB এর জন্য একটি বরং জটিল অপারেশন। বাস্তব অবস্থার মধ্যে, এটি একটি প্রসপ্লিটিং এবং কম্প্যাক্টিফিকেশন কৌশলের মাধ্যমে চিন্তা করে চিকিত্সা করা যেতে পারে; বিশেষত, আমরা একটি স্ব-লিখিত ইউটিলিটি ব্যবহার করি যা আবর্জনা সংগ্রহ করে এবং পটভূমিতে ক্রমাগত HFiles সংকুচিত করে। এটা খুবই সম্ভব যে DataStax পরীক্ষার জন্য তারা প্রতি টেবিলে শুধুমাত্র 1টি অঞ্চল বরাদ্দ করেছে (যা সঠিক নয়) এবং এটি কিছুটা স্পষ্ট করবে কেন HB তাদের পড়ার পরীক্ষায় এত নিকৃষ্ট ছিল।

এ থেকে নিম্নলিখিত প্রাথমিক উপসংহার টানা হয়। ধরে নিচ্ছি যে পরীক্ষার সময় কোনও বড় ভুল করা হয়নি, তাহলে ক্যাসান্দ্রা দেখতে মাটির পায়ের সাথে একটি কলোসাসের মতো। আরও স্পষ্টভাবে, যখন তিনি একটি পায়ে ভারসাম্য বজায় রাখেন, যেমন নিবন্ধের শুরুতে ছবিতে, তিনি তুলনামূলকভাবে ভাল ফলাফল দেখান, কিন্তু একই অবস্থার অধীনে লড়াইয়ে তিনি সরাসরি হেরে যান। একই সময়ে, আমাদের হার্ডওয়্যারে কম CPU ব্যবহারকে বিবেচনায় নিয়ে, আমরা প্রতি হোস্টে দুটি RegionServer HB লাগাতে শিখেছি এবং এর ফলে কর্মক্ষমতা দ্বিগুণ হয়েছে। সেগুলো. সম্পদের ব্যবহার বিবেচনায় নিয়ে, সিএস-এর অবস্থা আরও শোচনীয়।

অবশ্যই, এই পরীক্ষাগুলি বেশ সিন্থেটিক এবং এখানে ব্যবহৃত ডেটার পরিমাণ তুলনামূলকভাবে শালীন। এটা সম্ভব যে যদি আমরা টেরাবাইটে স্যুইচ করি, পরিস্থিতি ভিন্ন হবে, কিন্তু যখন HB-এর জন্য আমরা টেরাবাইট লোড করতে পারি, CS-এর জন্য এটি সমস্যাযুক্ত হতে দেখা গেছে। এটি প্রায়শই এই ভলিউমগুলির সাথেও একটি OperationTimedOutException নিক্ষেপ করে, যদিও প্রতিক্রিয়ার জন্য অপেক্ষা করার পরামিতিগুলি ইতিমধ্যেই ডিফল্টগুলির তুলনায় কয়েকগুণ বৃদ্ধি করা হয়েছে।

আমি আশা করি যে যৌথ প্রচেষ্টার মাধ্যমে আমরা CS এর বাধাগুলি খুঁজে পাব এবং যদি আমরা এটিকে দ্রুততর করতে পারি, তাহলে পোস্টের শেষে আমি অবশ্যই চূড়ান্ত ফলাফল সম্পর্কে তথ্য যোগ করব।

ইউপিডি: কমরেডদের পরামর্শের জন্য ধন্যবাদ, আমি পড়ার গতি বাড়াতে পেরেছি। ছিল:
159 অপ্স (644 টেবিল, 4 স্ট্রীম, ব্যাচ 5)।
যুক্ত:
.WithLoadBalancing Policy(নতুন TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
এবং আমি থ্রেড সংখ্যা সঙ্গে প্রায় খেলা. ফলাফল নিম্নরূপ:
4টি টেবিল, 100টি থ্রেড, ব্যাচ = 1 (টুকরো টুকরো): 301 অপারেশন
4টি টেবিল, 100টি থ্রেড, ব্যাচ = 10: 447 অপ্স
4টি টেবিল, 100টি থ্রেড, ব্যাচ = 100: 625 অপ্স

পরে আমি অন্যান্য টিউনিং টিপস প্রয়োগ করব, একটি সম্পূর্ণ পরীক্ষা চক্র চালাব এবং পোস্টের শেষে ফলাফল যোগ করব।

উত্স: www.habr.com