In sermone suo, Andrey Borodin narrabit tibi quomodo rationem acceperunt experientiam PgBouncer scalae, cum nexum designans connexionem maiorem. quomodo se evolvit in productione. Insuper disseremus quae functiones urgentium in novis versionibus videre velimus: interest nobis non solum necessitates nostras obtegere, sed communitatem usoris evolvere. .
videos:
Hi omnes! Andreas nomen mihi est.
Apud Yandex, fontem apertum databases explicamus. Thema et hodie habemus de nexu nexuum nexuum.
Si scias quomodo nexum vocamus apud Russicos, dic mihi. Vere volo invenire terminum technicum bonum, quod institui debet in litteris technicis.
Locus est admodum perplexus, quia in multis databases nexus principalior aedificatur, et ne scire quidem debes. Quaedam loca, utique, ubique sunt, sed in Postgres hoc non operatur. Et in parallelis (ad HighLoad ++ 2019) exstat relatio a Nikolai Samokhvalov de quaestionibus in Postgres statuendis. Et intellego homines huc venisse qui petitiones perfecte iam configurantur, et hi sunt qui versantur in difficultatibus systematis rarioris ad reticulum retis, utendo resource utendo. Et in nonnullis locis satis difficilis potest esse in sensu problemata non perspicua.
Yandex habet Postgres. Multa Yandex officia in Yandex.Cloud vivunt. Et habemus plura petabyta notitiarum quae saltem decies centena millia petitionum generantium in Postgres secundo.
Et praebemus botrum satis typicum pro omnibus officiis - hoc est principale primarium nodi nodi, consuetum in duabus replicationibus (synchronis et asynchronis), tergum, scandendo petitiones legendi in replica.
Quisque nodi botrus Postgres est, in quo, praeter Postgres et systemata vigilantia, nexus maior etiam inauguratus est. Connexio lacusor adhibetur ad claudendum et ad principale propositum.
Quod est principale propositum nexum pooler?
Postgres exemplar processum adhibet ad operandum cum database. Hoc significat unum nexum unum processum, unum Postgres backend. Et multae diversae tabulae in hoc backend sunt, quae satis pretiosae sunt ut diversos diversos nexus reddant.
Item, est ordo in codice Postgres vocato procArray. Continet notitias fundamentales circa retis nexus. Et fere omnes procArray processus algorithmorum complexionem linearem habent, per totam retis nexum discurrunt. Pulchellus est cyclus celeriter, sed cum retis nexus advenientis, res plusculum habent carius. Et cum res aliquantulum pretiosius possideas, tandem maximo pretio solvendo pro magno numero retis nexus.
Sunt aditus III possibiles:
- De applicatione lateris.
- In datorum parte.
- Et inter, id est, omnes combinationes possibilium.
Donec in lacus sit amet elit. Amici in PostgreSQL Professional hoc plerumque faciunt. Cum praedicere difficile apparebit. Et quidem, architecto optio nobis est soluta. Hae sunt applicatio lateris piscinae et lacus procurator.
Ad latus stagnum applicationis facillimum est. Et fere omnes rectores clientes praebent tibi viam: decies centena milia nexuum tuorum in codice repraesentare sicut aliquos justos e nexus datorum.
Difficultas est cum quodam puncto quod vis retro scandere, vis eam multis machinis virtualibus explicari.
Tunc adhuc animadverto vos habere plures regiones promptiores, plures centra data. Et cliens latus collatis accessus ad magnos numeros ducit. Magnae circiter 10 hospites sunt. Hoc est ora quod bene potest operari.
Si de procuratorio loquimur, duo sunt qui multum possunt facere. Nulla non lacus nisi. Pleniores sunt + magis refrigerandi functionality. Hoc ΠΈ .
Quisque eget dolor eget nibh consequat suscipit id sed neque. Et ducit ad hoc quod poolers tantum sessionem collatis subsidiis sustinet, i.e. unum clientem ineuntes, unum clientem exitu datorum.
Hoc non est valde idoneum ad opera nostra, sic utimur PgBouncer, qui instrumenti transactionis collativae, i.e., hospites provisi sunt ad clientelas hospites tantum pro duratione transactionis.
Et in onere nostro - verum est. Sed plures quaestiones sunt.
Problemata incipiunt cum sessionem egritudo vis, quia omnes nexus advenientes locales sunt. Omnes venerunt cum loopback et aliquo modo difficile fit sessionem investigare.
Utique application_name_add_hostium uti potes. Haec est Bouncer via ad partem IP inscriptionis accessionis ad applicationem_name. Sed application_nomen addito nexu constituitur.
In hac chartula, ubi linea fulva postulationes verae sunt, et ubi linea caerulea petita sunt, in datorum volitant. Quae differentia est prorsus appellatio nominis applicationis, quod tantum opus est ad typum, sed omnino liberum non est.
Praeterea Bouncer unam piscinam circumscribere non potest, i.e. numerum nexuum datorum per user, per database.
Quid hoc ducunt? Servitium onustum habes in C ++ et alicubi prope parvam servitutem in nodo quae nihil mali facit cum turpi, sed insanus exactor eius. Aperit ad viginti milia nexus et reliqua omnia exspectabunt. Etiam codicem tuum verum est.
Sane parvam commissuram scripsimus pro Bouncer qui hunc occasum, i.e., limitando clientes ad piscinam addidit.
Posset hoc facere in Postgres parte, i.e. coarctare muneribus in datorum numero nexuum.
Sed tunc facultatem perdis intellige cur hospites non habeas cum servo. PgBouncer errorem nexum non mittit, semper eadem notitia redit. Et non potes intellegere: tesserae tuae fortasse mutatae sunt, fortasse database descenderunt, fortasse aliquid falsum est. Sed non est diagnosis. Si sessio institui nequit, nescies cur fieri non possit.
Quodam loco, graphs applicationis spectas et vide applicationem non laborat.
Summam aspice et vide ut bouncer liciatus est. Haec meta est in vita servitutis. Intelligis te parare databases per annum et dimidium conscendere, et debes conscendere pleniorem.
Pervenimus ad conclusionem PgBouncers pluribus indigere.
Bouncer leviter perantiqua est.
Et fecerunt ut plures Bouncers cum reuse portus TCP elevari possint. Et iam ratio operativa automatice ineuntes TCP nexus inter eos per-robin'om transfert.
Hoc perspicuum est clientibus, i.e., spectat sicut unum habes Bouuncr, sed habes nexuum otiosorum rupturam inter currentes Bouuncres.
Et aliquando animadvertere licet hos 3 Bouncers unumquemque suum nucleum per C% edisse. Paucis Bouncers opus est. Quare?
Quia habes TLS. Encrypted nexum habes. Et si Probatio Postgres cum et sine TLS, numerum coniunctionum stabilitum per duos fere ordines magnitudinis cum encryptione factas invenies, quod manus TLS manus CPU consumit.
Et in summo, videre potes satis paucas functiones cryptographicas quae in fluctu advenientis nexus efficiuntur. Cum prima nostra potestas inter zonas disponibilitatem commutare potest, fluctus nexuum advenientium condicio satis typica est. Hoc est, ob aliquam causam, primarium antiquum pervulgatum fuit, totum onus alteri Mauris interdum immissum est. Salvere omnes simul TLS veniant.
Et magnus numerus TLS handshake non iam salutat Bouncer, sed iugulum premat. Fluctus advenientis hospites ex re timeout fieri potest illaesam. Si retry ad basim sine cedente exponentiali, iterum atque iterum in unda cohaerente non revertentur.
Exemplum hic est 16 PgBouncers qui onerant 16 coros ad 100%.
Pervenimus ad Cascading PgBouncer. Haec optima conformatio nos consequi possumus onus nostrum Bouncer. Externi nostri Bouncers pro handshake TCP inserviunt, et interni Bouuncers pro vera collatione inserviunt, ne nexus externas multum dilanient.
In hac configuratione, sileo mollis potest. Haec omnia 18 Bouncers singillatim sileo potes. Sed talis conformatio servans satis difficilis est. Administratores systematis DevOps et homines qui huic servo re vera responsabiles non erunt valde gauisi sunt hac ratione.
Videtur quod omnes emendationes nostrae in aperto fonte promoveri possint, at Bouncer non optime favet. Exempli gratia, facultas currere multiple PgBouncers in eodem portu ante mensem commissum est. Rogatio viverra cum hac factura paucis abhinc annis fuit.
Vel unum exemplum. In Postgres, petitionem currentem inrita potes mittendo secretum ad alium nexum sine authenticitate extra. Aliqui autem clientes simpliciter mittunt TCP-reset, i.e., nexum retis frangunt. Quid hoc faciet Bouncer? Non faciet. Perget exequi rogatu. Si ingentem numerum nexuum acceperis quae basim cum parvis petitionibus posuerunt, tunc simpliciter nexum disiungens a Bouncer non erit satis, adhuc opus est petitiones illas complere quae in datorum currunt.
Hoc disiunctum est et exitus adhuc in fluvium Bouncer non est immersus.
Itaque ad conclusionem devenimus necesse est nexum nostrum pleniorem, quae evolvetur, perantiqua, in qua cito problemata figere poterit et quae sane multi- lina esse debent.
Multithreading sumus ut praecipuum opus. Non opus est ut hospites bene TLS advenientis undam tractare possimus.
Ad hoc faciendum, bibliothecam separatam Machinarium nuncupatam evolvere debebamus, quae machinae nexus retis sicut codicem Vide designabat. Si codicem fontem libpq spectes, bella complexa videbis vocat quae exitum ad te referre possunt et dices: "Voca me paulo post. Nunc IO pro nunc habeo, sed cum IO transit, in processus sarcinam habeo. Et haec ratio multi-grada est. Commercium retis plerumque describitur per machinam publicam. Multum regulae sicut "Si prius fasciculum capitis magnitudinis N accepi, nunc N bytes exspecto", "Si fasciculum SYNC misi, tunc nunc exspecto fasciculum cum metadata proventu." Intuitive codice difficiliore evenit, quasi error in scan lineam conversus sit. Hoc fecimus ut loco machinae publicae, programmator principale iter commercium describit in forma imperativi ordinarii. In hoc codice imperativo, loca inserere debes, ubi consecutio exsecutionis interrumpi debet, exspectando a retis notitia, transeat contextum exsecutionis in aliud coroutinum (filum viride). Accessus hic similis est rei, quod in errore in ordine deprimimus exspectatissimam semitam, et deinde ad eam ramos adiciemus.
Quam ob rem unum filum habemus quod TCP accipimus et rotundum Robin transit TPC connexionem multis opificibus.
In hoc casu, uterque nexus clientium in uno processu semper incurrit. Idque tibi permittit ut hoc facias amice.
Insuper collectionem parvarum fasciculorum in unum magnum fasciculum leviter emendavimus ut systematis TCP acervum offload.
Praeterea emendationem transactionalem emendavimus in sensu, quod Odyssea figuratus possit mittere CANCELL et revolvi in ββcasu retis nexus defectus, i.e., si nemo petitionem expectat, Odyssea narrabit datorum non conari adimplere. petentibus ut opes pretiosas dissiparet.
Et si fieri potest, hospites eidem clienti tenemus. Hoc cavet, ut applicationem_name_add_host restituat. Si fieri potest, non habemus additam rete parametri, qui opus est ad diagnostica.
In rebus Yandex.Cloud laboramus. Et si postgreSQL administrato uteris et nexum pisciculorum inauguratum habes, replicationem logicam externam creare potes, i.e., nobis relinque si vis, per replicationem logicam. Bouncer extra fluxum replicationis logicae non dabit.
Hoc est exemplum replicationis logicae.
Praeterea habemus subsidium corporalis replicationis exterioris. In Cloud, utique impossibile est, quia tunc botrus dabit tibi nimium informationem de se. Sed in institutionibus tuis, si replicationem corporis indiges per nexum potiorem in Odyssea, fieri potest.
Odyssea cum PgBouncer vigilantia plene compatitur. Idem nos consolatur, qui omnia fere eadem mandata exequuntur. Si aliquid desit, petitionem trahendam, vel saltem fluxum in GitHub mittemus, mandata necessaria perficiemus. Sed iam habemus principalem functionem PgBouncer consolatorium.
Et error utique nobis procuret. Errorem a turpi relatum reddemus. Cognosces cur non in turpi, non quod non in eo.
Haec factura debilitata est in casu C% convenientiae cum PgBouncer debes. Bouncer agere possumus, in casu tantum.
consilio
Pauca verba de Odysseae codice fonte.
Verbi gratia, sunt mandata "Pause/Resume". Solent ad update database. Si opus est ut upgrade Postgres, illud in connexione fundatoris immorari potes, pg_upgrade fac, deinde resume. Et ex parte clientis, videbunt sicut retardationem datorum erat. Haec officiatio a communitate ad nos allata est. Nondum mortua est, sed mox erunt omnia. (iam mortuus est)
- iam mortui
Praeterea, unum e novis notis in PgBouncer est SCRAM Authenticationis subsidium, quod etiam nobis allatum est ab eo qui in Yandex.Cloud non operatur. Utrumque munus implicatum et magnum.
Quare velim tibi narrare quid sit de Odyssea, si tu quoque velis codicem aliquem nunc scribere.
Basis originalis Odysseae habes, quae duobus praecipue bibliothecis nititur. Bibliotheca Kiwi exsecutio nuntii protocolli Postgres est. Id est, Postgres's patria proto 3 est normae nuntii quae frontes et tergum commutare possunt. Eae in bibliotheca Kiwi complentur.
Machinarium bibliotheca est filum exsequendum bibliotheca. Parvum fragmentum Machinarium hujusce in assemblea scriptum est. Sed ne cures, tantum XV lineae sunt.
Architectura Homeri. Nulla consectetur cursus coroutines. Haec machina instrumenti accipiendi hospites TCP advenientes et inter operarios distribuendi.
Intra unum operarium, tracto plures clientes operari potest. Atque etiam in praecipuo sequela, consolatorium et processus munerum croetorum ad removendas nexus qui iam non opus sunt in piscina operantur.
Odyssea probatur uti signo postgres testarum. Modo per Bouncer install-reprehendimus et per Odysseam currimus, nullum divum obtinemus. Plures sunt probationes ad formaturam formatam pertinentium quae prorsus eadem deficiunt in Boumer et Odyssea.
Praeterea multi sunt rectores qui suum experimentum habent. Utimur autem illis probatis ad probandum Odysseam.
Etiam, ob nostram figuram cascading, varios fasciculos probare debemus: Postgres + Odyssey, PgBouncer + Odyssea, Odyssea + Odyssea, ut scias, si Odyssea est in quavis partium in cascade, ea etiam adhuc opera expectatur. .
pectis rastris,
Utimur Odyssea in productione. Et non esset aequum, si omnia iusta opera dicerem. Non, i.e., sed non semper. Exempli gratia, in productione omnia iusta operata, amici nostri a PostgreSQL Lorem venerunt et dixerunt nos memoriam habuisse Leak. Vere erant, constituimus eos. Sed simplex erat.
Inde invenimus nexum principaliorem habere nexus ineuntes TLS et nexus exitu TLS. Et hospites egent clientelam libellorum ac testium libellorum.
Bouncer et Odyssea ministrator libellorum a pcache releguntur, sed testimoniales clientes a pcache non egent, quia tandem Odyssea nostra scalable in ratio perficiendi legendi huius certificandi nititur. Hoc mirum nobis factum est, quia non statim quievimus. Primo linearly scandet, et post viginti millia nexus simultaneos ineuntes, quaestio haec manifestata est.
Ratio authenticitatis plugabilis est facultas authenticitatis instrumentorum in lunux constructo. In PgBouncer, ita effectum est ut filum separatum exspectet responsionem ex PAM et est principale filum PgBouncer qui nexui currenti inservit et petere potest ut in filo PAM vivant.
Hoc una simplici ratione non efficimus. Multos rivos habemus. Quid opus est?
Quam ob rem haec difficultates creare possunt in eo quod, si authenticas PAM habes et authenticas non-PAM, tunc magnus unda PAM authenticas non-PAM authenticas signanter morari potest. Hoc unum est eorum quae certum non habemus. Sed si vis reficere, potes hoc facere.
Alius sarculus erat cum eo quod unum habemus linum quod omnes hospites advenientes excipit. Deinde transferuntur ad piscinam opificis, ubi TLS handshake fient.
Quam ob rem, si undam cohaerentem 20 retis nexus habeas, omnes accepturi erunt. Et in hac parte, libpq incipiet renuntiationes timeouts. Defalta, similis 000 secundis ibi.
Si omnes basim simul ingredi non possunt, basim intrare non possunt, quia haec omnia per retry non exponentiali tegi possunt.
Nos finivimus schema PgBouncer describentes hic ut suffocare numerum TCP hospitum recipiamus.
Si videmus quod hospites accipimus, sed in fine handshake tempus non habent, ea in queue ponimus ut facultates CPU non consumant. Hoc eo ducit, ut manus simultanea non omnibus necessariis adiunctis peragi possit. Sed saltem aliquis datorum intrabit, etiam si satis validus est onus.
Roadmap
Quid vis videre in futuro in Odyssea? Quid parati sumus nosmetipsos evolvere et quid expectamus a communitate?
Ad Augustum MMXIX.
Hoc est quod Odyssea roadmap simile in Augusto videbatur:
- SCRAM et PAM authenticas voluimus.
- Volumus autera legere petitiones standby.
- Volo online-sileo.
- Et in servo morandi facultatem.
Dimidium huius roadmap fit, non a nobis. et hoc bonum est. Discutiamus igitur quid superest et plura addamus.
? Replicas habemus, quod sine petitionibus implendis aerem simpliciter calefacit. Eis opus est ut failover et switchovere provideant. In casu problematum in uno e centris notariorum, eas opere aliquo utili occupare velim. Quia non possumus eosdem processus centrales configurare, aliter eadem memoria, quia replicatio aliter non faciet.
Principio, in Postgres, ab 10 incipiendo, specificare sessiones_attrs coniungens potest. Potes enumerare omnes catervas datorum in nexu et dicere cur ad datorum properas: scribe vel lege tantum. Et ipse auriga primum exercitum in indice eliget quod maxime placet, quod exigentias session_attrs adimplet.
Sed difficultas huius accessionis est quod replicationem lag non refrenat. Habeas aliquam imaginem, quae post tempus ingratum est, pro servitio tuo. Ut exsecutionem plenam-featured petitionum legentium in effigiem efficiamus, re vera in Odyssea opus est facultatem non operari, cum legere non potest.
Odyssea habet ire ad datorum subinde et postulationem replicationis distantiae primariae. Et si ad terminum pervenerit, ne novas petitiones in datorum dimittat, clienti nuntia te necessitates hospites renovare et alium exercitum ad petitiones exsequi fortasse eligere. Hoc datorum permittit ut replicationem pigri cito restituat et iterum ad interrogationi respondeat.
Difficile est nomen exsecutionem gaudet, quia fons est aperta. Sed, spero, non 2,5 annis sicut collegae a PgBouncer. Hoc pluma in Odyssea videre vellem.
. Praeparatam propositionem facere potes duobus modis. Primum mandatum SQL exequi potes, nempe "paratum". Ad hoc mandatum SQL intelligendum, discendum est quomodo SQL in parte Bouncer intelligere. Hoc est overkill quod est overkill cum opus est tota parser. Non possumus omne mandatum parse SQL.
Est autem propositio praeparata ad nuntium protocollum in proto3 gradu. Hoc autem loco est, cum informatio praeparata enuntiatio creatur in structore forma. Et intellectui favere potuimus quod clientem in aliquo servo nexu rogaverunt ut propositiones paratas crearent. Etiam si res clausa est, nos tamen servo et clienti coniunctam servare debemus.
Sed hic discrepantia in dialogo est, quod aliquis dicat te intelligere debes quae paratae locutiones clientem creatum et servo nexum inter omnes clientes communicantes, qui hunc nexum servo creavit, i.e., qui talem praeparatam constitutionem creavit.
Andres Freund dixit, si clientis ad te venit, qui talem propositionem praeparatam in alio servo iunctio iam creaverat, eum creare. Sed parum videtur esse iniquum quaerentes in loco clientis datorum exsequi, sed ex parte viae, qui protocollum scribit ad commercium datorum, opportunum esset si simpliciter nexus retis daretur. quae tam parata petitio.
Et unum plura, quae ad efficiendum opus est. Nunc nos cum PgBouncer vigilantia compatitur. Mediocris interrogationis tempus exsecutionis reddere possumus. Sed tempus mediocris est temperatura mediocris in hospitali: aliquis frigidus est, aliquis calidus - in mediocris quisque sanus est. Non est verum.
Pro centonibus subsidii ad effectum deducendi opus est, quod significamus petitiones tardas esse quae facultates consumunt et vigilantia gratiora facturi sunt.
Praecipuum est quod versionem 1.0 desidero (Version 1.1 iam dimissa est). Ita est, quod nunc Odyssea est in versione 1.0rc, i.e., dimittere candidatum. Et omnes rastri, quos enumeravi, prorsus eadem litera fixa sunt, praeter memoriam perpluo.
Quid 1.0 versionem vult nobis? Odysseam volvimus ad bases nostras. Iam in nostris databases currit, sed cum ad 1 petitionum secundarum pervenerit, tunc dicere possumus hanc versionem emissio esse et haec versio quae 000 appellari potest.
Plures in conventu plures moras petiverunt et SCRAM in versione 1.0. Sed hoc significabit nos necesse esse versionem proximam ad productionem evolvere, quia nec SCRAM nec mora adhuc coalescit. Sed, verisimile, satis cito haec quaestio solvetur.
Im 'expectans viverra petitionem tuam. Vellem etiam audire quae problemata apud Bouncer habes. Discutiamus eos. Forsitan aliqua munera efficere possumus quae vos postulo.
Hoc concludit equidem ex te audire velim. Gratias tibi!
quaestiones
Si applicationem_nomen meum dedero, rectene coniecta erit, cum in re comparata in Odyssea?
Odyssey or Bouncer?
in Odyssea. Bouncer iactatur.
Faciamus statutum.
Et si verus nexus adsultim supra alios nexus, numquid tradetur?
Statutum faciemus omnium parametri, qui recensentur. Non possum dicere si application_nomen in hoc indice est. Videtur quod ibi eum vidisset. parametri omnes eadem ponemus. Uno rogatu, statutum faciet omnia quae a cliente in initio inaugurata sunt.
Gratias Andrey pro fama! Fama bona! Laetor Odyssea omnia minutatim ocius et velocius evolvere. eadem manere vellem. Iam a te petivimus ut multarum notitiarum nexum habeas, ut Odyssea diversis databases simul, i.e., servum coniungere possit, et tunc sponte novo domino post deficientem coniungere possit.
Imo videor referre illam disputationem. Plures schedulae nunc sunt. Sed nulla inter eos. A nobis, quaerendum est servo hoc adhuc vivere et intellegere defectorem accidisse, qui pg_recuperare incipiet. Vexillum habeo ad intelligendum quod nos ad dominum non venimus. Et quomodo intellegendum est quomodolibet ex erroribus? Id est, de idea est interesting, de qua agitur. Plura scribere comment. Si manibus opus habes, qui noverunt C, hoc fere mirum est.
Eventus per replicas scalas etiam nobis interest, quia adoptionem uvarum replicatarum quam maxime fieri volumus ad applicationes tincidunt. Sed hic plura commenta libet, hoc est, facere, quam bene facere.
Item quaeritur de replicas. Evenit quod habetis a domino et pluribus replicas. Et patet quod rarius vadunt ad replicam quam ad dominum propter hospites, quia possunt habere differentiam. Dixisti quod talis differentia notitiarum sit ut negotia tua non satisfaciant, et ibi non ibis donec replicatur. Eodem tempore, si non diu ibis, et tunc ire incepi, tunc notitia quam opus non erit statim praesto. Hoc est, si assidue ad dominum pergamus, tunc cella ibi calefacta est, et paulo post in imagine cella est.
Sic suus 'verum. Nullae notitiae clausulae in pcache quae vis, in cache reali notitia nulla erit de tabulis quas vis, nulla parsed quaestionis in consiliis, nihil omnino.
Et cum habeas aliquod genus botri, et addis ibi novam imaginem, tunc dum incipit, omne malum est in eo, i.e., crescit in cella sua.
duxi ideam. Rectus accessus esset ad parvas recipis interrogationes ad primum replicam currendam, quae latibulum foveret. Dure loquendo condicionem habemus ut non plus quam X secundis post dominum esse debeamus. Et haec conditio non debet poni in una fluctu, sed aequaliter in aliquibus clientibus.
Auge pondus.
Haec est bona idea. Sed primum hoc shutdown efficere debes. Primum averte opus est, deinde quomodo verto cogitabimus. Magnum est hoc pluma vertere in lubricum.
nginx habet hanc optionem slowly start in botro pro servo. et onus gradatim aedificat.
Ita, magna idea, experimentum dabimus cum ad illud perveniemus.
Source: www.habr.com