Heus Habr! Nomen meum est Maxim Vasiliev, analysta laboro et procurator apud FINCH. Hodie tibi dicere volumus quomodo, usura ElasticSearch, XV decies petitiones in VI minutis procedere potuimus et onera cotidiana in situ unius clientium nostrorum optimizare potuimus. Infeliciter, sine nominibus debebimus facere, cum NDA habemus, speramus nos ab hoc contentum articuli non laborare. Abeamus.
Quam project operatur
In nostro backendentes operas creamus quae efficiendum curent nostri websites huius loci et applicationes mobiles. Communis structura in schemate videri potest:
In processu operis magnum numerum negotiorum egimus: emptiones, praestationes, operationes cum statera usoris, quibus multa ligna condimus, necnon haec notitia ad systemata externa importat et exportant.
Processus etiam contrarii sunt cum notitias ex cliente accipimus et eam in utentem transfermus. Praeterea processus adhuc sunt ad operandum cum solutionibus et programmatibus bonus.
Brevis background
Initio nos PostgreSQL usi sumus ut solum data copia. Commoda eius vexillum pro DBMS: praesentia rerum gerendarum, notae excultae linguae sampling, amplis instrumentorum ad integrationem; satis diu iunctis bonis nostris necessitatibus satisfecerimus.
Omnino notitias in Postgres: ab transactionibus ad nuntium reposuimus. Sed numerus utentium crevit, et cum eo numerus petitionum.
Ad intelligendum, annuus numerus sessionum in 2017 tantum in escritorio situs 131 decies centena millia, in 2018 - 125 decies centena, 2019 iterum 130 decies centena millia. Adde aliam 100-200 decies centena millia ex versione mobili situs et applicationis mobilis, et tu erit numerus petitionum ingens.
Cum incremento propositi, Postgres cum onere parietum obstitissemus, tempus non erat - numerus variarum quaesitionum apparuit, quarum copiam copiam indices creare non potuimus.
Intelleximus aliud opus esse notitiarum thesaurorum quae nostris necessitatibus praeberent et onus PostgreSQL auferendum. Investigatio elastica et MongoDB optiones quam maxime habitae sunt. Posterior perditur in sequentibus punctis;
- Tarda celeritas indexing sicut copia notitiarum in indicibus crescit. Cum Elastica, celeritas non pendet a copia notitiarum.
- Nihil plenum textum quaerere
Ita nobis elasticam elegimus et ad transitum praeparavimus.
Transitus ad Elasticam
1. Transitum e puncto venditionis inquisitionis incepimus. Cliens noster summam circiter 70 puncta venditionis habet, et hoc requirit varias inquisitionum genera in situ et in applicatione:
- Textus quaerere ab urbe nomen
- Geosearch intra datam radium ab aliqua parte. Exempli causa, si usor videre velit quae venditionis puncta ad domum eius proxima sunt.
- Quaere quadrato dato usore quadratum in tabula trahit et omnia puncta in hoc radio ei ostenduntur.
- Quaerere per filtras adiectis. Puncta venditionis inter se certae differunt
Si de ordinatione loquimur, tunc in Postgres habemus fontem data pro charta et nuntio, et in elasticis Snapshots ex notitia originali sumuntur. Re vera initio Postgres investigationem per omnia criteria obire non poterant. Non solum multi indices erant, etiam aliudque erant, sic Postgres schedulae perierunt nec intellexerunt quibus index uteretur.
2. Proxima in acie erat pars nuntiorum. Publicationes in situ cotidie apparent ut usor in profluvio informationis non deperit, notitia ante exitum sorted debet. Hoc est quod quaerendum est: locum quaerere potes per copulam textuum et simul filtras adnectere, cum etiam per Elasticam factae sint.
3. Deinde rem gestam movemus processus. Users productum quoddam in situ emere possunt et praemium trahere participare. Post has emptiones magnam copiam notitiarum, praesertim in weekends et festis, processimus. Ad comparationem, si in vulgaribus diebus numerus emptionum alicubi est inter 1,5-2 miliones, tunc diebus festis figura 53 decies centena millia attingere potest.
Eodem tempore, notitia quam brevissimo tempore discursum est - utentes non placet eventum aliquot dies expectare. Nullo modo est talis fatalia per Postgres - seras saepe suscepimus et dum omnes petitiones dispensabamus, usores inhibere non poterant utrum praemia accepissent necne. Id negotii non admodum iucundum est, itaque processus ad Elasticationem movemur.
periodicae
Nunc updates configurantur eventus-substructio secundum has condiciones:
- Venditio demonstrat. Quamprimum notitias ab extrinseco accipimus, statim renovationem incipimus.
- Nuntium. Quamprimum quodlibet nuntium ex situ editum est, automatice ad Elasticam mittitur.
Hic porro commoda Elastica memorare digna est. In Postgres, cum mitto petitionem tuam, exspectandum est, donec omnia monumenta honeste procedamus. 10 monumenta mittere potes ad Elasticam et statim operari incipies, sine exspectatione monumentorum per omnia Shards distribuenda. Scilicet, aliqua Shard vel Replica notitia statim non videre potest, sed omnia brevi tempore praesto erunt.
Integration modi
Sunt 2 modi cum Elastica integrandi:
- Per patriam clientem TCP. Auriga vernacula paulatim exstinguitur: iam non sustinetur, syntaxin valde incommodum habet. Ideo fere non utimur et eam penitus omittere conamur.
- Per interfaciem HTTP quae tum JSON petitionibus uti potest et syntaxi Lucene. Ultima est machinae textus qui elasticis utitur. In hac versione facultatem per JSON petitiones HTTP Batch obtinemus. Hoc est bene uti conamur.
Gratias HTTP interface, bibliothecis uti possumus, qui asynchronam exsecutionem clientis HTTP praebent. Utilitatem possumus Batch et API asynchronum, quod consequitur altam observantiam, quae multum adiuvit in diebus magni promotionis (more infra)
Numeri aliquot ad comparationem;
- Salvis Postgres largitas users in 20 stamina sine copula: 460713 records in 42 seconds
- Elastica + client reactiva pro 10 stamina + batch pro 1000 elementis: 596749 records in 11 seconds
- Elastica + client reactiva pro 10 stamina + batch pro 1000 elementis: 23801684 entries in 4 minuta
Nunc procurator petitionem HTTP scripsimus qui JSON ut Batch/non Batch aedificat et per aliquem clientem HTTP mittit, cuiuscumque bibliothecae. Petitiones synchrone vel asynchronously mittere potes etiam eligere.
In nonnullis integrationibus, adhuc clientelam onerariam officialem utimur, sed hoc in negotio sequentis refactoring est. In hoc casu, consuetudo clientis aedificata in fundamento ver WebClient adhibetur ad expediendas.
magnus promotionem
Semel in anno, exertus exercituum magna promotio utentium - hoc idem est Highload, quia in hoc tempore cum decem decies centena milia usorum simul laboramus.
Plerumque cacumina onerum diebus festis occurrunt, sed haec promotio in gradu prorsus dissimili est. Anno proximo, die promotionis, unitates bonorum 27 vendidimus. Data est processus plus quam dimidium horae, quod incommodum usorum causavit. Praemia pro participatione acceperunt Users, sed patuit processum opus esse accelerandum.
Ineunte MMXIX, placuit nobis opus ElasticSearch. Annum integrum constituimus processus notitiarum receptarum in Elastica et earum editae in api applicationis mobilis et in situ. Quam ob rem annus secundus in expeditione processimus 15 introitus in 131 minuta.
Cum nos multos homines, qui bona emere cupiunt et praemiorum promotionum participent participes, haec mensura temporalis est. Nunc notitias elasticas ut-colatas mittimus, in futuro autem cogitamus informationes scrinium transferre praeteritorum mensium ad Postgres tamquam tabularium permanentem. Ut index elasticus non intercludat, qui etiam limitationes habet.
Conclusio / conclusiones
In momento omnia servitia quae Elastica voluimus transtulimus et in hoc pro nunc destitimus. Nunc indicem in Elastica aedificamus in summa repositionis pertinaciae in Postgres, quae usoris onus occupat.
In posterum operas transferre cogitamus si intelligamus petitionem notitiae nimis variam fieri et infinitis columnis inquirere. Hoc opus non est pro Postgres.
Si plene textu quaerendo in functionitate indigemus aut si multa alia criteria quaestionis habemus, iam novimus haec necessitates in Elasticam transferenda esse.
βββ
Gratias legendi. Si societas tua ElasticSearch etiam utitur et suas causas exsecutionis habet, dic nobis. Erit interesting scire quomodo alii sunt
Source: www.habr.com