Gelek kes bi Elasticsearch re têkoşîn dikin. Lê çi diqewime gava ku hûn dixwazin wê bikar bînin da ku têketin "di cildek bi taybetî mezin" de hilînin? Û gelo ceribandina têkçûna yek ji çend navendên daneyê jî bê êş e? Divê hûn çawa avahîsaziyek çêbikin, û hûn ê li ser kîjan xeletiyan bikevin?
Me li Odnoklassniki biryar da ku em elasticsearch-ê bikar bînin da ku pirsgirêka rêveberiya têketinê çareser bikin, û naha em ezmûna xwe bi Habr re parve dikin: hem di derbarê mîmariyê de û hem jî di derbarê qulikan de.
Ez Pyotr Zaitsev im, ez wekî rêveberê pergalê li Odnoklassniki dixebitim. Berî wê, ez jî rêveber bûm, bi Manticore Search, Sphinx search, Elasticsearch re xebitîm. Dibe ku, ger ...lêgerînek din xuya bibe, dibe ku ez ê jî pê re bixebitim. Ez jî bi dilxwazî beşdarî gelek projeyên çavkaniya vekirî dibim.
Dema ku ez hatim Odnoklassniki, min di hevpeyvînê de bêhemdî got ku ez dikarim bi Elasticsearch re bixebitim. Piştî ku min ew bi dest xist û hin karên hêsan temam kirin, ji min re peywira mezin a reformkirina pergala rêveberiya têketinê ya ku di wê demê de hebû hate dayîn.
daxwazên
Pêdiviyên pergalê bi vî rengî hatine damezrandin:
- Diviyabû ku Graylog wekî pêşek were bikar anîn. Ji ber ku pargîdanî berê xwedan ezmûna karanîna vê hilberê bû, bernamesaz û ceribandinvanan ew dizanibû, ew ji wan re nas û rehet bû.
- Hêjmara daneyê: bi navînî 50-80 hezar peyam di saniyeyê de, lê heke tiştek bişkê, wê hingê seyrûsefer ji hêla tiştek ve nayê sînorkirin, ew dikare di çirkeyê de 2-3 mîlyon xet be.
- Piştî ku bi xerîdaran re li ser hewcedariyên ji bo leza hilberandina pirsên lêgerînê nîqaş kirin, me fêm kir ku şêwaza gelemperî ya karanîna pergalek weha ev e: mirov van du rojên dawîn li têketinên serîlêdana xwe digerin û naxwazin ji yek bêtir li bendê bin. duyemîn ji bo encama pirsek formulekirî.
- Rêvebiran israr kirin ku ger hewce bike pergal bi hêsanî berbelav bibe, bêyî ku hewce bike ku ew bi kûrahî li ka çawa dixebite.
- Ji ber vê yekê tenê peywira lênêrînê ya ku van pergalên periyodîk hewce dike ev e ku meriv hin hardware biguhezîne.
- Wekî din, Odnoklassniki xwedan kevneşopiyek teknîkî ya hêja ye: her karûbarek ku em dest pê dikin divê ji têkçûna navenda daneyê (ji nişka ve, neplankirî û bêkêmasî di her kêliyê de) sax bimîne.
Pêdiviya dawî ya di pêkanîna vê projeyê de herî zêde mesrefa me kir, ku ez ê bi berfirehî behsa wê bikim.
Çarşem
Em li çar navendên daneyê dixebitin, dema ku girêkên daneya Elasticsearch tenê dikarin di sê de cih bigirin (ji ber çend sedemên ne-teknîkî).
Van çar navendên daneyê bi qasî 18 hezar çavkaniyên têketinê yên cihêreng hene - hardware, konteynir, makîneyên virtual.
Taybetmendiya girîng: kom di konteyneran de dest pê dike ne li ser makîneyên fîzîkî, lê li ser . Konteyner 2 core, mîna 2.0Ghz v4, bi îhtîmala vezîvirandina navikên mayî ger ew bêkar bin, garantî dikin.
Bi gotineke din:
Topology
Min di destpêkê de forma giştî ya çareseriyê wiha dît:
- 3-4 VIP li pişt A-qeyda domaina Graylogê ne, ev navnîşana ku têketin jê re têne şandin e.
- her VIP balansek LVS ye.
- Piştî wê, têketin diçin bataryaya Graylog, hin dane bi formata GELF, hin jî di forma syslogê de ne.
- Dûv re ev hemî di beşên mezin de li bataryayek koordînatorên Elasticsearch têne nivîsandin.
- Û ew, di encamê de, daxwazên nivîsandinê û xwendinê ji girêkên daneyên têkildar re dişînin.
Terminolojiyê
Dibe ku her kes ji termînolojiyê bi hûrgulî fêm neke, ji ber vê yekê ez dixwazim hinekî li ser rawestim.
Elasticsearch çend celeb nod hene - master, koordînator, girê dane. Ji bo veguheztinên têketinê û danûstendina di navbera komên cûda de du celebên din hene, lê me tenê yên ku hatine navnîş kirin bikar anîn.
Mamoste
Ew hemî girêkên ku di komê de hene ping dike, nexşeyek komê ya nûjen diparêze û wê di navbera girêkan de belav dike, mentiqê bûyerê pêvajo dike, û cûrbecûr kargêriya xaniyek grûpê pêk tîne.
Koordînator
Yek peywirek yekane pêk tîne: daxwazên xwendin an nivîsandinê ji xerîdaran qebûl dike û vê seyrûseferê rêve dike. Ger daxwazek nivîsandinê hebe, bi îhtîmalek mezin, ew ê ji masterê bipirse ka kîjan perçeya pêveka têkildar divê ew têxe hundurê, û dê daxwazê bêtir beralî bike.
Nodeya daneyê
Daneyên hilanînê, pirsên lêgerînê yên ku ji derve tên pêk tîne û operasyonan li ser perçeyên ku li ser wê ne pêk tîne.
graylog
Ev tiştek mîna tevlihevkirina Kibana bi Logstash re di stûnek ELK de ye. Graylog hem UI û hem jî boriyek pêvajoyek têketinê bi hev re dike. Di bin serpêhatiyê de, Graylog Kafka û Zookeeper-ê dimeşîne, ku pêwendiyê bi Graylog re wekî komek peyda dikin. Ger Elasticsearch ne berdest be, Graylog dikare têketin (Kafka) cache bike û daxwazên xwendin û nivîsandinê yên neserkeftî dubare bike, li gorî qaîdeyên diyarkirî têketin kom bike û nîşan bide. Mîna Logstash, Graylog fonksiyonek heye ku rêzan biguhezîne berî ku wan li Elasticsearch binivîse.
Wekî din, Graylog xwedan vedîtinek karûbarek çêkirî ye ku dihêle, li ser bingeha yek girêkek Elasticsearch-ya berdest, tevahiya nexşeya komê bi dest bixe û wê ji hêla tagek taybetî ve fîlter bike, ku ev yek gengaz dike ku serlêdanan berbi konteynerên taybetî ve bike.
Bi dîtbarî tiştek wiha xuya dike:
Ev dîmenek ji mînakek taybetî ye. Li vir em li ser bingeha pirsa lêgerînê histogramek ava dikin û rêzên têkildar nîşan didin.
Indexes
Vegera mîmariya pergalê, ez dixwazim bi hûrgulî bisekinim ka me çawa modela indexê çêkir da ku ew hemî rast bixebite.
Di diagrama jor de, ev asta herî nizm e: Girêdanên daneya Elasticsearch.
Indeks sazûmanek mezin a virtual e ku ji perçeyên Elasticsearch pêk tê. Bi serê xwe, her yek ji şikestinan ji navnîşek Lucene ne tiştek din e. Û her navnîşek Lucene, di encamê de, ji yek an bêtir beşan pêk tê.
Dema sêwiranê, me fêhm kir ku ji bo ku em hewcedariya leza xwendinê li ser hejmareke mezin a daneyan bicîh bînin, pêdivî ye ku em van daneyan bi rengek wekhev li nav girêkên daneyê "belav bikin".
Vê yekê di rastiyê de encam da ku divê jimara perçeyên per index (bi replicayan) bi hişkî bi hejmara girêkên daneyê re wekhev be. Ya yekem, ji bo ku em faktorek dubarekirinê ya duduyan misoger bikin (ango, em dikarin nîvê komê winda bikin). Û, ya duyemîn, ji bo ku bi kêmî ve nîvê komê daxwazên xwendin û nivîsandinê bişopînin.
Me pêşî dema hilanînê wekî 30 roj diyar kir.
Dabeşkirina perçeyan dikare bi grafîkî wekî jêrîn were destnîşan kirin:
Tevahiya çargoşeya gewr a tarî nîşanek e. Çargoşeya sor a çepê di wê de şûşeya seretayî ye, di îndeksê de yekem e. Û çargoşeya şîn şiklê replica ye. Ew li navendên daneyên cuda hene.
Dema ku em şiklekek din lê zêde dikin, ew diçe navenda daneya sêyemîn. Û, di dawiyê de, em vê strukturê digirin, ku dihêle hûn DC-yê winda bikin bêyî ku hevgirtina daneyê winda bikin:
Zivirîna îndeksan, yanî. îndekseke nû biafirîne û ya herî kevn jê bibe, me ew kir 48 saetan (li gorî şêwaza karanîna îndeksê: 48 demjimêrên dawîn pir caran têne lêgerîn).
Ev navbera zivirîna indexê ji ber sedemên jêrîn e:
Gava ku daxwazek lêgerînê digihîje girêkek daneya taybetî, wê hingê, ji hêla performansê ve, gava ku yek şûşeyek were pirsîn, heke mezinahiya wê bi mezinahiya girêka girêkê re were berhev kirin, sûdmendtir e. Ev dihêle hûn beşa "germ" a pêvekê di nav hev de bihêlin û zû bigihîjin wê. Dema ku gelek "beşên germ" hene, leza lêgerîna navnîşê kêm dibe.
Dema ku girêkek li ser yek perçek dest bi pêkanîna pirsek lêgerînê dike, ew bi qasî hejmarên hîperthreading ên makîneya fizîkî jimarek têlan vediqetîne. Ger pirsek lêgerînek li hejmareke mezin a şûşeyan bandor dike, wê hingê hejmara têlan bi rêjeyî mezin dibe. Ev bandorek neyînî li ser leza lêgerînê dike û bandorek neyînî li ser nîşankirina daneyên nû dike.
Ji bo peydakirina derengiya lêgerînê ya pêwîst, me biryar da ku em SSD bikar bînin. Ji bo ku zû serlêdanan bişopînin, makîneyên ku van konteyneran mêvandar dikin diviyabû ku bi kêmî ve 56 core hebin. Hêjmara 56 wekî nirxek têra şertî hate hilbijartin ku hejmara tîrêjên ku Elasticsearch dê di dema xebatê de çêbike destnîşan dike. Di Elasitcsearch-ê de, gelek parametreyên hewza têlan rasterast bi hejmara navikên berdest ve girêdayî ne, ku di encamê de rasterast li gorî prensîba "kêm naverok - bêtir girêk" bandorê li ser hejmara hewce ya girêkên di komê de dike.
Wekî encamek, me dît ku bi navînî şûrek bi qasî 20 gîgabayt giran e, û her pêdekek 1 şûr hene. Li gorî vê, ger em wan her 360 saetan carekê bizivirînin, wê demê 48 ji wan hene. Her index daneyên 15 rojan dihewîne.
Danûstandin û nivîsandina danûstendinê
Ka em fêr bibin ka data di vê pergalê de çawa têne tomar kirin.
Em bibêjin ku hin daxwazek ji Graylogê digihîje koordînatorê. Ji bo nimûne, em dixwazin 2-3 hezar rêzan nîşan bikin.
Koordînator, piştî ku daxwazek ji Graylog wergirt, ji masterê dipirse: "Di daxwaznameya îndekskirinê de, me bi taybetî pêdekek diyar kir, lê di kîjan şiklê de nivîsandina wê nehat diyar kirin."
Mamoste bersivê dide: "Vê agahiyê li jimareya 71-ê binivîsin," pişt re ew rasterast ji girêka daneya têkildar re tê şandin, ku li wir jimareya 71-a-sharda bingehîn lê ye.
Piştî ku têketina danûstendinê li replica-shard, ku di navendek daneya din de ye, tê dubare kirin.
Daxwazek lêgerînê ji Graylog digihîje koordînatorê. Koordînator wê li gorî îndeksê beralî dike, dema ku Elasticsearch bi karanîna prensîba dor-robin daxwazan di navbera seretayî-shard û replica-shard de belav dike.
180 nod bi rengek neyeksan bersiv didin, û dema ku ew bersiv didin, koordînator agahdariya ku ji berê ve ji hêla girêkên daneya bilez ve hatî "pifandin" berhev dike. Piştî vê yekê, gava ku hemî agahdarî gihîştin, an jî daxwaz gihîşt demek dirêj, ew her tiştî rasterast dide xerîdar.
Tevahiya vê pergalê bi navînî pirsên lêgerînê di 48 demjimêrên paşîn de di 300-400ms de pêvajoyê dike, ji bilî van pirsan bi xiftanek sereke.
Kulîlkên bi Elasticsearch: Sazkirina Java
Ji bo ku ew hemî bi awayê ku me di eslê xwe de dixwest bixebite, me demek pir dirêj derbas kir ku cûrbecûr tiştên di komê de xelet kirin.
Beşa yekem a pirsgirêkên ku hatine vedîtin bi awayê ku Java ji hêla xwerû ve di Elasticsearch-ê de pêş-vesazkirî ye ve girêdayî bû.
Pirsgirêk yek
Me hejmareke pir mezin a raporan dît ku di asta Lucene de, dema ku karên paşîn têne xebitandin, yekbûna beşa Lucene bi xeletiyek têk diçe. Di heman demê de, di qeydan de diyar bû ku ev xeletiyek OutOfMemoryError bû. Me ji telemetrîyê dît ku hip azad e, û ne diyar bû ku çima ev operasyon bi ser neket.
Derket holê ku îndeksa Lucene li derveyî hipê pêk tê. Û konteynir di warê çavkaniyên ku têne bikar anîn de pir hişk in. Tenê heap dikaribû di van çavkaniyan de cîh bigirta (nirxa heap.size bi qasî RAM-ê bû), û hin operasyonên off-heap bi xeletiyek veqetandina bîranînê têk çûn heke ji ber hin sedeman ew nekevin nav ~500MB ya ku li ber sînor mabû.
Serastkirin pir hindik bû: mîqdara RAM-a ku ji bo konteynerê peyda dibe zêde bû, piştî ku me ji bîr kir ku me jî pirsgirêkên weha hebûn.
Pirsgirêk du
4-5 roj piştî destpêkirina komê, me ferq kir ku girêkên daneyê dest bi periyodîk ji komê derdikevin û piştî 10-20 çirkeyan têkevin wê.
Dema ku me dest bi fêhmkirina wê kir, derket holê ku ev bîranîna bêserûber di Elasticsearch de bi tu awayî nayê kontrol kirin. Gava ku me bêtir bîranîn da konteynerê, me karî hewzên tamponê yên rasterast bi agahdariya cihêreng tijî bikin, û ew tenê piştî ku GC-ya eşkere ji Elasticsearch hate destpêkirin hate paqij kirin.
Di hin rewşan de, vê operasyonê demek pir dirêj girt, û di vê demê de komê karî vê nodê wekî ku berê derketiye nîşan bide. Ev pirsgirêk baş tê vegotin .
Çareserî bi vî rengî bû: me şiyana Java-yê sînordar kir ku ji bo van operasyonan piranîya bîranînê li dervayê giravê bikar bîne. Me ew bi 16 gîgabaytan (-XX:MaxDirectMemorySize=16g) bi sînor kir, piştrast kir ku GC-ya eşkere pir caran pirtir tê gazî kirin û pir zûtir tête pêvajo kirin, bi vî rengî êdî komê bêîstîkrar nake.
Pirsgirêk sê
Ger hûn difikirin ku pirsgirêkên "girêdan di demek herî nediyar de ji komê derdikevin" qediyan, hûn xelet in.
Dema ku me kar bi indexan vesaz kir, me mmapfs hilbijart li ser perçeyên nû yên bi dabeşkirina mezin. Ev pir xeletiyek bû, ji ber ku dema ku mmapfs bikar tînin pel di RAM-ê de tê nexşandin, û dûv re em bi pelê nexşeyê re dixebitin. Ji ber vê yekê, derdikeve holê ku gava GC hewl dide ku mijarên di serîlêdanê de rawestîne, em ji bo demek pir dirêj diçin cîhê ewlehiyê, û di rê de, serîlêdan bersivê dide daxwazên masterê di derheqê ka ew sax e. . Li gorî vê yekê, master bawer dike ku girêk êdî di komê de nemaye. Piştî vê yekê, piştî 5-10 çirkeyan, berhevkarê çopê dixebite, girêk zindî dibe, ji nû ve dikeve nav komê û dest bi destpêkirina şûşeyan dike. Hemî wekî "hilberîna ku me heq kiriye" hîs dikir û ji bo tiştek cidî ne maqûl bû.
Ji bo ku em ji vê tevgerê xilas bibin, me pêşî veguherand niofên standard, û dûv re, gava ku em ji guhertoyên pêncemîn ên Elastic koçî şeşemîn kirin, me hybridfs ceribandiye, ku ev pirsgirêk nehat dubare kirin. Hûn dikarin li ser celebên hilanînê bêtir bixwînin .
Pirsgirêk çar
Dûv re pirsgirêkek din a pir balkêş hebû ku me ji bo demek rekor derman kir. Me 2-3 mehan ew girt ji ber ku qalibê wê bi tevahî nedihat famkirin.
Carinan koordînatorên me diçûn Full GC, bi gelemperî piştî nîvro, û qet ji wir venegeriyan. Di heman demê de, dema ku derengiya GC tê tomar kirin, wusa xuya bû: her tişt baş, baş, baş dimeşe, û dûv re ji nişkê ve her tişt pir xirab diçe.
Di destpêkê de me fikirîn ku me bikarhênerek xirab heye ku hin daxwazek ku hevrêzkar ji moda xebatê derdixist derdixist pêş. Me daxwazname ji bo demek pir dirêj tomar kir, hewl da ku fêm bikin ka çi diqewime.
Wekî encamek, derket holê ku di dema ku bikarhênerek daxwazek mezin dide, û ew digihîje koordînatorek taybetî ya Elasticsearch, hin nod ji yên din dirêjtir bersiv didin.
Û dema ku koordînator li benda bersivek ji hemî girêkan e, ew encamên ku ji girêkên ku berê bersiv dane hatine şandin berhev dike. Ji bo GC, ev tê vê wateyê ku şêwazên karanîna meya hepê pir zû diguhezin. Û GC-ya ku me bikar anî nekarî bi vî karî rabe.
Yekane rastkirina ku me dît ku di vê rewşê de behreya komê biguhezîne koçkirina JDK13 û karanîna berhevkarê çopê Shenandoah e. Bi vê yekê pirsgirêk çareser bû, koordînatorên me rawestiyan.
Li vir pirsgirêkên Java-yê bi dawî bûn û pirsgirêkên bandwidth dest pê kir.
"Berries" bi Elasticsearch: berbi
Pirsgirêkên bi guheztinê tê vê wateyê ku koma me bi îstîqrar dixebite, lê di lûtkeya hejmara belgeyên pêvekirî de û di dema manevrayan de, performans têrê nake.
Nîşaneya yekem ku rû da: di dema hin "teqanan" de di hilberînê de, gava ku ji nişka ve hejmareke pir mezin têketin têne çêkirin, xeletiya îndekskirinê es_rejected_execution bi gelemperî di Graylog de dest pê dike.
Ev ji ber wê yekê bû ku thread_pool.write.queue li ser yek girêka daneyê, heya dema ku Elasticsearch karibe daxwaza îndekskirinê bişopîne û agahiyê li ser perçeya li ser dîskê barbike, dikare bi xweber tenê 200 daxwazan cache bike. Û di Li ser vê parameterê pir kêm tê gotin. Tenê hejmara herî zêde ya mijaran û mezinahiya xwerû têne destnîşan kirin.
Bê guman, me çû ku vê nirxê zivirîn û jêrîn fêr bûn: bi taybetî, di sazkirina me de, heya 300 daxwazî pir baş têne cache kirin, û nirxek bilindtir bi vê yekê ve girêdayî ye ku em dîsa difirin nav Full GC.
Wekî din, ji ber ku ev komikên peyaman in ku di nav yek daxwazê de digihîjin, pêdivî bû ku Graylog biguhezîne da ku ew ne pir caran û di beşên piçûk de, lê di beşên mezin de binivîsîne an jî her 3 çirkeyan carekê heke berhevok hîn neqede binivîsîne. Di vê rewşê de, derdikeve holê ku agahdariya ku em di Elasticsearch-ê de dinivîsin ne di du saniyeyan de, lê di pênc saniyan de peyda dibe (ku ji me re pir xweş tê), lê jimara paşvekêşanên ku divê bêne çêkirin da ku bi rê ve bibin. berhevoka agahdariyê kêm dibe.
Ev bi taybetî di wan kêliyan de girîng e ku tiştek li deverek têk çûye û bi hêrs di derbarê wê de rapor dike, da ku Elasticek bi tevahî spamkirî nebîne, û piştî demekê - girêkên Graylog ên ku ji ber tamponên girtî nexebitîne.
Wekî din, dema ku me heman teqîn di hilberînê de hebûn, me gilî ji bernameçêker û ceribandinvanan wergirt: di dema ku ew bi rastî hewcedariya wan bi van logan bûn, ew pir hêdî têne dayîn.
Wan dest pê kir ku wê fêm bikin. Ji aliyek ve, eşkere bû ku hem pirsên lêgerînê û hem jî pirsên îndekskirinê, di bingeh de, li ser heman makîneyên laşî hatine pêvajo kirin, û bi rengekî din dê hin vekêşan hebin.
Lê ev dibe ku hinekî were dorpêç kirin ji ber vê yekê ku di guhertoyên şeşemîn ên Elasticsearch de, algorîtmayek xuya bû ku dihêle hûn ne li gorî prensîba dor-robinê ya bêserûber pirsan di navbera girêkên daneya têkildar de belav bikin (konteynir ku îndekskirinê dike û ya bingehîn digire. -shard dikare pir mijûl be, dê rêyek ji bo bersivdana bilez tune be), lê ji bo şandina vê daxwazê ji konteynirek kêmtir barkirî ya bi replica-shard re, ku dê pir zûtir bersivê bide. Bi gotinên din, em gihîştin use_adaptive_replica_selection: rast.
Wêneyê xwendinê bi vî rengî dest pê dike:
Veguheztina vê algorîtmayê îmkan da ku em di wan kêliyan de dema ku me ji bo nivîsandinê herikînek mezin a têketin hebûn bi girîngî baştirkirina dema lêpirsînê.
Di dawiyê de, pirsgirêka sereke rakirina bê êş a navenda daneyê bû.
Tiştê ku me ji komê xwest tavilê piştî windakirina girêdana bi yek DC re:
- Ger di navenda daneya têkçûyî de masterek me ya heyî hebe, wê hingê ew ê ji nû ve were hilbijartin û wekî rolek li girêkek din a DC-ya din were veguheztin.
- Mamoste dê zû hemî girêkên negihîştî ji komê derxîne.
- Li ser bingeha yên mayî, ew ê fêm bike: di navenda daneya windabûyî de me şaxên seretayî yên weha û weha hebûn, ew ê zû di navendên daneyê yên mayî de şûşeyên kopîkî yên temamker pêşve bibe, û em ê navnîşkirina daneyan bidomînin.
- Wekî encamek vê yekê, nivîsandin û xwendina komê dê hêdî hêdî kêm bibe, lê bi gelemperî her tişt dê bixebite, her çend hêdî, lê bi îstîqrar.
Wekî ku derket holê, me tiştek weha dixwest:
Û me ev tişt girt:
Ev çawa çêbû?
Dema ku navenda daneyê ket, axayê me bû kelek.
Çima
Rastî ev e ku master xwedan TaskBatcher e, ku berpirsiyarê belavkirina hin kar û bûyeran di komê de ye. Her derketina girêkek, her danasîna perçeyek ji kopiyek berbi seretayî, her peywirek ku meriv li cîhek perçeyek biafirîne - ev hemî pêşî diçe TaskBatcher, li wir ew bi rêz û di yek tîrêkê de tê hilanîn.
Di dema vekişîna yek navendek daneyê de, derket holê ku hemî girêkên daneyê yên li navendên daneyê yên sax ji erka xwe dihesibînin ku axayê xwe agahdar bikin "me filan şikestî û girêkên daneyan wusa û wusa winda kirine."
Di heman demê de, girêkên daneya saxlem ev hemî agahdarî ji masterê heyî re şandin û hewl dan ku li benda pejirandinê bin ku wî ew qebûl kiriye. Ew li benda vê yekê neman, ji ber ku axayan ji wî zûtir peywiran distînin. Girêkan daxwaza dubarekirina wextê qedandin, û master di vê demê de tewra jî hewl neda ku bersiva wan bide, lê bi tevahî di peywira rêzkirina daxwazan de li gorî pêşîniyê mijûl bû.
Di forma termînalê de, derket holê ku girêkên daneyê ji masterê re spam kirin heya ku ew çû nav GC-ya tevahî. Piştî wê, rola serdestê me derbasî hin girêka din bû, bê guman heman tişt hat serê wê, û di encamê de kom bi tevahî hilweşiya.
Me pîvandin girt, û berî guhertoya 6.4.0, ku ev yek hate rast kirin, ji me re bes bû ku em di heman demê de tenê 10 girêkên daneyê ji 360 derxînin da ku komê bi tevahî qut bikin.
Tiştek weha xuya bû:
Piştî guhertoya 6.4.0, ku ev xeletiya tirsnak hate rast kirin, girêkên daneyê kuştina master rawestand. Lê vê yekê ew "aqilmend" nekir. Ango: dema ku em 2, 3 an 10 (ji bilî yek jimarek din) girêkên daneyê derdixin, master peyamek yekem werdigire ku dibêje girê A derketiye, û hewl dide ku ji girê B, girê C, li ser vê yekê bêje, girê D.
Û di vê gavê de, ev tenê dikare bi danîna demek ji bo hewildanên ku ji kesek re li ser tiştekê re bêje, bi qasî 20-30 saniyeyan, û bi vî rengî kontrolkirina leza navenda daneyê ya ku ji komê diçe kontrol bike.
Di prensîbê de, ev di nav hewcedariyên ku di destpêkê de wekî beşek projeyê ji hilbera paşîn re hatî pêşkêş kirin re têkildar e, lê ji hêla "zanistiya paqij" ve ev xeletiyek e. Ya ku, bi awayê, ji hêla pêşdebiran ve di guhertoya 7.2 de bi serfirazî hate rast kirin.
Wekî din, dema ku girêkek daneyê derket, derket holê ku belavkirina agahdariya der barê derketina wê de girîngtir e ji ku ji tevahiya komê re bêje ku li ser wê şikestinên seretayî yên weha û weha hene (ji bo ku di daneyek din de kopiyek-şardek pêşve bibe. navend di seretayî de, û di agahdarî de dikare li ser wan were nivîsandin).
Ji ber vê yekê, gava ku her tişt jixwe vemirî, girêkên daneya berdan tavilê wekî kevin nayên nîşankirin. Li gorî vê yekê, em neçar in ku li bendê bin heya ku hemî ping ji girêkên daneya berdanê re derbas bibin, û tenê piştî wê koma me dest pê dike ku ji me re bêje ku li wir, li wir û li wir hewce ye ku em agahdariya tomarkirinê bidomînin. Hûn dikarin li ser vê yekê bêtir bixwînin .
Wekî encamek, operasyona vekişîna navendek daneyê îro di demjimêra bilez de 5 hûrdeman digire. Ji bo kolosek wusa mezin û bêkêmasî, ev encamek pir baş e.
Di encamê de em gihîştin vê biryara jêrîn:
- 360 girêkên me yên daneyê bi dîskên 700 gigabyte hene.
- 60 koordînator ji bo rêvekirina seyrûseferê bi van heman girêkên daneyê.
- 40 axayên ku me ji guhertoyên berî 6.4.0-ê ve wekî celebek mîras hiştiye - ji bo ku em ji vekişîna navenda daneyê sax bimînin, em ji hêla derûnî ve amade bûn ku em çend makîneyan winda bikin da ku em garantî bikin ku di heman demê de xwedî qasek axayan bin. senaryoya herî xirab
- Her hewildanên berhevkirina rolan li ser yek konteynerê bi vê yekê rast hat ku zû an dereng girêk dê di bin barkirinê de biqelişe.
- Tevahiya komê mezinahiyek 31 gîgabaytan bikar tîne: hemî hewildanên kêmkirina mezinahiyê di encamê de an bi kuştina hin girêkan li ser pirsên lêgerîna giran bi tîpa çolê ya pêşeng an jî di Elasticsearch-ê bixwe de vekêşana dorpêçê bi dest xistin.
- Wekî din, ji bo misogerkirina performansa lêgerînê, me hewl da ku hejmara tiştên di komê de bi qasî ku pêkan hindik be, bihêle, ji bo ku bi qasî ku pêkan bûyeran di şûşeya ku me di masterê de girtiye de pêvajoyê bikin.
Di dawiyê de li ser çavdêriyê
Ji bo ku bicîh bikin ku ev hemî wekî ku tê armanc kirin, em çavdêriya jêrîn dikin:
- Her girêka daneyê ji ewra me re radigihîne ku ew heye, û li ser wê şikestinên weha û weha hene. Dema ku em li cîhek tiştek vemirînin, kom piştî 2-3 çirkeyan radigihîne ku li navenda A me girêkên 2, 3, û 4 vemirandin - ev tê vê wateyê ku li navendên daneya din em di bin ti şert û mercan de nikanin wan girêkên ku li ser wan tenê yek perçek heye vemirînin. çep.
- Dizanin cewherê tevgerê masterê, em pir bi baldarî li hejmara karên li bendê dinêrin. Ji ber ku tewra yek peywirek asêbûyî jî, heke ew di wextê xwe de neqede, ji hêla teorîkî ve di hin rewşa awarte de dikare bibe sedem ku, mînakî, pêşvebirina perçeyek kopiyek di seretayî de nexebite, ji ber vê yekê îndekskirin dê bixebite.
- Em di heman demê de ji nêz ve li derengiyên berhevkarê çopê dinêrin, ji ber ku me di dema xweşbîniyê de jixwe zehmetiyên mezin bi vê yekê re hebûn.
- Ji hêla têlan ve red dike da ku pêşî li ku derê şûşê fêm bike.
- Welê, metrîkên standard ên wekî heap, RAM û I/O.
Dema ku çavdêriya avakirinê, divê hûn taybetmendiyên Thread Pool di Elasticsearch de bigirin. vebijarkên veavakirinê û nirxên xwerû yên ji bo lêgerîn û îndekskirinê vedibêje, lê di derbarê thread_pool.management de bi tevahî bêdeng e. Van mijaran pêvajoyê dikin, bi taybetî, pirsên wekî _cat/shards û yên din ên mîna wan, ku karanîna wan di dema nivîsandina çavdêriyê de hêsan e. Komek her ku mezintir be, ew qas daxwazên weha di yekîneya demê de têne bicîh kirin, û thread_pool.managementa navborî ne tenê di belgeya fermî de nayê pêşkêş kirin, lê di heman demê de ji hêla xwerû ve bi 5 mijaran ve jî tê sînordar kirin, ku pir zû têne avêtin, piştî kîjan çavdêrî bi awayekî rast dixebite.
Tiştê ku ez dixwazim di encamê de bêjim: me ew kir! Me karîbû amûrek bernamesaz û pêşdebirên xwe bidin ku, hema hema di her rewşê de, dikare bi lez û bez agahdarî li ser tiştê ku di hilberînê de diqewime peyda bike.
Erê, derket holê ku ew pir tevlihev e, lê, dîsa jî, me karî xwestekên xwe di nav hilberên heyî de bi cih bikin, yên ku me neçar ma ku ji xwe re xêz bikin û ji nû ve binivîsin.
Source: www.habr.com