اهو به هڪ مذاق نه آهي، اهو لڳي ٿو ته هي خاص تصوير بلڪل صحيح طور تي انهن ڊيٽابيس جي جوهر کي ظاهر ڪري ٿو، ۽ آخر ۾ اهو واضح ٿي ويندو ته ڇو:
DB-Engines Ranking جي مطابق، ٻه مشهور NoSQL ڪالمن ڊيٽابيس آهن Cassandra (هتان کان پوءِ CS) ۽ HBase (HB).
قسمت جي مرضي سان، Sberbank تي اسان جي ڊيٽا لوڊنگ مئنيجمينٽ ٽيم اڳ ۾ ئي آهي ۽ HB سان ويجهي ڪم ڪري ٿو. ان دوران اسان ان جي قوتن ۽ ڪمزورين جو چڱيءَ طرح اڀياس ڪيو ۽ ان کي پچائڻ جو طريقو سکيو. تنهن هوندي، سي ايس جي صورت ۾ هڪ متبادل جي موجودگي هميشه اسان کي مجبور ڪيو ته پاڻ کي شڪ سان ٿورو عذاب ڪرڻ: ڇا اسان صحيح انتخاب ڪيو؟ ان کان سواء، نتيجا ، ڊيٽا اسٽيڪس پاران ڪيل ، انهن چيو ته سي ايس آساني سان HB کي تقريبن هڪ ڪرشنگ اسڪور سان مات ڏئي ٿو. ٻئي طرف، DataStax هڪ دلچسپي واري پارٽي آهي، ۽ توهان کي ان لاءِ انهن جو لفظ نه وٺڻ گهرجي. اسان ٽيسٽ جي حالتن جي باري ۾ معلومات جي ٿوري مقدار کان پڻ پريشان ٿي ويا آهيون، تنهنڪري اسان پاڻ کي ڳولڻ جو فيصلو ڪيو ته ڪير آهي BigData NoSql جو بادشاهه، ۽ حاصل ڪيل نتيجا ڏاڍا دلچسپ نڪتا.
بهرحال، تجربن جي نتيجن تي هلڻ کان اڳ، اهو ضروري آهي ته ماحول جي جوڙجڪ جي اهم پهلوئن کي بيان ڪيو وڃي. حقيقت اها آهي ته سي ايس هڪ موڊ ۾ استعمال ڪري سگهجي ٿو جيڪا ڊيٽا کي نقصان جي اجازت ڏئي ٿي. اهي. اهو تڏهن ٿيندو آهي جڏهن صرف هڪ سرور (نوڊ) ڪنهن خاص ڪنجي جي ڊيٽا لاءِ ذميوار هوندو آهي، ۽ جيڪڏهن ڪنهن سبب جي ڪري اهو ناڪام ٿي ويندو آهي، ته پوءِ هن ڪنجي جي قيمت ختم ٿي ويندي آهي. ڪيترن ئي ڪمن لاءِ اهو نازڪ ناهي، پر بينڪن جي شعبي لاءِ اهو قاعدي جي بجاءِ استثنا آهي. اسان جي حالت ۾، اهو ضروري آهي ته قابل اعتماد اسٽوريج لاء ڊيٽا جي ڪيترن ئي ڪاپيون آهن.
تنهن ڪري، ٽرپل نقل واري موڊ ۾ صرف سي ايس آپريٽنگ موڊ سمجهيو ويو، يعني. ڪيس اسپيس جي ٺاھڻ ھيٺ ڏنل پيراگرافن سان ڪئي وئي آھي:
CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};
اڳيون، گهربل سطح جي استحڪام کي يقيني بڻائڻ لاء ٻه طريقا آهن. عام اصول:
NW + NR > RF
جنهن جو مطلب آهي ته نوڊس مان تصديق جو تعداد جڏهن لکڻ (NW) ۽ نوڊس مان تصديق جو تعداد جڏهن پڙهڻ (NR) ريپليڪشن فيڪٽر کان وڌيڪ هجڻ گهرجي. اسان جي حالت ۾، آر ايف = 3، جنهن جو مطلب آهي ته هيٺيان اختيار مناسب آهن:
2 + 2 > 3
3 + 1 > 3
جيئن ته اهو بنيادي طور تي ضروري آهي ته اسان ڊيٽا کي محفوظ طور تي محفوظ ڪرڻ لاء ممڪن طور تي، 3 + 1 اسڪيم چونڊيو ويو. ان کان علاوه، ايڇ بي ساڳئي اصول تي ڪم ڪري ٿو، يعني. اهڙو مقابلو وڌيڪ منصفانه ٿيندو.
اهو ياد رکڻ گهرجي ته DataStax انهن جي مطالعي ۾ سامهون ڪيو، انهن سي ايس ۽ ايڇ ٻنهي لاء آر ايف = 1 مقرر ڪيو (بعد ۾ HDFS سيٽنگون تبديل ڪندي). هي هڪ واقعي اهم پاسو آهي ڇاڪاڻ ته هن معاملي ۾ سي ايس جي ڪارڪردگي تي اثر تمام وڏو آهي. مثال طور، هيٺ ڏنل تصوير ڏيکاري ٿي CS ۾ ڊيٽا لوڊ ڪرڻ لاءِ گهربل وقت ۾ اضافو:
ھتي اسان ھيٺين کي ڏسون ٿا: وڌيڪ مقابلي وارا موضوع ڊيٽا لکندا آھن، اھو گھڻو وقت وٺندو آھي. اهو قدرتي آهي، پر اهو ضروري آهي ته RF = 3 جي ڪارڪردگي جي خرابي تمام گهڻي آهي. ٻين لفظن ۾، جيڪڏهن اسان 4 موضوعن کي 5 جدولن ۾ لکون ٿا (مجموعي طور تي 20)، پوءِ RF = 3 اٽڪل 2 ڀيرا وڃائي ٿو (150 سيڪنڊن لاءِ RF=3 بمقابله 75 RF=1 لاءِ). پر جيڪڏهن اسان لوڊ وڌائي ڊيٽا کي 8 جدولن ۾ لوڊ ڪندي 5 ٿريڊن سان هر هڪ (40 مجموعي ۾)، پوءِ RF = 3 جو نقصان اڳ ۾ ئي 2,7 ڀيرا آهي (375 سيڪنڊن جي مقابلي ۾ 138).
ٿي سگهي ٿو اهو جزوي طور تي CS لاءِ DataStax پاران ڪيل ڪامياب لوڊ ٽيسٽنگ جو راز آهي، ڇاڪاڻ ته HB لاءِ اسان جي موقف تي 2 کان 3 تائين ريپليڪشن فيڪٽر کي تبديل ڪرڻ جو ڪو به اثر نه پيو. اهي. ڊسڪ اسان جي تشڪيل لاءِ HB رڪاوٽ نه آهن. بهرحال، هتي ٻيا به ڪيترائي نقصان آهن، ڇاڪاڻ ته اهو ياد رکڻ گهرجي ته اسان جي HB جو نسخو ٿورڙو پيچ ۽ ٽائيڪ ڪيو ويو آهي، ماحول بلڪل مختلف آهي، وغيره. اهو پڻ قابل ذڪر آهي ته شايد مون کي خبر ناهي ته سي ايس کي ڪيئن تيار ڪجي ۽ ان سان گڏ ڪم ڪرڻ جا ڪجهه وڌيڪ اثرائتو طريقا آهن، ۽ مون کي اميد آهي ته اسان تبصرن ۾ ڳولي سگهنداسين. پر پهرين شيون پهرين.
سڀئي تجربا هڪ هارڊويئر ڪلستر تي ڪيا ويا جن ۾ 4 سرور شامل آهن، هر هڪ هيٺ ڏنل ترتيب سان:
سي پي يو: Xeon E5-2680 v4 @ 2.40GHz 64 موضوع.
ڊسڪ: 12 ٽڪرا SATA HDD
جاوا ورزن: 1.8.0_111
سي ايس ورزن: 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
تصديق ڪندڙ: AllowAllAuthenticator
اختيار ڪندڙ: اجازت ڏيڻ وارو
رول_منيجر: CassandraRoleManager
ڪردارن_صحت_۾_ms: 2000
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: روڪيو
عزم_ناڪامي_پاليسي: روڪيو
تيار ڪيل_ بيانن_ڪيش_سائز_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
اسٽوريج_پورٽ: 7000
ssl_storage_port: 7001
ٻڌو_ايڊريس: *
broadcast_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: غلط
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
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: ڊي سي
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
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: غلط
enable_materialized_views: سچو
enable_sasi_indexes: صحيح
جي سي سيٽنگون:
### CMS سيٽنگون-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSparallelRemark فعال
-XX: SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiating OccupancyFraction=75
-XX:+UseCMSI صرف قبضي جي شروعات ڪرڻ
-XX: CMSWaitDuration=10000
-XX:+CMSparallelInitialMark فعال
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSCclassUnloading Enabled
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 ٿي ويو جڏهن علائقن جو تعداد 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:+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 Log Size: 100 MiB
HBase Thrift Server وڌ ۾ وڌ لاگ فائل بيڪ اپ: 5
ماسٽر ميڪس لاگ سائيز: 100 ايم بي
ماسٽر وڌ ۾ وڌ لاگ فائل بيڪ اپ: 5
ريجن سرور ميڪس لاگ سائيز: 100 ايم بي
RegionServer وڌ ۾ وڌ لاگ فائل بيڪ اپ: 5
ايڇ بيس ايڪٽو ماسٽر ڊيٽيڪشن ونڊو: 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 Thrift Server Default Group: 3 GiB
بائيٽس ۾ HBase ماسٽر جي جاوا هيپ سائيز: 16 GiB
HBase RegionServer جي جاوا هيپ سائيز بائيٽ ۾: 32 GiB
+ زو سنڀاليندڙ
maxClientCnxns: 601
وڌ ۾ وڌ سيشن ٽائم آئوٽ: 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'}
هتي هڪ اهم نقطو آهي - 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
دير سان لکڻ: 0.1350068438699957 ms
باقي فلش: 0
ٽيبل: t1
SST قابل ڳڻپ: 16
استعمال ٿيل خلا (لائيو): 148.59 ايم بي
استعمال ٿيل خلا (ڪل): 148.59 ايم بي
اسپيس استعمال ٿيل سنيپ شاٽ (ڪل): 0 بائيٽ
آف هيپ ميموري استعمال ڪئي وئي (ڪل): 5.17 ايم بي
ايس ايس ٽيبل ڪمپريشن تناسب: 0.5720989576459437
ورهاڱي جو تعداد (اندازو): 3970323
يادگار سيل ڳڻپ: 0
ياد رکڻ واري ڊيٽا سائيز: 0 بائيٽ
ميٽبل آف هيپ ميموري استعمال ٿيل: 0 بائيٽ
يادگار سوئچ ڳڻپ: 5
مقامي پڙهيل ڳڻپ: 2346045
مقامي پڙهڻ جي دير: NaN ms
مقامي لکڻ جي ڳڻپ: 3865503
مقامي لکڻ جي دير: NaN ms
باقي رهيل فلش: 0
مرمت جو سيڪڙو: 0.0
بلوم فلٽر غلط مثبت: 25
بلوم فلٽر غلط تناسب: 0.00000
بلوم فلٽر اسپيس استعمال ٿيل: 4.57 ايم بي
بلوم فلٽر آف هيپ ميموري استعمال ٿيل: 4.57 ايم بي
انڊيڪس خلاصو آف هيپ ميموري استعمال ٿيل: 590.02 KiB
کمپريشن ميٽا ڊيٽا آف هيپ ميموري استعمال ٿيل: 19.45 KiB
ٺهيل ورهاڱي ۾ گھٽ ۾ گھٽ بائيٽ: 36
ٺهيل ورهاڱي جي وڌ ۾ وڌ بائيٽ: 42
ٺهيل ورهاڱي جو مطلب بائيٽ: 42
سراسري زنده سيل في سلائس (آخري پنج منٽ): NaN
وڌ ۾ وڌ جاندار سيل في سلائس (آخري پنج منٽ): 0
سراسري قبرن جا پٿر في سلائس (آخري پنج منٽ): NaN
وڌ ۾ وڌ قبرن جا پٿر في سلائس (آخري پنج منٽ): 0
ڦٽي ميوٽيشنز: 0 بائيٽ
بيچ جي سائيز کي گهٽائڻ جي ڪوشش (جيتوڻيڪ ان کي انفرادي طور تي موڪلڻ) جو ڪو اثر نه ٿيو، اهو صرف خراب ٿي ويو. اهو ممڪن آهي ته حقيقت ۾ اها حقيقت ۾ CS لاءِ سڀ کان وڌيڪ ڪارڪردگي آهي، ڇو ته CS لاءِ حاصل ڪيل نتيجا ساڳيا آهن جيڪي ڊيٽا اسٽيڪس لاءِ حاصل ڪيا ويا آهن - اٽڪل سئو هزارين آپريشن في سيڪنڊ. اضافي طور تي، جيڪڏهن اسان وسيلن جي استعمال تي نظر رکون ٿا، اسان ڏسندا سين ته سي ايس گهڻو وڌيڪ سي پي يو ۽ ڊسڪ استعمال ڪري ٿو:
انگ اکر ڏيکاري ٿو استعمال کي هلائڻ دوران سڀني ٽيسٽن جي هڪ قطار ۾ ٻنهي ڊيٽابيس لاءِ.
ايڇ بي جي طاقتور پڙهڻ واري فائدي جي حوالي سان. هتي توهان ڏسي سگهو ٿا ته ٻنهي ڊيٽابيسن لاءِ، پڙهڻ دوران ڊسڪ جو استعمال انتهائي گهٽ آهي (پڙهڻ جا ٽيسٽ هر ڊيٽابيس لاءِ ٽيسٽنگ چڪر جو آخري حصو آهن، مثال طور CS لاءِ هي 15:20 کان 15:40 تائين آهي). HB جي صورت ۾، سبب واضح آهي - اڪثر ڊيٽا ميموري ۾، ميم اسٽور ۾، ۽ ڪجهه بلاڪ ڪيش ۾ ڪيش ٿيل آهي. جيئن ته CS لاءِ، اهو بلڪل واضح ناهي ته اهو ڪيئن ڪم ڪري ٿو، پر ڊسڪ ريسائڪلنگ به نظر نٿي اچي، پر صرف ان صورت ۾، هڪ ڪوشش ڪئي وئي ته ڪيش کي فعال ڪرڻ جي ڪوشش ڪئي وئي row_cache_size_in_mb = 2048 ۽ سيٽ ڪيشنگ = {'keys': 'ALL', 'rows_per_partition': '2000000'}، پر ان ان کي وڌيڪ خراب ڪيو.
اهو پڻ قابل ذڪر آهي ته هڪ ڀيرو ٻيهر ايڇ بي ۾ علائقن جي تعداد بابت هڪ اهم نقطو. اسان جي صورت ۾، قيمت 64 جي طور تي بيان ڪئي وئي هئي. جيڪڏھن توھان ان کي گھٽايو ۽ ان کي برابر ڪريو، مثال طور، 4، پوء پڙھڻ وقت، رفتار 2 ڀيرا گھٽجي ويندي. ان جو سبب اهو آهي ته memstore تيزيءَ سان ڀرجي ويندو ۽ فائلون گهڻو ڪري فليش ٿينديون ۽ پڙهڻ دوران، وڌيڪ فائلن کي پروسيس ڪرڻ جي ضرورت پوندي، جيڪو HB لاءِ بلڪه پيچيده آپريشن آهي. حقيقي حالتن ۾، اهو علاج ڪري سگهجي ٿو سوچڻ سان اڳڀرائي ۽ ٺهڪندڙ حڪمت عملي؛ خاص طور تي، اسان هڪ خود لکيل افاديت استعمال ڪندا آهيون جيڪو ڪچرو گڏ ڪري ٿو ۽ پس منظر ۾ مسلسل HFiles کي دٻائي ٿو. اهو بلڪل ممڪن آهي ته DataStax ٽيسٽن لاءِ هنن في ٽيبل صرف 1 علائقو مختص ڪيو (جيڪو درست ناهي) ۽ اهو ڪجهه واضح ڪندو ته HB انهن جي پڙهڻ واري ٽيسٽ ۾ ايترو گهٽ ڇو هو.
ان مان هيٺيان ابتدائي نتيجا اخذ ڪيا ويا آهن. فرض ڪيو ته جاچ دوران ڪا وڏي غلطي نه ڪئي وئي هئي، پوءِ ڪئسينڊرا مٽيءَ جي پيرن سان ڪولاسس وانگر نظر اچي ٿي. وڌيڪ صحيح طور تي، جڏهن هوء هڪ ٽنگ تي توازن رکي ٿي، جيئن آرٽيڪل جي شروعات ۾ تصوير ۾، هوء نسبتا سٺا نتيجا ڏيکاري ٿي، پر ساڳئي حالتن ۾ جنگ ۾ هوء صحيح طور تي وڃائي ٿي. ساڳئي وقت، اسان جي هارڊويئر تي گهٽ سي پي يو استعمال کي نظر ۾ رکندي، اسان هر ميزبان کي ٻه ريجن سرور HB پلانٽ ڪرڻ سکيو ۽ ان سان ڪارڪردگي کي ٻيڻو ڪيو. اهي. وسيلن جي استعمال کي نظر ۾ رکندي، سي ايس جي صورتحال اڃا به وڌيڪ خراب آهي.
يقينا، اهي تجربا ڪافي مصنوعي آهن ۽ ڊيٽا جو مقدار جيڪو هتي استعمال ڪيو ويو آهي نسبتا معمولي آهي. اهو ممڪن آهي ته جيڪڏهن اسان ٽيرا بائيٽس ۾ تبديل ڪريون ته صورتحال مختلف هجي ها، پر جڏهن ته HB لاءِ اسان ٽيرا بائيٽ لوڊ ڪري سگهون ٿا، سي ايس لاءِ اهو مسئلو پيدا ٿيو. اهو اڪثر ڪري انهن حجمن سان گڏ هڪ OperationTimedOutException پڻ اڇلائي ٿو، جيتوڻيڪ جواب جي انتظار لاءِ پيرا ميٽر اڳ ۾ ئي ڊفالٽ وارن جي مقابلي ۾ ڪيترائي ڀيرا وڌيا ويا آهن.
مون کي اميد آهي ته گڏيل ڪوششن ذريعي اسان سي ايس جي رڪاوٽن کي ڳولي سگهنداسين ۽ جيڪڏهن اسان ان کي تيز ڪري سگهون ٿا ته پوءِ پوسٽ جي آخر ۾ آئون ضرور حتمي نتيجن بابت معلومات شامل ڪندس.
UPD: ڪامريڊن جي صلاح جي مهرباني، مان پڙهڻ کي تيز ڪرڻ ۾ ڪامياب ٿيس. هو:
159 اوپس (644 ٽيبل، 4 اسٽريم، بيچ 5).
شامل ٿيل
.withLoadBalancingPolicy(نئين TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
۽ مون موضوعن جي تعداد سان گڏ راند ڪيو. نتيجو هيٺ ڏنل آهي:
4 جدول، 100 سلسلا، بيچ = 1 (ٽڪڙو ٽڪرو): 301 ops
4 ٽيبل، 100 موضوع، بيچ = 10: 447 او ايس
4 ٽيبل، 100 موضوع، بيچ = 100: 625 او ايس
بعد ۾ آئون ٽيوننگ جون ٻيون تجويزون لاڳو ڪندس، مڪمل ٽيسٽ چڪر هلائيندس ۽ پوسٽ جي آخر ۾ نتيجا شامل ڪندس.
جو ذريعو: www.habr.com