یہ ایک لطیفہ بھی نہیں ہے، ایسا لگتا ہے کہ یہ خاص تصویر ان ڈیٹا بیس کے جوہر کو بالکل درست طریقے سے ظاہر کرتی ہے، اور آخر میں یہ واضح ہو جائے گا کہ کیوں:
DB-Engines کی درجہ بندی کے مطابق، دو سب سے زیادہ مقبول NoSQL کالمی ڈیٹا بیس Cassandra (اس کے بعد CS) اور HBase (HB) ہیں۔
قسمت کی مرضی سے، Sberbank میں ہماری ڈیٹا لوڈنگ مینجمنٹ ٹیم پہلے ہی موجود ہے۔ اور 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 اسی طرح کے اصول پر کام کرتا ہے، یعنی اس طرح کا موازنہ زیادہ منصفانہ ہوگا۔
واضح رہے کہ DataStax نے اپنے مطالعے میں اس کے برعکس کیا، انہوں نے CS اور HB دونوں کے لیے RF = 1 مقرر کیا (بعد میں HDFS کی ترتیبات کو تبدیل کرکے)۔ یہ واقعی ایک اہم پہلو ہے کیونکہ اس معاملے میں CS کی کارکردگی پر اثر بہت زیادہ ہے۔ مثال کے طور پر، نیچے دی گئی تصویر CS میں ڈیٹا لوڈ کرنے کے لیے درکار وقت میں اضافہ دکھاتی ہے۔
یہاں ہم مندرجہ ذیل دیکھتے ہیں: جتنے زیادہ مسابقتی تھریڈز ڈیٹا لکھتے ہیں، اتنا ہی زیادہ وقت لگتا ہے۔ یہ فطری ہے، لیکن یہ ضروری ہے کہ RF=3 کی کارکردگی میں کمی نمایاں طور پر زیادہ ہو۔ دوسرے لفظوں میں، اگر ہم 4 تھریڈز کو 5 ٹیبلز میں لکھتے ہیں (مجموعی طور پر 20)، تو RF=3 تقریباً 2 گنا (RF=150 کے لیے 3 سیکنڈز بمقابلہ 75 RF=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
authenticator: AllowAllAuthenticator
مصنف: اجازت دینے والا
رول_منیجر: کیسینڈرا رول مینجر
رولز_ویلڈیٹی_میں_ایم ایس: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 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
کمٹلاگ_سیگمنٹ_سائز_ان_ایم بی: 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: ہیپ_بفرز
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: سچ ہے۔
کالم_انڈیکس_سائز_ان_کب: 64
کالم_انڈیکس_کیشے_سائز_ان_کب: 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
درخواست_شیڈیولر: org.apache.cassandra.scheduler.NoScheduler
سرور_انکرپشن_اختیارات:
internode_encryption: کوئی نہیں۔
کلائنٹ_انکرپشن_اختیارات:
فعال: غلط
انٹرنوڈ_کمپریشن: ڈی سی
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
شفاف_ڈیٹا_انکرپشن_اختیارات:
فعال: غلط
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: غلط
enable_materialized_views: سچ
enable_sasi_indexes: true
جی سی کی ترتیبات:
### CMS کی ترتیبات-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemark فعال
-XX: زندہ بچ جانے کا تناسب=8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+CMSINItiatinging Occupancy صرف استعمال کریں۔
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMark فعال
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSC کلاس ان لوڈنگ فعال
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 سے زیادہ تھی)
غیر طے شدہ 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 زیادہ سے زیادہ لاگ سائز: 100 MiB
HBase Thrift Server زیادہ سے زیادہ لاگ فائل بیک اپ: 5
ماسٹر میکس لاگ سائز: 100 ایم بی
ماسٹر زیادہ سے زیادہ لاگ فائل بیک اپ: 5
ریجن سرور میکس لاگ سائز: 100 ایم بی
ریجن سرور زیادہ سے زیادہ لاگ فائل بیک اپ: 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 Thrift Server ڈیفالٹ گروپ: 3 GiB
HBase Master کا جاوا ہیپ سائز بائٹس میں: 16 GiB
HBase RegionServer کا جاوا ہیپ سائز بائٹس میں: 32 GiB
+ZooKeeper
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 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 تک ہے)۔ ایچ بی کے معاملے میں، وجہ واضح ہے - زیادہ تر ڈیٹا میموری میں ہینگ ہوتا ہے، میم اسٹور میں، اور کچھ بلاک کیچ میں محفوظ ہوتا ہے۔ جہاں تک CS کا تعلق ہے، یہ بالکل واضح نہیں ہے کہ یہ کیسے کام کرتا ہے، لیکن ڈسک کی ری سائیکلنگ بھی نظر نہیں آتی، لیکن صرف اس صورت میں، کیش کو فعال کرنے کی کوشش کی گئی تھی row_cache_size_in_mb = 2048 اور سیٹ caching = {'keys': 'ALL'، 'rows_per_partition': '2000000'}، لیکن اس نے اسے اور بھی خراب کر دیا۔
ایک بار پھر HB میں علاقوں کی تعداد کے بارے میں ایک اہم نکتہ بھی قابل ذکر ہے۔ ہمارے معاملے میں، قدر 64 کے طور پر بیان کی گئی تھی۔ اگر آپ اسے گھٹا کر اسے برابر کرتے ہیں، مثال کے طور پر، 4، تو پڑھتے وقت، رفتار 2 گنا کم ہو جاتی ہے۔ وجہ یہ ہے کہ میم اسٹور تیزی سے بھرے گا اور فائلیں زیادہ کثرت سے فلش کی جائیں گی اور پڑھتے وقت مزید فائلوں پر کارروائی کرنے کی ضرورت ہوگی، جو کہ HB کے لیے ایک پیچیدہ آپریشن ہے۔ حقیقی حالات میں، اس کا علاج ایک presplitting اور compactification کی حکمت عملی کے ذریعے سوچ کر کیا جا سکتا ہے؛ خاص طور پر، ہم ایک خود تحریر کردہ یوٹیلیٹی استعمال کرتے ہیں جو کوڑا کرکٹ جمع کرتا ہے اور HFiles کو پس منظر میں مسلسل کمپریس کرتا ہے۔ یہ بالکل ممکن ہے کہ DataStax ٹیسٹوں کے لیے انہوں نے فی ٹیبل صرف 1 علاقہ مختص کیا ہو (جو درست نہیں ہے) اور اس سے کسی حد تک یہ واضح ہو جائے گا کہ HB ان کے پڑھنے کے ٹیسٹ میں اتنا کمتر کیوں تھا۔
اس سے درج ذیل ابتدائی نتائج اخذ کیے گئے ہیں۔ یہ فرض کرتے ہوئے کہ جانچ کے دوران کوئی بڑی غلطیاں نہیں ہوئیں، پھر کیسینڈرا مٹی کے پاؤں کے ساتھ ایک کالوسس کی طرح دکھائی دیتی ہے۔ مزید واضح طور پر، جب وہ ایک ٹانگ پر توازن رکھتی ہے، جیسا کہ مضمون کے شروع میں تصویر میں ہے، وہ نسبتاً اچھے نتائج دکھاتی ہے، لیکن انہی حالات میں لڑائی میں وہ بالکل ہار جاتی ہے۔ اسی وقت، اپنے ہارڈ ویئر پر کم CPU استعمال کو مدنظر رکھتے ہوئے، ہم نے فی میزبان دو RegionServer HB لگانا سیکھا اور اس طرح کارکردگی کو دوگنا کر دیا۔ وہ. وسائل کے استعمال کو مدنظر رکھتے ہوئے، CS کے لیے صورتحال اور بھی تشویشناک ہے۔
بلاشبہ، یہ ٹیسٹ کافی مصنوعی ہیں اور یہاں استعمال ہونے والے ڈیٹا کی مقدار نسبتاً معمولی ہے۔ یہ ممکن ہے کہ اگر ہم ٹیرا بائٹس پر سوئچ کرتے ہیں، تو صورتحال مختلف ہوتی، لیکن جب کہ HB کے لیے ہم ٹیرا بائٹس لوڈ کر سکتے ہیں، CS کے لیے یہ مشکل ثابت ہوا۔ اس نے اکثر ان جلدوں کے ساتھ بھی OperationTimedOutException پھینک دیا، حالانکہ جواب کے انتظار کے پیرامیٹرز پہلے سے طے شدہ کے مقابلے میں کئی گنا بڑھ چکے تھے۔
مجھے امید ہے کہ مشترکہ کوششوں سے ہم CS کی رکاوٹوں کو تلاش کر لیں گے اور اگر ہم اسے تیز کر سکتے ہیں تو پوسٹ کے آخر میں میں حتمی نتائج کے بارے میں معلومات ضرور شامل کروں گا۔
UPD: ساتھیوں کے مشورے کی بدولت میں پڑھنے کو تیز کرنے میں کامیاب ہو گیا۔ تھا:
159 آپریشنز (644 میزیں، 4 سلسلے، بیچ 5)۔
شامل:
.withLoadBlancingPolicy(نئی TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
اور میں دھاگوں کی تعداد کے ساتھ کھیلتا رہا۔ نتیجہ درج ذیل ہے:
4 میزیں، 100 دھاگے، بیچ = 1 (ٹکڑا بہ ٹکڑا): 301 آپریشنز
4 میزیں، 100 دھاگے، بیچ = 10: 447 آپریشنز
4 میزیں، 100 دھاگے، بیچ = 100: 625 آپریشنز
بعد میں میں دوسرے ٹیوننگ ٹپس کا اطلاق کروں گا، ایک مکمل ٹیسٹ سائیکل چلاؤں گا اور پوسٹ کے آخر میں نتائج شامل کروں گا۔
ماخذ: www.habr.com