Өдрийн мэнд Намайг Данил Липовой гэдэг, манай Sbertech-ийн баг HBase-г үйл ажиллагааны мэдээллийн сан болгон ашиглаж эхэлсэн. Үүнийг судлах явцад би системчилж, тайлбарлахыг хүссэн туршлага хуримтлуулсан (энэ нь олон хүнд хэрэг болно гэж найдаж байна). Доорх бүх туршилтыг HBase-ийн 1.2.0-cdh5.14.2 болон 2.0.0-cdh6.0.0-beta1 хувилбарууд дээр хийсэн.
- Ерөнхий архитектур
- HBASE-д өгөгдөл бичиж байна
- HBASE-ээс өгөгдлийг уншиж байна
- Өгөгдлийн кэш
- Багц өгөгдөл боловсруулах MultiGet/MultiPut
- Хүснэгтүүдийг бүс болгон хуваах стратеги (хуваах)
- Гэмтлийг тэсвэрлэх чадвар, нягтаршил, өгөгдлийн байршил
- Тохиргоо ба гүйцэтгэл
- Стресс тест
- үр дүн нь
1. Ерөнхий архитектур
Нөөц Мастер нь ZooKeeper зангилаа дээрх идэвхтэй хүний зүрхний цохилтыг сонсож, алга болсон тохиолдолд мастерын үүргийг гүйцэтгэдэг.
2. HBASE-д өгөгдөл бичих
Эхлээд хамгийн энгийн тохиолдлыг харцгаая - put(rowkey) ашиглан хүснэгтэд түлхүүр-утга объект бичих. Үйлчлүүлэгч эхлээд hbase:meta хүснэгтийг хадгалдаг Root Region Server (RRS) хаана байрлаж байгааг олж мэдэх ёстой. Тэрээр энэ мэдээллийг ZooKeeper-ээс авдаг. Үүний дараа RRS-д нэвтэрч, hbase:meta хүснэгтийг уншиж, сонирхсон хүснэгтэд өгөгдсөн эгнээний товчлуурын өгөгдлийг хадгалах үүрэгтэй RegionServer (RS) мэдээллийг гаргаж авдаг. Ирээдүйд ашиглахын тулд мета хүснэгтийг үйлчлүүлэгч кэшээр хадгалдаг тул дараагийн дуудлага нь RS руу шууд очдог.
Дараа нь RS хүсэлтийг хүлээн авсны дараа юуны түрүүнд WriteAheadLog (WAL) руу бичдэг бөгөөд энэ нь эвдэрсэн тохиолдолд сэргээхэд шаардлагатай байдаг. Дараа нь өгөгдлийг MemStore-д хадгална. Энэ нь тухайн бүс нутагт эрэмбэлэгдсэн түлхүүрүүдийг агуулсан санах ойн буфер юм. Хүснэгтийг бүс болгон (хуваалт) болгон хувааж болох бөгөөд тус бүр нь салангид товчлууруудыг агуулдаг. Энэ нь илүү өндөр гүйцэтгэлд хүрэхийн тулд бүс нутгийг өөр сервер дээр байрлуулах боломжийг танд олгоно. Гэсэн хэдий ч, энэ мэдэгдэл нь илэрхий байсан ч энэ нь бүх тохиолдолд ажиллахгүй гэдгийг бид дараа нь харах болно.
MemStore-д оруулга байршуулсны дараа харилцагчид оруулгыг амжилттай хадгалсан гэсэн хариу ирдэг. Гэсэн хэдий ч бодит байдал дээр энэ нь зөвхөн буферт хадгалагддаг бөгөөд тодорхой хугацаа өнгөрсний дараа эсвэл шинэ мэдээллээр дүүргэсний дараа л диск рүү ордог.
"Устгах" үйлдлийг гүйцэтгэх үед өгөгдлийг физик байдлаар устгадаггүй. Тэдгээрийг зүгээр л устгасан гэж тэмдэглэсэн бөгөөд 7-р зүйлд илүү дэлгэрэнгүй тайлбарласан гол авсаархан функцийг дуудах мөчид устгал өөрөө тохиолддог.
HFile форматтай файлууд HDFS-д хуримтлагддаг бөгөөд үе үе жижиг хэмжээний процессыг эхлүүлдэг бөгөөд энэ нь жижиг файлуудыг юу ч устгахгүйгээр зүгээр л том файл болгон нэгтгэдэг. Цаг хугацаа өнгөрөхөд энэ нь зөвхөн өгөгдлийг уншихад л гарч ирдэг асуудал болж хувирдаг (бид энэ талаар хэсэг хугацааны дараа эргэн ирэх болно).
Дээр дурдсан ачаалах процессоос гадна илүү үр дүнтэй журам байдаг бөгөөд энэ нь мэдээллийн сангийн хамгийн хүчтэй тал болох BulkLoad юм. Энэ нь бид HFiles-ийг бие даан бүрдүүлж, дискэн дээр байрлуулж байгаа нь биднийг төгс масштаблах, маш сайн хурдтай болгох боломжийг олгодог. Үнэн хэрэгтээ энд байгаа хязгаарлалт нь HBase биш, харин техник хангамжийн боломжууд юм. 16 RegionServers болон 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 thread), HBase хувилбар 1.2.0-cdh5.14.2-аас бүрдсэн кластер дээрх ачаалах үр дүнг доор харуулав.
Хүснэгт дэх хуваалт (бүс) болон Spark гүйцэтгэгчдийн тоог нэмэгдүүлснээр бид татаж авах хурд нэмэгдэж байгааг эндээс харж болно. Мөн хурд нь бичлэгийн хэмжээнээс хамаарна. Том блокууд нь MB/s-ийн өсөлтийг өгдөг, жижиг блокууд нь нэгж цаг тутамд оруулсан бичлэгийн тоог нэмэгдүүлдэг, бусад бүх зүйл тэнцүү байна.
Та мөн хоёр хүснэгтийг нэгэн зэрэг ачаалж эхлэх ба хурдыг хоёр дахин нэмэгдүүлэх боломжтой. Хоёр хүснэгтэд нэг дор 10 КБ блок бичих нь тус бүрдээ 600 МБ/сек хурдтай (нийт 1275 МБ/сек) явагддаг бөгөөд энэ нь нэг хүснэгтэд бичих хурд 623 МБ/сектэй давхцаж байгааг доороос харж болно. Дээрх №11)
Гэхдээ 50 КБ-ын багтаамжтай хоёр дахь гүйлт нь татаж авах хурд бага зэрэг нэмэгдэж байгаа нь хязгаарт ойртож байгааг харуулж байна. Үүний зэрэгцээ, та HBASE дээр бараг ямар ч ачаалал үүсгэдэггүй гэдгийг санах хэрэгтэй бөгөөд үүнд шаардлагатай бүх зүйл бол эхлээд hbase: meta-аас өгөгдөл өгөх, HFiles доторлогооны дараа BlockCache өгөгдлийг дахин тохируулж, хадгалах явдал юм. MemStore буфер хоосон биш бол диск рүү оруулна.
3. HBASE-ээс өгөгдөл унших
Хэрэв бид үйлчлүүлэгчид hbase:meta-ийн бүх мэдээллийг аль хэдийн авсан гэж үзвэл (2-р цэгийг үзнэ үү) хүсэлт нь шаардлагатай түлхүүр хадгалагдсан RS руу шууд очно. Нэгдүгээрт, хайлтыг MemCache дээр гүйцэтгэдэг. Өгөгдөл байгаа эсэхээс үл хамааран хайлтыг BlockCache буфер, шаардлагатай бол HFiles дотор хийдэг. Хэрэв файлаас өгөгдөл олдсон бол түүнийг BlockCache-д байршуулах бөгөөд дараагийн хүсэлтээр илүү хурдан буцаах болно. Bloom шүүлтүүрийг ашигласнаар HFile дээр хайлт харьцангуй хурдан байдаг, i.e. Бага хэмжээний өгөгдлийг уншсаны дараа энэ файлд шаардлагатай түлхүүр байгаа эсэхийг шууд тодорхойлж, хэрэв байхгүй бол дараагийнх руу шилжинэ.
Эдгээр гурван эх сурвалжаас мэдээлэл хүлээн авсны дараа RS нь хариулт үүсгэдэг. Ялангуяа, хэрэв үйлчлүүлэгч хувилбар гаргахыг хүссэн бол энэ нь объектын хэд хэдэн олдсон хувилбарыг нэгэн зэрэг шилжүүлэх боломжтой.
4. Өгөгдлийн кэш
MemStore болон BlockCache буфер нь хуваарилагдсан овоолон RS санах ойн 80 хүртэлх хувийг эзэлдэг (Үлдсэн хэсэг нь RS үйлчилгээний даалгаварт зориулагдсан). Хэрэв ердийн хэрэглээний горим нь процессууд ижил өгөгдлийг бичиж, шууд уншдаг бол BlockCache-ийг багасгаж, MemStore-г нэмэгдүүлэх нь зүйтэй. Өгөгдөл бичихийн тулд кэш рүү орохгүй бол BlockCache нь бага ашиглагддаг. BlockCache буфер нь хоёр хэсгээс бүрдэнэ: LruBlockCache (үргэлж дээр байдаг) ба BucketCache (ихэвчлэн овооноос гадуур эсвэл SSD дээр). Унших хүсэлт их байгаа бөгөөд LruBlockCache-д тохирохгүй байгаа тохиолдолд BucketCache-г ашиглах ёстой бөгөөд энэ нь Хог цуглуулагчийг идэвхтэй ажиллуулахад хүргэдэг. Үүний зэрэгцээ та уншсан кэшийг ашигласнаар гүйцэтгэл эрс нэмэгдэнэ гэж найдаж болохгүй, гэхдээ бид үүнийг 8-р зүйлд эргэн харах болно.
Бүхэл бүтэн RS-д нэг BlockCache байдаг ба хүснэгт бүрт нэг MemStore байдаг (баганын гэр бүл тус бүрт нэг).
Хэрхэн Онолын хувьд бичих үед өгөгдөл кэш рүү ордоггүй бөгөөд хүснэгтийн хувьд CACHE_DATA_ON_WRITE, RS-ийн хувьд "Cache DATA on Write" гэсэн параметрүүдийг худал гэж тохируулсан байдаг. Гэсэн хэдий ч бодит байдал дээр бид MemStore-д өгөгдөл бичиж, дараа нь диск рүү угааж (ингэснээр үүнийг цэвэрлэж), дараа нь үүссэн файлыг устгаад авах хүсэлтийг гүйцэтгэснээр бид өгөгдлийг амжилттай хүлээн авах болно. Түүнчлэн, та BlockCache-г бүрэн идэвхгүй болгож, хүснэгтийг шинэ мэдээллээр дүүргэж, дараа нь MemStore-г диск рүү дахин тохируулж, устгаад өөр сессээс хүссэн ч гэсэн тэд хаа нэгтээгээс татаж авах болно. Тиймээс HBase нь зөвхөн өгөгдөл төдийгүй нууцлаг нууцуудыг хадгалдаг.
hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
cf:c timestamp=1534440690218, value=try_to_delete_me
"Cache DATA on Read" параметрийг худал гэж тохируулсан. Хэрэв танд ямар нэгэн санаа байгаа бол сэтгэгдэл дээр хэлэлцэхийг урьж байна.
5. Багц өгөгдөл боловсруулах MultiGet/MultiPut
Ганц хүсэлтийг боловсруулах (Авах/Тайх/Устгах) нь нэлээд үнэтэй үйлдэл тул боломжтой бол тэдгээрийг Жагсаалт эсвэл Жагсаалт болгон нэгтгэх нь гүйцэтгэлийг мэдэгдэхүйц нэмэгдүүлэх боломжийг олгодог. Энэ нь ялангуяа бичих үйлдлүүдийн хувьд үнэн боловч унших үед дараах бэрхшээл тулгардаг. Доорх график нь MemStore-оос 50 бичлэг унших хугацааг харуулж байна. Унших нь нэг урсгалаар хийгдсэн бөгөөд хэвтээ тэнхлэг нь хүсэлт дэх товчлуурын тоог харуулна. Эндээс та нэг хүсэлтийн мянган түлхүүрийг нэмэгдүүлэхэд гүйцэтгэлийн хугацаа буурч байгааг харж болно. хурд нэмэгддэг. Гэсэн хэдий ч, MSLAB горимыг анхдагчаар идэвхжүүлсэн үед энэ босгоны дараа гүйцэтгэл эрс буурч эхэлдэг бөгөөд бичлэг дэх өгөгдлийн хэмжээ их байх тусам ажиллах хугацаа урт болно.
Туршилтыг виртуал машин, 8 цөм, HBase 2.0.0-cdh6.0.0-beta1 хувилбар дээр хийсэн.
MSLAB горим нь шинэ болон хуучин үеийн өгөгдлүүд холилдсоны улмаас үүсдэг нуруулдан хуваагдлыг багасгах зорилготой юм. Товч шийдэл болгон, MSLAB-г идэвхжүүлсэн үед өгөгдлийг харьцангуй жижиг нүднүүдэд (хэсэг) байрлуулж, хэсэг болгон боловсруулдаг. Үүний үр дүнд, хүссэн өгөгдлийн багц дахь хэмжээ нь хуваарилагдсан хэмжээнээс хэтэрсэн тохиолдолд гүйцэтгэл огцом буурдаг. Нөгөөтэйгүүр, энэ горимыг унтраахыг зөвлөдөггүй, учир нь энэ нь өгөгдлийг эрчимтэй боловсруулж байх үед GC-ийн улмаас зогсоход хүргэдэг. Уншихтай зэрэгцэн оруулах замаар идэвхтэй бичих тохиолдолд эсийн хэмжээг нэмэгдүүлэх нь сайн шийдэл юм. Хэрэв та бичлэг хийснийхээ дараа MemStore-г диск рүү дахин тохируулдаг flush командыг ажиллуулбал эсвэл BulkLoad ашиглан ачаалбал асуудал гарахгүй гэдгийг тэмдэглэх нь зүйтэй. Доорх хүснэгтээс харахад MemStore-оос их хэмжээний (мөн ижил хэмжээний) өгөгдөл авах хүсэлтүүд удаашралд хүргэдэг. Гэсэн хэдий ч, хэрчмийг нэмэгдүүлснээр бид боловсруулах хугацааг хэвийн болгодог.
Хэмжээг нэмэгдүүлэхээс гадна өгөгдлийг бүс нутгаар хуваах нь тусалдаг, i.e. ширээ хуваах. Үүний үр дүнд бүс бүрт цөөн хүсэлт ирдэг бөгөөд хэрэв тэдгээр нь нүдэнд багтах юм бол хариу нь сайн хэвээр байна.
6. Хүснэгтүүдийг бүс болгон хуваах стратеги (хуваах)
HBase нь түлхүүр утгын хадгалалт бөгөөд хуваалтыг түлхүүрээр гүйцэтгэдэг тул өгөгдлийг бүх бүс нутагт жигд хуваах нь маш чухал юм. Жишээлбэл, ийм хүснэгтийг гурван хэсэгт хуваах нь өгөгдлийг гурван бүсэд хуваахад хүргэдэг:
Хэрэв дараа нь ачаалагдсан өгөгдөл нь жишээлбэл, ихэнх нь ижил цифрээс эхэлдэг урт утгууд шиг харагдаж байвал энэ нь огцом удаашрахад хүргэдэг.
1000001
1000002
...
1100003
Түлхүүрүүд нь байт массив хэлбэрээр хадгалагддаг тул тэдгээр нь бүгд адилхан эхлэх бөгөөд энэ хүрээний түлхүүрүүдийг хадгалдаг нэг №1 бүсэд хамаарах болно. Хэд хэдэн хуваах стратеги байдаг:
HexStringSplit – Түлхүүрийг "00000000" => "FFFFFFFF" мужид арван зургаатын кодлогдсон мөр болгон хувиргаж, зүүн талд нь тэгээр дүүргэнэ.
UniformSplit – Түлхүүрийг "00" => "FF" мужид арван зургаатын кодчилол бүхий байт массив болгон хувиргаж, баруун талд тэгээр дүүргэнэ.
Нэмж дурдахад та хуваах ямар ч муж эсвэл багц товчлуурыг зааж өгч, автоматаар хуваахыг тохируулах боломжтой. Гэсэн хэдий ч хамгийн энгийн бөгөөд үр дүнтэй аргуудын нэг нь UniformSplit ба хэш холболтыг ашиглах явдал юм, жишээлбэл CRC32(rowkey) функц болон rowkey өөрөө дамжуулан түлхүүрийг ажиллуулахад хамгийн чухал хос байт:
хэш + rowkey
Дараа нь бүх өгөгдөл бүс нутгуудад жигд хуваарилагдах болно. Унших үед эхний хоёр байт нь зүгээр л хаягдаж, анхны түлхүүр хэвээр үлдэнэ. Мөн RS нь тухайн бүс нутаг дахь өгөгдөл, түлхүүрүүдийн хэмжээг хянадаг бөгөөд хэрэв хязгаараас хэтэрсэн бол автоматаар хэсэг болгон хуваадаг.
7. Гэмтлийг тэсвэрлэх чадвар ба өгөгдлийн байршил
Түлхүүр тус бүрийг зөвхөн нэг бүс хариуцдаг тул RS-ийн эвдрэл эсвэл ашиглалтаас хасахтай холбоотой асуудлыг шийдэх арга нь HDFS-д шаардлагатай бүх өгөгдлийг хадгалах явдал юм. RS унах үед мастер үүнийг ZooKeeper зангилаа дээр зүрхний цохилт байхгүйгээс илрүүлдэг. Дараа нь энэ нь үйлчилсэн бүсийг өөр RS-д хуваарилдаг бөгөөд HFiles нь тархсан файлын системд хадгалагддаг тул шинэ эзэмшигч нь тэдгээрийг уншиж, өгөгдөлд үргэлжлүүлэн үйлчилнэ. Гэсэн хэдий ч зарим өгөгдөл нь MemStore-д байж болох бөгөөд HFiles руу орох цаг байхгүй байсан тул үйл ажиллагааны түүхийг сэргээхэд HDFS-д хадгалагддаг WAL-г ашигладаг. Өөрчлөлтүүдийг хэрэгжүүлсний дараа RS нь хүсэлтэд хариу өгөх боломжтой боловч энэ алхам нь зарим өгөгдөл болон тэдгээрт үйлчлэх процессууд өөр өөр зангилаанууд дээр дуусдаг, жишээлбэл. газар нутаг багасч байна.
Асуудлын шийдэл бол том нягтаршил юм - энэ процедур нь файлуудыг хариуцдаг зангилаанууд руу (тэдгээрийн бүсүүд байрладаг) шилжүүлдэг бөгөөд үүний үр дүнд энэ процедурын явцад сүлжээ болон диск дээрх ачаалал эрс нэмэгддэг. Гэсэн хэдий ч ирээдүйд өгөгдөлд хандах хандалт мэдэгдэхүйц хурдасч байна. Нэмж дурдахад, major_compaction нь бүх HFiles-ийг бүс доторх нэг файлд нэгтгэхээс гадна хүснэгтийн тохиргооноос хамааран өгөгдлийг цэвэрлэдэг. Жишээлбэл, та хадгалах ёстой объектын хэдэн хувилбар эсвэл объектыг физикээр устгах хугацааг зааж өгч болно.
Энэ процедур нь HBase-ийн үйл ажиллагаанд маш эерэг нөлөө үзүүлж чадна. Доорх зураг нь идэвхтэй өгөгдөл бичлэгийн үр дүнд гүйцэтгэл хэрхэн доройтсоныг харуулж байна. Эндээс та нэг хүснэгтэд 40 хэлхээ хэрхэн бичиж, 40 хэлхээ өгөгдлийг нэгэн зэрэг уншиж байгааг харж болно. Бичгийн хэлхээ нь улам олон HFiles үүсгэдэг бөгөөд үүнийг бусад thread-ууд уншдаг. Үүний үр дүнд санах ойноос улам олон өгөгдлийг устгах шаардлагатай болж, эцэст нь GC ажиллаж эхэлдэг бөгөөд энэ нь бүх ажлыг бараг саатуулдаг. Их хэмжээний нягтруулах ажлыг эхлүүлснээр үүссэн хог хаягдлыг цэвэрлэж, бүтээмжийг сэргээхэд хүргэсэн.
Туршилтыг 3 DataNode болон 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 урсгалтай) дээр хийсэн. HBase хувилбар 1.2.0-cdh5.14.2
Мэдээллийг идэвхтэй бичиж, уншиж байсан "амьд" хүснэгтэд томоохон нягтралыг эхлүүлсэн гэдгийг тэмдэглэх нь зүйтэй. Энэ нь өгөгдлийг уншихад буруу хариу өгөхөд хүргэж болзошгүй гэсэн мэдэгдэл онлайнаар гарч байсан. Шалгахын тулд шинэ өгөгдөл үүсгэж, хүснэгтэд бичсэн процессыг эхлүүлсэн. Үүний дараа би нэн даруй уншиж, гарсан утга нь бичсэн зүйлтэй давхцаж байгаа эсэхийг шалгасан. Энэ процесс явагдаж байх үед их хэмжээний шахалтыг 200 орчим удаа хийсэн бөгөөд нэг ч удаа алдаа гаргаагүй. Асуудал нь маш ховор бөгөөд зөвхөн ачаалал ихтэй үед гарч ирдэг тул GC-ийн бууралтаас урьдчилан сэргийлэхийн тулд бичих, унших үйл явцыг төлөвлөсний дагуу зогсоож, цэвэрлэгээ хийх нь илүү аюулгүй юм.
Мөн их хэмжээний нягтаршил нь MemStore-ийн төлөв байдалд нөлөөлөхгүй бөгөөд үүнийг диск рүү угааж, нягтруулахын тулд та flush (connection.getAdmin().flush(TableName.valueOf(tblName))) ашиглах хэрэгтэй.
8. Тохиргоо ба гүйцэтгэл
Өмнө дурьдсанчлан, HBase нь BulkLoad-ийг гүйцэтгэх үед юу ч хийх шаардлагагүй тохиолдолд хамгийн том амжилтаа харуулдаг. Гэсэн хэдий ч энэ нь ихэнх систем, хүмүүст хамаатай. Гэсэн хэдий ч, энэ хэрэгсэл нь өгөгдлийг бөөнөөр нь том блок болгон хадгалахад илүү тохиромжтой бөгөөд хэрэв процесс нь унших, бичих олон хүсэлтийг шаарддаг бол дээр дурдсан Get, Put командуудыг ашигладаг. Хамгийн оновчтой параметрүүдийг тодорхойлохын тулд хүснэгтийн параметр, тохиргооны янз бүрийн хослолоор хөөргөх ажлыг гүйцэтгэсэн.
- 10 урсгалыг нэгэн зэрэг 3 удаа дараалан эхлүүлсэн (үүнийг хэлхээний блок гэж нэрлэе).
- Блок дахь бүх утаснуудын ажиллах хугацааг дундажласан бөгөөд энэ нь блокийн үйл ажиллагааны эцсийн үр дүн юм.
- Бүх утаснууд нэг хүснэгттэй ажилласан.
- Утасны блокыг эхлүүлэх бүрийн өмнө томоохон нягтралыг гүйцэтгэсэн.
- Блок бүр дараах үйлдлүүдийн зөвхөн нэгийг нь гүйцэтгэсэн.
-Тав
- Ав
-Авах+Тавих
- Блок бүр үйл ажиллагааныхаа 50 давталт хийсэн.
- Бичлэгийн блокийн хэмжээ нь 100 байт, 1000 байт эсвэл 10000 байт (санамсаргүй) байна.
- Хүссэн өөр өөр тооны түлхүүрээр блокуудыг эхлүүлсэн (нэг түлхүүр эсвэл 10).
- Блокуудыг өөр өөр хүснэгтийн тохиргооны дор ажиллуулсан. Өөрчлөгдсөн параметрүүд:
— BlockCache = асаалттай эсвэл унтраасан
- BlockSize = 65 KB эсвэл 16 KB
- Хуваалтууд = 1, 5 эсвэл 30
— MSLAB = идэвхжүүлсэн эсвэл идэвхгүй болгосон
Тиймээс блок дараах байдлаар харагдаж байна.
а. MSLAB горимыг асаасан/унтраасан.
б. Дараах параметрүүдийг тохируулсан хүснэгтийг үүсгэсэн: BlockCache = үнэн/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
в. Шахалтыг GZ гэж тохируулсан.
г. Энэ хүснэгтэд 10/1/10 байт бичлэг бүхий 100/1000 put/get/get+put үйлдлүүд хийж, 10000 асуулга дараалсан (санамсаргүй товчлуурууд) гүйцэтгэх 50 хэлхээг нэгэн зэрэг эхлүүлсэн.
д. d цэгийг гурван удаа давтана.
е. Бүх утаснуудын ажиллах хугацааг дунджаар тооцсон.
Бүх боломжит хослолуудыг туршиж үзсэн. Бичлэгийн хэмжээ ихсэх тусам хурд буурах эсвэл кэшийг идэвхгүй болгосноор удаашрахыг урьдчилан таамаглах боломжтой. Гэсэн хэдий ч зорилго нь параметр бүрийн нөлөөллийн зэрэг, ач холбогдлыг ойлгох явдал байсан тул цуглуулсан өгөгдлийг шугаман регрессийн функцын оролтод оруулсан бөгөөд энэ нь t-статистикийг ашиглан ач холбогдлыг үнэлэх боломжтой болгодог. Put үйлдлийг гүйцэтгэж буй блокуудын үр дүнг доор харуулав. 2*2*3*2*3 хослолын бүрэн багц = 144 сонголт + 72 tk. заримыг нь хоёр удаа хийсэн. Тиймээс нийт 216 гүйлт байна:
Туршилтыг 3 DataNode ба 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 утас) -аас бүрдсэн мини кластер дээр хийсэн. HBase хувилбар 1.2.0-cdh5.14.2.
MSLAB горимыг унтраасан, нэг хуваалттай ширээн дээр, BlockCache-г идэвхжүүлсэн, BlockSize = 3.7, 16 байт бичлэг, нэг багцад 100 ширхэг байх үед 10 секундын хамгийн өндөр оруулах хурдыг олж авсан.
82.8 секундын хамгийн бага оруулах хурдыг MSLAB горимыг идэвхжүүлсэн үед, нэг хуваалттай хүснэгтэд, BlockCache идэвхжүүлсэн, BlockSize = 16, тус бүр 10000 байт, 1 байт бичлэгтэй үед авсан.
Одоо загварыг харцгаая. R2 дээр суурилсан загварын сайн чанарыг бид харж байгаа боловч энд экстраполяци хийх нь эсрэг заалттай байгаа нь туйлын тодорхой юм. Параметрүүд өөрчлөгдөх үед системийн бодит байдал нь шугаман биш байх болно, энэ загвар нь урьдчилан таамаглахад биш, харин өгөгдсөн параметрийн хүрээнд юу болсныг ойлгоход хэрэгтэй. Жишээлбэл, бид Оюутны шалгуураас харахад BlockSize болон BlockCache параметрүүд нь Put үйлдлийн хувьд хамаагүй (энэ нь ерөнхийдөө урьдчилан таамаглах боломжтой):
Гэхдээ хуваалтын тоог нэмэгдүүлэх нь гүйцэтгэл буурахад хүргэдэг нь зарим талаараа гэнэтийн зүйл юм (Бид BulkLoad ашиглан хуваалтын тоог нэмэгдүүлэх эерэг нөлөөллийг аль хэдийн харсан), ойлгомжтой ч гэсэн. Нэгдүгээрт, боловсруулахын тулд та нэг биш харин 30 бүс нутагт хүсэлт гаргах ёстой бөгөөд өгөгдлийн хэмжээ нь ашиг олохгүй. Хоёрдугаарт, нийт ажиллах хугацааг хамгийн удаан RS-ээр тодорхойлдог бөгөөд DataNodes-ийн тоо нь RS-ийн тооноос бага байдаг тул зарим бүс нутагт тэг байршилтай байдаг. За, эхний тавыг харцгаая:
Одоо Get блокуудыг гүйцэтгэх үр дүнг үнэлье:
Хуваалтын тоо нь ач холбогдлоо алдсан бөгөөд энэ нь өгөгдөл сайн хадгалагдсан, унших кэш нь хамгийн чухал (статистикийн) параметртэй холбоотой байж магадгүй юм. Мэдээжийн хэрэг, хүсэлт дэх мессежийн тоог нэмэгдүүлэх нь гүйцэтгэлд маш их хэрэгтэй байдаг. Шилдэг оноо:
За, эцэст нь эхлээд авч, дараа нь тавьсан блокны загварыг харцгаая.
Энд бүх параметрүүд чухал ач холбогдолтой. Мөн удирдагчдын үр дүн:
9. Ачааллын туршилт
За, эцэст нь бид илүү их эсвэл бага хэмжээний ачааллыг эхлүүлэх болно, гэхдээ танд харьцуулах зүйл байвал үргэлж илүү сонирхолтой байдаг. Кассандрагийн гол хөгжүүлэгч DataStax-ийн вэбсайт дээр байдаг HBase хувилбар 0.98.6-1 зэрэг олон тооны NoSQL хадгалалтын NT. Ачаалах ажиллагааг 40 урсгал, өгөгдлийн хэмжээ 100 байт, SSD дискээр гүйцэтгэсэн. Унших-Өөрчлөх-Бичих үйлдлийг турших үр дүнд дараах үр дүн гарлаа.
Миний ойлгож байгаагаар унших нь 100 бичлэгийн блокуудад хийгдсэн бөгөөд 16 HBase зангилааны хувьд DataStax тест нь секундэд 10 мянган үйлдлийн гүйцэтгэлийг харуулсан.
Манай кластер нь бас 16 зангилаатай нь азтай ч тус бүр нь 64 цөмтэй (threads) тийм ч "азтай" биш бол DataStax тестэд ердөө 4 байдаг. Нөгөө талаар тэдгээр нь SSD хөтчүүдтэй байхад манайд HDD байдаг. эсвэл түүнээс дээш ачааллын үед HBase-ийн шинэ хувилбар ба CPU-ийн ашиглалт бараг мэдэгдэхүйц нэмэгдээгүй (харааны хувьд 5-10 хувиар). Гэсэн хэдий ч, энэ тохиргоог ашиглаж эхлэхийг хичээцгээе. Хүснэгтийн өгөгдмөл тохиргоо, уншилтыг 0-ээс 50 сая хүртэлх гол мужид санамсаргүй байдлаар гүйцэтгэдэг (жишээ нь, цаг тутамд үндсэндээ шинэ). Хүснэгт нь 50 хуваалтад хуваагдсан 64 сая бичлэгийг агуулдаг. Түлхүүрүүдийг crc32 ашиглан хэш хийсэн. Хүснэгтийн тохиргоо нь анхдагч бөгөөд MSLAB идэвхжсэн. 40 урсгалыг эхлүүлснээр хэлхээ бүр 100 санамсаргүй товчлуурын багцыг уншиж, үүсгэсэн 100 байтыг эдгээр товчлуурууд руу шууд бичнэ.
Тавиур: 16 DataNode ба 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 утас). HBase хувилбар 1.2.0-cdh5.14.2.
Дундаж үр дүн нь секундэд 40 мянган үйлдэлтэй ойрхон байгаа нь DataStax тестээс хамаагүй дээр юм. Гэсэн хэдий ч туршилтын зорилгоор та нөхцөлийг бага зэрэг өөрчилж болно. Бүх ажлыг зөвхөн нэг ширээн дээр, мөн зөвхөн өвөрмөц түлхүүрүүд дээр хийх нь магадлал багатай юм. Үндсэн ачааллыг үүсгэдэг тодорхой "халуун" товчлуурууд байдаг гэж бодъё. Тиймээс, илүү том бичлэг (10 KB) бүхий ачааллыг 100 багцаар, 4 өөр хүснэгтэд, хүссэн түлхүүрүүдийн хүрээг 50 мянга хүртэл хязгаарлахыг хичээцгээе. Доорх график нь 40 хэлхээг эхлүүлж байгааг харуулж байна. 100 товчлуурын багц бөгөөд нэн даруй эдгээр товчлуурууд дээр санамсаргүй 10 KB бичдэг.
Тавиур: 16 DataNode ба 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 утас). HBase хувилбар 1.2.0-cdh5.14.2.
Ачааллын үед үндсэн шахалтыг хэд хэдэн удаа эхлүүлсэн бөгөөд дээр дурдсанчлан, энэ процедургүйгээр гүйцэтгэл аажмаар буурах боловч гүйцэтгэх явцад нэмэлт ачаалал үүсдэг. Бууралт нь янз бүрийн шалтгааны улмаас үүсдэг. Заримдаа утаснууд ажиллаж дуусч, дахин эхлүүлэх үед түр зогсолт гардаг, заримдаа гуравдагч талын програмууд кластер дээр ачаалал үүсгэдэг.
Унших, шууд бичих нь HBase-ийн ажлын хамгийн хэцүү хувилбаруудын нэг юм. Хэрэв та 100 байт, жишээлбэл, 10-50 мянган ширхэг багц болгон нийлүүлэх жижиг хүсэлтүүдийг хийвэл секундэд хэдэн зуун мянган үйлдэл хийх боломжтой бөгөөд нөхцөл байдал зөвхөн унших хүсэлттэй төстэй байна. Үр дүн нь DataStax-ийн олж авсан үр дүнгээс эрс дээрдсэн гэдгийг тэмдэглэх нь зүйтэй бөгөөд энэ нь хамгийн гол нь 50 мянган блокийн хүсэлтээс үүдэлтэй юм.
Тавиур: 16 DataNode ба 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 утас). HBase хувилбар 1.2.0-cdh5.14.2.
10. Дүгнэлт
Энэ систем нь нэлээд уян хатан тохируулагдсан боловч олон тооны параметрийн нөлөөлөл тодорхойгүй хэвээр байна. Тэдгээрийн заримыг нь туршиж үзсэн боловч үр дүнгийн тестийн багцад оруулаагүй болно. Жишээлбэл, урьдчилсан туршилтаар хөрш зэргэлдээх нүднүүдийн утгыг ашиглан мэдээллийг кодлодог DATA_BLOCK_ENCODING гэх мэт параметрийн ач холбогдол бага байгааг харуулсан бөгөөд энэ нь санамсаргүй байдлаар үүсгэгдсэн өгөгдөлд ойлгомжтой юм. Хэрэв та олон тооны давхардсан объектуудыг ашигладаг бол ашиг нь мэдэгдэхүйц байх болно. Ерөнхийдөө HBase нь нэлээд нухацтай, сайтар бодож боловсруулсан мэдээллийн сан гэсэн сэтгэгдэл төрүүлдэг бөгөөд энэ нь их хэмжээний өгөгдлийн блокуудтай ажиллахад нэлээд үр дүнтэй байдаг. Ялангуяа унших, бичих үйл явцыг цаг хугацаанд нь салгах боломжтой бол.
Хэрэв таны бодлоор хангалттай дэлгэгдээгүй ямар нэг зүйл байвал би танд илүү дэлгэрэнгүй ярихад бэлэн байна. Хэрэв та ямар нэг зүйлтэй санал нийлэхгүй байвал туршлагаа хуваалцах эсвэл ярилцахыг урьж байна.
Эх сурвалж: www.habr.com