Энэ бол хошигнол ч биш, энэ зураг нь эдгээр мэдээллийн сангийн мөн чанарыг хамгийн зөв тусгаж байгаа юм шиг санагдаж байгаа бөгөөд эцэст нь яагаад тодорхой болох нь тодорхой болно.
DB-Engines Ranking-ийн дагуу NoSQL-ийн хамгийн алдартай хоёр багана мэдээллийн сан бол Кассандра (цаашид CS) ба HBase (HB) юм.
Хувь заяаны хүслээр манай Сбербанк дахь өгөгдөл ачаалах менежментийн баг аль хэдийн ажиллаж байна HB-тэй нягт хамтран ажилладаг. Энэ хугацаанд бид түүний давуу болон сул талыг нэлээд сайн судалж, хоол хийх аргад суралцсан. Гэсэн хэдий ч CS хэлбэрээр өөр хувилбар байгаа нь биднийг үргэлж эргэлзээ төрүүлж өөрсдийгөө бага зэрэг зовооход хүргэдэг: бид зөв сонголт хийсэн үү? Үүнээс гадна үр дүн , DataStax-ийн гүйцэтгэсэн, тэд CS бараг бутлах оноогоор HB амархан ялдаг гэж хэлсэн. Нөгөөтэйгүүр, DataStax бол сонирхогч тал бөгөөд та тэдний үгийг хүлээж авах ёсгүй. Туршилтын нөхцлийн талаархи бага хэмжээний мэдээлэл биднийг бас андуурч байсан тул бид BigData NoSql-ийн хаан хэн болохыг өөрсдөө олж мэдэхээр шийдсэн бөгөөд олж авсан үр дүн нь маш сонирхолтой болсон.
Гэсэн хэдий ч хийсэн туршилтын үр дүнд шилжихээсээ өмнө хүрээлэн буй орчны тохиргооны чухал талуудыг тайлбарлах шаардлагатай. Баримт нь CS-ийг өгөгдөл алдах боломжийг олгодог горимд ашиглах боломжтой юм. Тэдгээр. Энэ нь зөвхөн нэг сервер (зангилаа) нь тодорхой түлхүүрийн өгөгдлийг хариуцах бөгөөд хэрэв ямар нэг шалтгаанаар бүтэлгүйтвэл энэ түлхүүрийн утга алдагдах болно. Олон ажлын хувьд энэ нь тийм ч чухал биш боловч банкны салбарын хувьд энэ нь дүрэм гэхээсээ үл хамаарах зүйл юм. Манай тохиолдолд найдвартай хадгалахын тулд хэд хэдэн хуулбар өгөгдөлтэй байх нь чухал юм.
Тиймээс гурав дахин хуулбарлах горимд зөвхөн CS үйлдлийн горимыг авч үзсэн, i.e. Кейсийн орон зайг үүсгэх ажлыг дараах параметрүүдээр гүйцэтгэсэн.
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 нь ижил төстэй зарчмаар ажилладаг, i.e. Ийм харьцуулалт илүү шударга байх болно.
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 секунд) байна.
Магадгүй энэ нь зарим талаараа DataStax-аас CS-д хийсэн ачааллын туршилтыг амжилттай хийсний нууц байж болох юм, учир нь манай стенд дээр HB-ийн хувьд хуулбарлах коэффициентийг 2-оос 3 болгон өөрчлөх нь ямар ч нөлөө үзүүлээгүй. Тэдгээр. дискнүүд нь бидний тохиргооны хувьд HB-ийн саад бэрхшээл биш юм. Гэсэн хэдий ч энд өөр олон бэрхшээл бий, учир нь бидний HB хувилбар нь бага зэрэг засварлагдсан, тохируулагдсан, орчин нь огт өөр, гэх мэт гэдгийг тэмдэглэх нь зүйтэй. Магадгүй би CS-г хэрхэн зөв бэлтгэхээ мэдэхгүй байж магадгүй бөгөөд үүнтэй ажиллах илүү үр дүнтэй аргууд байгаа гэдгийг тэмдэглэх нь зүйтэй бөгөөд бид үүнийг тайлбар дээрээс олж мэдэх болно гэж найдаж байна. Гэхдээ хамгийн түрүүнд хийх зүйл.
Бүх туршилтыг тус бүр нь дараах тохиргоотой 4 серверээс бүрдсэн техник хангамжийн кластер дээр хийсэн.
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 урсгалтай.
Диск: 12 ширхэг SATA HDD
java хувилбар: 1.8.0_111
CS хувилбар: 3.11.5
cassandra.yml параметрүүдТокенуудын_тоо: 256
hinted_handoff_enabled: үнэн
kb-д_дамжуулагч_дамжуулагч: 1024
хамгийн их_санамж, хүргэлтийн_утас: 2
hints_directory: /data10/cassandra/hints
ms-д_цэвэрлэх_хугацаа: 10000
mb-д_хамгийн_санамж_файлын_хэмжээ: 128
batchlog_replay_throttle_in_kb: 1024
баталгаажуулагч: AllowAllAuthenticator
зохиогч: AllowAllAuthorizer
үүрэг_менежер: CassandraRoleManager
ms-д үүрэг_хүчтэй байдал: 2000
зөвшөөрлийн_хүчинтэй_хугацаа: 2000
итгэмжлэлийн_хүчтэй_мэдэгдэл: 2000
хуваагч: org.apache.cassandra.dht.Murmur3Partitioner
өгөгдлийн_файлын_директорууд:
- /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: худал
дискний_бүтэлгүйтлийн_бодлого: зогсоох
бүтэлгүйтлийн_бодлого: зогсоох
бэлтгэсэн_мэдэгдэлийн_кэш_хэмжээ_mb:
хэмнэлттэй_бэлтгэсэн_мэдэгдэлийн_кэш_хэмжээ_mb:
key_cache_size_in_mb:
түлхүүрийн_кэш_хадгалах хугацаа: 14400
МБ-д_мөрийн_кэш_хэмжээ: 0
мөрийн_кэш_хадгалах_хугацаа: 0
counter_cache_size_mb-д:
counter_cache_save_period: 7200
хадгалсан_кэшүүд: /data10/cassandra/saved_caches
commitlog_sync: үе үе
commitlog_syc_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
үр_үйлүүлэгч:
- ангийн_нэр: org.apache.cassandra.locator.SimpleSeedProvider
Параметрүүд:
- үр: "*,*"
зэрэгцээ_уншсан: 256 # оролдсон 64 - ямар ч ялгаа анзаарагдсангүй
concurrent_writes: 256 # оролдсон 64 - ямар ч ялгаа анзаарагдсангүй
зэрэгцээ_тоологч_бичдэг: 256 # оролдсон 64 - ямар ч ялгаа анзаарагдсангүй
зэрэгцээ_материалжуулсан_үзэл_бичдэг: 32
memtable_heap_space_in_mb: 2048 # оролдсон 16 GB - энэ нь удаан байсан
memtable_location_type: heap_buffers
индексийн_хураангуй_багтаамжийн_мб:
индексийн_хураангуй_хэмжээг өөрчлөх_интервал минутанд: 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_хаяг: *
rpc_port: 9160
rpc_keepalive: үнэн
rpc_server_type: sync
хэмнэлттэй_хүрээтэй_тээврийн_хэмжээ: 15
нэмэлт_нөөцлөлт: худал
нягтруулахын өмнөх агшин зуурын зураг: худал
auto_snapshot: үнэн
баганын_индекс_хэмжээ_кб: 64
баганын_индекс_кэш_хэмжээ_кб: 2
нэгэн зэрэг нягтруулагч: 4
сек-н нягтаршлын_дамж: 1600
sstable_preemptive_open_interval_in_mb: 50
Унших_хүсэлтийн_хугацаа_минусаар: 100000
муж_хүсэлтийн_цаг_хугацааны_мэд: 200000
бичих_хүсэлтийн_хугацаа_мС: 40000
Эсрэг_бичих_хүсэлтийн_хугацаа_мС: 100000
cas_conttention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
хүсэлтийн_хугацаа_ин_м: 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_ms: 600000
динамик_муу_муу_босго: 0.1
хүсэлт_хуваарилагч: org.apache.cassandra.scheduler.NoScheduler
серверийн_шифрлэлтийн_сонголтууд:
internode_encryption: байхгүй
үйлчлүүлэгчийн_шифрлэлтийн_сонголтууд:
идэвхжүүлсэн: худал
зангилаа хоорондын_шахалт: dc
inter_dc_tcp_nodelay: худал
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
идэвхжүүлэх_хэрэглэгчийн_тодорхойлогдсон_функцууд: худал
идэвхжүүлэх_scripted_user_defined_functions: false
windows_таймерын интервал: 1
ил тод_өгөгдлийн_шифрлэлтийн_сонголтууд:
идэвхжүүлсэн: худал
булшны_сануулах_босго: 1000
булшны_бүтэлгүйтлийн_босго: 100000
багцын_хэмжээний_сануулах_босго_кб: 200
багцын_хэмжээ_бүтэлгүйтлийн_босго_кб: 250
хуваалтуудаар_нэгдээгүй_багц анхааруулах босго: 10
нягтруулах_том_хуваалтын_анхааруулах_босго_mb: 100
gc_warn_threshold_in_ms: 1000
буцах_даралтыг идэвхжүүлсэн: худал
Материалжуулсан_үзэлтийг идэвхжүүлэх: үнэн
enable_sasi_indexes: үнэн
GC тохиргоо:
### CMS тохиргоо-XX:+ParNewGC-г ашигла
-XX:+ConcMarkSweepGC ашиглах
-XX:+CMSParallelRemarkEnabled
-XX: Амьд үлдэх харьцаа=8
-XX:Хамгийн дээд босго=1
-XX:CMSIinitiatingOccupancyFraction=75
-XX:+CMSIinitiatingOccupancyOnly ашиглах
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled
jvm.options санах ойд 16 Гб хуваарилагдсан (бид бас 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 ангид бид RegionServer дээрх бүсүүдийн тоо 1000-аас дээш байх үед GC-д хүргэсэн MetricsRegion-ыг хассан)
Өгөгдмөл бус 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 минут(s)
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.хугацаа: 4 цаг
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.үржүүлэгч: 6
hbase.hstore.compactionБосго: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 хоног
hbase-site.xml-д зориулсан HBase Service Advanced Configuration Snippet (Аюулгүйн хавхлага):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.том12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer-д зориулсан Java тохиргооны сонголтууд:
-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 МБ
HBase REST серверийн хамгийн их бүртгэлийн файлын нөөцлөлт: 5
HBase Thrift Server Хамгийн их бүртгэлийн хэмжээ: 100 МБ
HBase Thrift Server хамгийн их бүртгэлийн файлын нөөцлөлт: 5
Мастер хамгийн их бүртгэлийн хэмжээ: 100 МБ
Мастер хамгийн их бүртгэлийн файлын нөөцлөлт: 5
RegionServer хамгийн их бүртгэлийн хэмжээ: 100 МБ
RegionServer хамгийн их бүртгэлийн файлын нөөцлөлт: 5
HBase идэвхтэй мастер илрүүлэх цонх: 4 минут
dfs.client.hdgeged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 миллисекунд(s)
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
Үйлчлүүлэгчийн Java нуруулдангийн хэмжээ байтаар: 1 гиб
HBase REST серверийн үндсэн бүлэг: 3 гиб
HBase Thrift Server өгөгдмөл групп: 3 GiB
HBase мастерын Java нуруулдангийн хэмжээ байтаар: 16 гиб
HBase RegionServer-ийн Java нуруулдангийн хэмжээ байтаар: 32 гиб
+ Амьтны хүрээлэнгийн ажилтан
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', COMPRISON => 'GZ'}
Энд нэг чухал зүйл байна - DataStax-ийн тайлбарт HB хүснэгтүүдийг үүсгэхэд хэдэн бүс ашигласан талаар заагаагүй боловч энэ нь том хэмжээний хувьд чухал юм. Тиймээс туршилтын хувьд тоо хэмжээ = 64-ийг сонгосон бөгөөд энэ нь 640 ГБ хүртэл хадгалах боломжийг олгодог, өөрөөр хэлбэл. дунд хэмжээний ширээ.
Туршилтын үед HBase нь 22 мянган хүснэгт, 67 мянган бүстэй байсан (энэ нь дээр дурдсан нөхөөсгүй бол 1.2.0 хувилбарын хувьд үхэлд хүргэх байсан).
Одоо кодын тухай. Тодорхой мэдээллийн санд ямар тохиргоо илүү ашигтай байх нь тодорхойгүй байсан тул туршилтыг янз бүрийн хослолоор хийсэн. Тэдгээр. зарим туршилтанд 4 хүснэгтийг нэгэн зэрэг ачаалсан (бүх 4 зангилааг холбоход ашигласан). Бусад туршилтуудад бид 8 өөр хүснэгттэй ажилласан. Зарим тохиолдолд багцын хэмжээ 100, бусад тохиолдолд 200 (багцын параметр - доорх кодыг үзнэ үү). Утгын өгөгдлийн хэмжээ нь 10 байт эсвэл 100 байт (өгөгдлийн хэмжээ). Хүснэгт бүрт нийтдээ 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-ийн тохиргоонд ямар нэгэн саад тотгор байгаа гэсэн хардлага байдаг. Гэсэн хэдий ч Google-ээр хайж, хамгийн тодорхой параметрүүдийг (concurrent_writes эсвэл memtable_heap_space_in_mb гэх мэт) хайх нь ажлыг хурдасгасангүй. Үүний зэрэгцээ гуалин нь цэвэрхэн бөгөөд юу ч хараадаггүй.
Мэдээллийг зангилаануудад жигд тараасан, бүх зангилааны статистик нь ойролцоогоор ижил байв.
Хүснэгтийн статистик нь нэг зангилаанаас иймэрхүү харагдаж байнаТовчлуурын зай: ks
Уншсан тоо: 9383707
Унших хоцролт: 0.04287025042448576 мс
Бичгийн тоо: 15462012
Бичих хоцролт: 0.1350068438699957 ms
Хүлээгдэж буй угаалга: 0
Хүснэгт: t1
SSTable тоо: 16
Ашигласан зай (амьд): 148.59 МБ
Ашигласан зай (нийт): 148.59 МБ
Хормын хувилбаруудад ашигласан зай (нийт): 0 байт
Ашигласан овоо санах ой (нийт): 5.17 МБ
SSTable шахалтын харьцаа: 0.5720989576459437
Хуваалтын тоо (тооцоо): 3970323
Memtable эсийн тоо: 0
Memtable өгөгдлийн хэмжээ: 0 байт
Ашигласан санах ойн санах ой: 0 байт
Memtable шилжүүлэгчийн тоо: 5
Орон нутгийн уншсан тоо: 2346045
Орон нутгийн унших хоцрогдол: NaN мс
Орон нутгийн бичих тоо: 3865503
Орон нутгийн бичих хоцрогдол: NaN мс
Хүлээгдэж буй зайлуулалт: 0
Зассан хувь: 0.0
Bloom шүүлтүүрийн худал эерэг: 25
Bloom шүүлтүүрийн хуурамч харьцаа: 0.00000
Ашигласан Блум шүүлтүүрийн зай: 4.57 МБ
Ашигласан санах ойг унтраах Блум шүүлтүүр: 4.57 МБ
Ашигласан санах ойн индексийн хураангуй: 590.02 КБ
Ашигласан санах ойн шахалтын мета өгөгдөл: 19.45 КБ
Нягтруулсан хуваалтын хамгийн бага байт: 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 дахин буурдаг. Шалтгаан нь memstore илүү хурдан дүүрч, файлууд илүү олон удаа цэвэрлэгдэж, унших үед илүү олон файл боловсруулах шаардлагатай болдог нь HB-ийн хувьд нэлээд төвөгтэй ажиллагаа юм. Бодит нөхцөлд үүнийг урьдчилан хуваах, нягтруулах стратегиар бодох замаар шийдэж болно; ялангуяа бид хогоо цуглуулж, HFile-г байнга шахдаг өөрөө бичсэн хэрэгслийг ашигладаг. DataStax тестийн хувьд тэд хүснэгт бүрт зөвхөн 1 бүсийг хуваарилсан байх магадлалтай (энэ нь зөв биш) бөгөөд энэ нь HB яагаад унших тестийн хувьд тийм доогуур байгааг тодорхой хэмжээгээр тодруулах болно.
Үүнээс дараах урьдчилсан дүгнэлтийг гаргаж байна. Туршилтын явцад томоохон алдаа гаргаагүй гэж үзвэл Кассандра шавартай хөлтэй аварга том амьтан шиг харагдаж байна. Бүр тодруулбал, нийтлэлийн эхэнд байгаа зурган дээрх шиг нэг хөл дээрээ тэнцвэрээ барьж байхдаа харьцангуй сайн үр дүн үзүүлж байгаа ч ижил нөхцөлтэй тулалдаанд шууд ялагддаг. Үүний зэрэгцээ, манай техник хангамжийн CPU-ийн ашиглалт бага байгааг харгалзан бид нэг хост бүрт хоёр RegionServer HB суулгаж сурсан бөгөөд ингэснээр гүйцэтгэлийг хоёр дахин нэмэгдүүлсэн. Тэдгээр. Нөөцийн ашиглалтыг харгалзан үзвэл 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