Hei Habr! Fy enw i yw Maxim Vasiliev, rwy'n gweithio fel dadansoddwr a rheolwr prosiect yn FINCH. Heddiw, hoffwn ddweud wrthych sut, gan ddefnyddio ElasticSearch, roeddem yn gallu prosesu 15 miliwn o geisiadau mewn 6 munud a gwneud y gorau o'r llwythi dyddiol ar wefan un o'n cleientiaid. Yn anffodus, bydd yn rhaid i ni wneud heb enwau, gan fod gennym NDA, rydym yn gobeithio na fydd cynnwys yr erthygl yn dioddef o hyn. Awn ni.
Sut mae'r prosiect yn gweithio
Ar ein backend, rydym yn creu gwasanaethau sy'n sicrhau perfformiad gwefannau a chymhwysiad symudol ein cleient. Mae'r strwythur cyffredinol i'w weld yn y diagram:
Yn y broses o weithio, rydym yn prosesu nifer fawr o drafodion: pryniannau, taliadau, gweithrediadau gyda balansau defnyddwyr, yr ydym yn storio llawer o logiau ar eu cyfer, yn ogystal Γ’ mewnforio ac allforio data hwn i systemau allanol.
Mae prosesau gwrthdroi hefyd pan fyddwn yn derbyn data gan y cleient ac yn ei drosglwyddo i'r defnyddiwr. Yn ogystal, mae prosesau o hyd ar gyfer gweithio gyda thaliadau a rhaglenni bonws.
Cefndir cryno
I ddechrau, gwnaethom ddefnyddio PostgreSQL fel yr unig storfa ddata. Ei fanteision safonol ar gyfer DBMS: presenoldeb trafodion, iaith samplu data ddatblygedig, ystod eang o offer ar gyfer integreiddio; ynghyd Γ’ pherfformiad da yn bodloni ein hanghenion am amser eithaf hir.
Fe wnaethom storio'r holl ddata yn Postgres: o drafodion i newyddion. Ond tyfodd nifer y defnyddwyr, a chyda hynny nifer y ceisiadau.
Er mwyn deall, mae nifer blynyddol y sesiynau yn 2017 yn unig ar y safle bwrdd gwaith yn 131 miliwn. Yn 2018 - 125 miliwn. 2019 eto 130 miliwn. Ychwanegwch 100-200 miliwn arall o fersiwn symudol y wefan a'r cymhwysiad symudol, a chi yn cael nifer fawr o geisiadau.
Gyda thwf y prosiect, rhoddodd Postgres y gorau i ymdopi Γ’'r llwyth, nid oedd gennym amser - ymddangosodd nifer fawr o wahanol ymholiadau, ac ni allem greu nifer ddigonol o fynegeion ar eu cyfer.
Roeddem yn deall bod angen storfeydd data eraill a fyddai'n darparu ein hanghenion ac yn cymryd y llwyth oddi ar PostgreSQL. Ystyriwyd Elasticsearch a MongoDB fel opsiynau posibl. Collodd yr olaf ar y pwyntiau canlynol:
- Cyflymder mynegeio araf wrth i faint o ddata mewn mynegeion dyfu. Gyda Elastig, nid yw'r cyflymder yn dibynnu ar faint o ddata.
- Dim chwiliad testun llawn
Felly fe ddewison ni Elastig i ni ein hunain a pharatoi ar gyfer y trawsnewid.
Pontio i Elastig
1. Dechreuon ni'r cyfnod pontio o'r gwasanaeth chwilio pwynt gwerthu. Mae gan ein cleient gyfanswm o tua 70 o bwyntiau gwerthu, ac mae hyn yn gofyn am sawl math o chwiliadau ar y wefan ac yn y cais:
- Chwiliad testun yn Γ΄l enw dinas
- Geosearch o fewn radiws penodol o ryw bwynt. Er enghraifft, os yw'r defnyddiwr eisiau gweld pa fannau gwerthu sydd agosaf at ei gartref.
- Chwiliwch yn Γ΄l sgwΓ’r penodol - mae'r defnyddiwr yn tynnu sgwΓ’r ar y map, a dangosir pob pwynt yn y radiws hwn iddo.
- Chwilio yn Γ΄l hidlwyr ychwanegol. Mae pwyntiau gwerthu yn wahanol i'w gilydd o ran amrywiaeth
Os byddwn yn siarad am y sefydliad, yna yn Postgres mae gennym ffynhonnell ddata ar gyfer y map a'r newyddion, ac yn Elastig mae Cipluniau'n cael eu cymryd o'r data gwreiddiol. Y ffaith yw na allai Postgres ymdopi Γ’'r chwiliad yn Γ΄l pob maen prawf i ddechrau. Nid yn unig yr oedd yna lawer o fynegeion, gallent hefyd orgyffwrdd, felly aeth amserlennydd Postgres ar goll ac nid oedd yn deall pa fynegai i'w ddefnyddio.
2. Y nesaf yn y llinell oedd yr adran newyddion. Mae cyhoeddiadau'n ymddangos ar y wefan bob dydd fel nad yw'r defnyddiwr yn mynd ar goll yn y llif gwybodaeth, rhaid didoli'r data cyn ei gyhoeddi. Dyma beth mae chwilio: gallwch chwilio'r wefan yn Γ΄l cyfatebiad testun, ac ar yr un pryd cysylltu hidlwyr ychwanegol, gan eu bod hefyd yn cael eu gwneud trwy Elastic.
3. Yna rydym yn symud y prosesu trafodiad. Gall defnyddwyr brynu cynnyrch penodol ar y wefan a chymryd rhan mewn raffl fawr. Ar Γ΄l pryniannau o'r fath, rydym yn prosesu llawer iawn o ddata, yn enwedig ar benwythnosau a gwyliau. Er mwyn cymharu, os yw nifer y pryniannau rhywle rhwng 1,5-2 miliwn ar ddiwrnodau cyffredin, yna ar wyliau gall y ffigur gyrraedd 53 miliwn.
Ar yr un pryd, rhaid prosesu'r data yn yr amser byrraf posibl - nid yw defnyddwyr yn hoffi aros am y canlyniad am sawl diwrnod. Nid oes unrhyw ffordd i gyrraedd terfynau amser o'r fath trwy Postgres - yn aml iawn, roedden ni'n derbyn cloeon, a thra roeddem yn prosesu pob cais, ni allai defnyddwyr wirio a oeddent yn derbyn gwobrau ai peidio. Nid yw hyn yn ddymunol iawn i fusnes, felly symudwyd y prosesu i Elasticsearch.
Cyfnodoldeb
Nawr mae diweddariadau wedi'u ffurfweddu yn seiliedig ar ddigwyddiadau, yn unol Γ’'r amodau canlynol:
- Pwyntiau gwerthu. Cyn gynted ag y byddwn yn derbyn data o ffynhonnell allanol, rydym yn cychwyn y diweddariad ar unwaith.
- Newyddion. Cyn gynted ag y caiff unrhyw newyddion ei olygu ar y wefan, caiff ei anfon yn awtomatig i Elastic.
Yma eto mae'n werth sΓ΄n am fanteision Elastig. Yn Postgres, wrth anfon cais, mae'n rhaid i chi aros nes ei fod yn prosesu'r holl gofnodion yn onest. Gallwch anfon 10 o gofnodion i Elastic a dechrau gweithio ar unwaith, heb aros i'r cofnodion gael eu dosbarthu ar draws yr holl Shards. Wrth gwrs, efallai na fydd rhai Shard neu Replica yn gweld y data ar unwaith, ond bydd popeth ar gael yn fuan iawn.
Dulliau integreiddio
Mae dwy ffordd o integreiddio ag Elastig:
- Trwy cleient brodorol dros TCP. Mae'r gyrrwr brodorol yn marw'n raddol: nid yw'n cael ei gefnogi mwyach, mae ganddo gystrawen anghyfleus iawn. Felly, yn ymarferol nid ydym yn ei ddefnyddio ac yn ceisio ei gefnu'n llwyr.
- Trwy ryngwyneb HTTP a all ddefnyddio ceisiadau JSON a chystrawen Lucene. Mae'r un olaf yn beiriant testun sy'n defnyddio Elastig. Yn y fersiwn hon, rydyn ni'n cael y gallu i Swpio trwy geisiadau JSON dros HTTP. Dyma'r opsiwn yr ydym yn ceisio ei ddefnyddio.
Diolch i'r rhyngwyneb HTTP, gallwn ddefnyddio llyfrgelloedd sy'n darparu gweithrediad asyncronaidd o'r cleient HTTP. Gallwn fanteisio ar Swp a'r API asyncronig, sy'n arwain at berfformiad uchel, a helpodd lawer yn nyddiau'r hyrwyddiad mawr (mwy ar hynny isod)
Rhai rhifau i'w cymharu:
- Arbed defnyddwyr bounty Postgres mewn 20 edefyn heb eu grwpio: 460713 o gofnodion mewn 42 eiliad
- Cleient elastig + adweithiol ar gyfer 10 edefyn + swp ar gyfer 1000 o elfennau: 596749 o gofnodion mewn 11 eiliad
- Cleient elastig + adweithiol ar gyfer 10 edafedd + swp ar gyfer 1000 o elfennau: 23801684 o gofnodion mewn 4 munud
Nawr rydym wedi ysgrifennu rheolwr cais HTTP sy'n adeiladu JSON fel Swp / nid Swp ac yn ei anfon trwy unrhyw gleient HTTP, waeth beth fo'r llyfrgell. Gallwch hefyd ddewis anfon ceisiadau yn gydamserol neu'n anghydamserol.
Mewn rhai integreiddiadau, rydym yn dal i ddefnyddio'r cleient trafnidiaeth swyddogol, ond dim ond mater o'r ailffactorio nesaf yw hyn. Yn yr achos hwn, defnyddir cleient arfer a adeiladwyd ar sail Spring WebClient ar gyfer prosesu.
dyrchafiad mawr
Unwaith y flwyddyn, mae'r prosiect yn cynnal hyrwyddiad mawr i ddefnyddwyr - dyma'r un Highload, oherwydd ar hyn o bryd rydym yn gweithio gyda degau o filiynau o ddefnyddwyr ar yr un pryd.
Fel arfer mae llawer o lwythi yn digwydd yn ystod y gwyliau, ond mae'r dyrchafiad hwn ar lefel hollol wahanol. Y flwyddyn cyn diweddaf, ar ddiwrnod y dyrchafiad, gwerthasom 27 o unedau o nwyddau. Proseswyd y data am fwy na hanner awr, a achosodd anghyfleustra i ddefnyddwyr. Derbyniodd defnyddwyr wobrau am gyfranogiad, ond daeth yn amlwg bod angen cyflymu'r broses.
Ar ddechrau 2019, fe benderfynon ni fod angen ElasticSearch. Am flwyddyn gyfan, fe wnaethom drefnu prosesu'r data a dderbyniwyd yn Elastic a'u cyhoeddi yn api y cymhwysiad symudol a'r wefan. O ganlyniad, y flwyddyn nesaf yn ystod yr ymgyrch, rydym yn prosesu 15 o geisiadau mewn 131 munud.
Gan fod gennym lawer o bobl sydd eisiau prynu nwyddau a chymryd rhan mewn tynnu gwobrau mewn hyrwyddiadau, mesur dros dro yw hwn. Nawr rydym yn anfon y wybodaeth ddiweddaraf i Elastic, ond yn y dyfodol rydym yn bwriadu trosglwyddo gwybodaeth wedi'i harchifo ar gyfer y misoedd diwethaf i Postgres fel storfa barhaol. Er mwyn peidio Γ’ chlocsio'r mynegai Elastig, sydd Γ’'i gyfyngiadau hefyd.
Casgliad/Casgliadau
Ar hyn o bryd, rydym wedi trosglwyddoβr holl wasanaethau yr oeddem eu heisiau i Elastig ac wedi oedi ar hyn am y tro. Nawr rydym yn adeiladu mynegai yn Elastig ar ben y prif storfa barhaus yn Postgres, sy'n cymryd drosodd y llwyth defnyddiwr.
Yn y dyfodol, rydym yn bwriadu trosglwyddo gwasanaethau os ydym yn deall bod y cais am ddata yn mynd yn rhy amrywiol ac yn cael ei chwilio am nifer anghyfyngedig o golofnau. Nid tasg i Postgres mo hon bellach.
Os oes angen chwiliad testun llawn arnom o ran ymarferoldeb neu os oes gennym lawer o feini prawf chwilio gwahanol, yna rydym eisoes yn gwybod bod angen cyfieithu hwn i Elastig.
βββ
Diolch am ddarllen. Os yw'ch cwmni hefyd yn defnyddio ElasticSearch a bod ganddo ei achosion gweithredu ei hun, yna dywedwch wrthym. Bydd yn ddiddorol gwybod sut mae eraill π
Ffynhonnell: hab.com