دا حتی یوه ټوکه هم نه ده، داسې بریښي چې دا ځانګړی انځور په سمه توګه د دې ډیټابیسونو جوهر منعکس کوي، او په پای کې به روښانه شي چې ولې:
د DB-Engines Ranking په وینا، دوه خورا مشهور NoSQL کالمر ډیټابیسونه کاسیندرا (له دې وروسته 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 په ورته اصولو کار کوي، د بیلګې په توګه. دا ډول پرتله کول به ډیر عادلانه وي.
دا باید په یاد ولرئ چې ډیټاسټیکس د دوی په مطالعې کې برعکس ترسره کړی، دوی د CS او HB دواړو لپاره RF = 1 ټاکلی (د وروستي لپاره د HDFS ترتیباتو بدلولو سره). دا واقعیا یو مهم اړخ دی ځکه چې پدې قضیه کې د CS فعالیت باندې تاثیر خورا لوی دی. د مثال په توګه، لاندې انځور په CS کې د ډیټا بارولو لپاره اړین وخت زیاتوالی ښیې:
دلته موږ لاندې ګورو: څومره چې سیالي کونکي تارونه ډیټا لیکي ، هومره وخت نیسي. دا طبیعي ده، مګر دا مهمه ده چې د RF=3 لپاره د فعالیت تخریب د پام وړ لوړ وي. په بل عبارت، که موږ 4 تارونه په 5 جدولونو کې ولیکو (په ټولیزه توګه 20)، نو RF=3 شاوخوا 2 ځله له لاسه ورکوي (150 ثانیې د RF=3 لپاره د 75 په مقابل کې د RF=1 لپاره). مګر که موږ په 8 جدولونو کې د 5 تارونو سره (په ټولیز ډول 40) کې د ډیټا بارولو سره بار زیات کړو (په ټولیز ډول 3) ، نو د RF=2,7 ضایع دمخه 375 ځله (138 ثانیې د XNUMX په مقابل کې) دی.
شاید دا یو څه د CS لپاره د ډیټاسټیکس لخوا ترسره شوي بریالي بار ازموینې راز دی ، ځکه چې زموږ په موقف کې د 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
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
مستند کوونکی: AllowAllAllAuthenticator
اختیار ورکوونکی: AllowAllAuthorizer
رول_منیجر: کیساندرا رول مدیر
رولونه_وثیقیت_په_ایمس: 2000
permissions_validity_in_ms: 2000
اعتبار_وثیقیت_په_ایمس: 2000
ویشونکی: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # هر ډیټا این لارښود یو جلا ډیسک دی
- /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: ودرول
ژمنه_ناکامۍ_پالیسی: ودروئ
چمتو شوي_بیانونه_کیچ_سایز_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
ژمنه_سیمه_سیز_ان_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
پیل_ملی_ټرانسپورټ: ریښتیا
اصلي_ټرانسپورټ_پورټ: 9042
start_rpc: ریښتیا
rpc_address: *
rpc_port: 9160
rpc_keepalive: ریښتیا
rpc_server_type: sync
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
متقابل_کمپیکټرونه: 4
compaction_throughput_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
د لوستلو_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
د لیکلو_غوښتنې_ وخت پای_نوم: 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: هیڅ نه
د مراجعینو_کوډ کولو_اختیارونه:
فعال شوی: غلط
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: 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:+UseConcMarkSweepGC
-XX:+CMSparallelRemark فعال شوی
-XX: د ژوندي پاتې کیدو تناسب = 8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiating OccupancyFraction=75
-XX:+UseCMSI یوازې د اشغال پیل کول
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMark فعال شوی
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSCclassUnloading فعال شوی
د 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.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-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:+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 Size: 100 MiB
د HBase Thrift Server اعظمي لاګ فایل بیک اپ: 5
د ماسټر میکس د ننوتلو اندازه: 100 MiB
ماسټر اعظمي لاګ فایل بیک اپ: 5
RegionServer Max Log Size: 100 MiB
د سیمې سرور اعظمي لاګ فایل بیک اپ: 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 ګی بی
د HBase REST سرور ډیفالټ ګروپ: 3 GiB
د HBase Thrift Server Default Group: 3 GiB
په بایټس کې د HBase ماسټر جاوا هیپ اندازه: 16 GiB
په بایټس کې د 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', COMPRESSION => 'GZ'}
دلته یو مهم ټکی شتون لري - د ډیټا سټیکس توضیحات دا نه وايي چې د 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 په ترتیب کې یو ډول خنډ شتون لري. په هرصورت، ګوګل کول او د خورا واضح پیرامیټونو لټون کول (لکه کنسرنټ_رایټس یا میمټبل_هیپ_سپیس_in_mb) شیان ګړندي نه کړل. په ورته وخت کې، لاګونه پاک دي او په هیڅ شی قسم نه کوي.
ډاټا په ټولو نوډونو کې په مساوي ډول ویشل شوي، د ټولو نوډونو احصایې نږدې ورته وې.
دا هغه څه دي چې د جدول احصایې د یو نوډونو څخه ښکاريکلیدي ځای: 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
د یادولو وړ حجرو شمیر: 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 لپاره ترلاسه شوي پایلې د ډیټاسټیکس لپاره ترلاسه شوي پایلې سره ورته دي - په هره ثانیه کې شاوخوا سلګونه زره عملیات. سربیره پردې، که موږ د سرچینو کارولو ته وګورو، موږ به وګورو چې CS ډیر CPU او ډیسک کاروي:
ارقام د دواړو ډیټابیسونو لپاره په قطار کې د ټولو ازموینو د چلولو پرمهال کارول ښیې.
د HB د قوي لوستلو ګټې په اړه. دلته تاسو لیدلی شئ چې د دواړو ډیټابیسونو لپاره ، د لوستلو پرمهال د ډیسک کارول خورا ټیټ دي (د لوستلو ازموینې د هر ډیټابیس لپاره د ازموینې دورې وروستۍ برخه ده ، د مثال په توګه د CS لپاره دا له 15:20 څخه تر 15:40 پورې دی). د HB په قضیه کې ، دلیل روښانه دی - ډیری ډیټا په حافظه کې ځړول کیږي ، په میمسټور کې ، او ځینې یې په بلاک کیچ کې ساتل کیږي. لکه څنګه چې د CS لپاره ، دا خورا روښانه نده چې دا څنګه کار کوي ، مګر د ډیسک ریسایکل کول هم نه لیدل کیږي ، مګر یوازې په هغه حالت کې چې د کیچ فعالولو هڅه شوې وه row_cache_size_in_mb = 2048 او د کیچنګ = {'کیز': 'ALL' تنظیم کړئ. 'rows_per_partition': '2000000'}، خو دې کار یو څه خراب کړ.
دا هم د یادولو وړ ده چې یو ځل بیا په HB کې د سیمو د شمیر په اړه یو مهم ټکی. زموږ په قضیه کې، ارزښت د 64 په توګه مشخص شوی. که تاسو یې کم کړئ او دا د مثال په توګه، 4 سره مساوي کړئ، نو کله چې لوستل کیږي، سرعت 2 ځله راټیټیږي. دلیل یې دا دی چې memstore به ګړندي ډک شي او فایلونه به ډیر ځله فلش شي او کله چې لوستل کیږي ، ډیر فایلونه به پروسس کولو ته اړتیا ولري ، کوم چې د HB لپاره خورا پیچلي عملیات دي. په ریښتیني شرایطو کې ، دا د وړاندیز کولو او تړون کولو ستراتیژۍ له لارې فکر کولو سره درملنه کیدی شي؛ په ځانګړي توګه ، موږ پخپله لیکل شوي یوټیلټي کاروو چې کثافات راټولوي او په شالید کې په دوامداره توګه HFiles فشاروي. دا خورا ممکنه ده چې د ډیټاسټیکس ازموینو لپاره دوی په هر میز کې یوازې 1 سیمه تخصیص کړې (کوم چې سمه نه ده) او دا به یو څه روښانه کړي چې ولې HB د دوی لوستلو ازموینو کې خورا ټیټ و.
لاندې لومړنۍ پایلې له دې څخه اخیستل شوي. داسې انګیرل کیږي چې د ازموینې په جریان کې کومه لویه تېروتنه نه وه شوې، نو بیا کیساندرا د مټ د پښو سره د کولوس په څیر ښکاري. په سمه توګه، پداسې حال کې چې هغه په یوه پښه کې توازن لري، لکه څنګه چې د مقالې په پیل کې انځور کې، هغه نسبتا ښه پایلې ښیي، مګر په ورته شرایطو کې په جګړه کې هغه په سخت ډول له لاسه ورکوي. په ورته وخت کې، زموږ په هارډویر کې د CPU ټیټ کارولو په پام کې نیولو سره، موږ زده کړل چې په هر کوربه کې دوه RegionServer HBs کښت کړو او په دې توګه فعالیت دوه چنده شو. هغوی. د منابعو د کارونې په نظر کې نیولو سره، د CS لپاره وضعیت نور هم د خپګان وړ دی.
البته، دا ازموینې خورا مصنوعي دي او د معلوماتو مقدار چې دلته کارول شوي نسبتا معتدل دي. دا ممکنه ده چې که موږ ټیرابایټ ته واړوو، وضعیت به توپیر ولري، مګر پداسې حال کې چې د HB لپاره موږ کولی شو ټیرابایټ پورته کړو، د CS لپاره دا ستونزمن و. دا ډیری وختونه د دې حجمونو سره حتی د OperationTimedOutException وغورځول ، که څه هم د ځواب انتظار کولو پیرامیټونه دمخه د ډیفالټ په پرتله څو ځله لوړ شوي.
زه امید لرم چې د ګډو هڅو له لارې به موږ د CS خنډونه ومومئ او که موږ یې ګړندي کړو نو د پوسټ په پای کې به زه حتما د وروستي پایلو په اړه معلومات اضافه کړم.
UPD: د ملګرو د مشورې څخه مننه، ما د لوستلو چټکتیا اداره کړه. وو:
159 عملیات (644 میزونه، 4 جریان، بیچ 5).
اضافه شوی:
.withLoadBalancingPolicy(نوی TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
او ما شاوخوا د تارونو شمیر سره لوبې کولې. پایله یې په لاندې ډول ده:
4 میزونه، 100 تارونه، بیچ = 1 (په ټوټه ټوټه): 301 عملیات
4 میزونه، 100 تارونه، بیچ = 10: 447 عملیات
4 میزونه، 100 تارونه، بیچ = 100: 625 عملیات
وروسته به زه نور د ټونینګ لارښوونې پلي کړم ، د بشپړ ازموینې دورې پرمخ وړم او پایلې به د پوسټ په پای کې اضافه کړم.
سرچینه: www.habr.com