{"id":82734,"date":"2020-05-24T13:42:22","date_gmt":"2020-05-24T11:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch"},"modified":"2020-05-24T13:42:22","modified_gmt":"2020-05-24T11:42:22","slug":"optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","title":{"rendered":"Optimering af belastningen p\u00e5 Highload-projekter ved hj\u00e6lp af ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hej, Habr! Mit navn er Maksim Vasiljev, jeg arbejder som analytiker og projektleder hos FINCH. I dag vil jeg gerne fort\u00e6lle, hvordan vi ved hj\u00e6lp af ElasticSearch kunne behandle 15 millioner foresp\u00f8rgsler p\u00e5 6 minutter og optimere de daglige belastninger p\u00e5 en af vores kunders websteder. Desv\u00e6rre m\u00e5 vi undv\u00e6re navne, da vi har NDA, men vi h\u00e5ber, at indholdet af artiklen ikke lider under dette. Lad os komme i gang.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Hvordan projektet er sat op<\/h2>\n<p>\nP\u00e5 vores backend opretter vi tjenester, der sikrer, at vores kundes websteder og mobilapplikation fungerer. Den overordnede struktur kan ses i diagrammet:<\/p>\n<p><img decoding=\"async\" alt=\"Optimering af belastningen p\u00e5 Highload-projekter ved hj\u00e6lp af ElasticSearch\" src=\"\/wp-content\/uploads\/2020\/05\/7bda10a9965163c2b175b501f50bc342.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI l\u00f8bet af arbejdet behandler vi et stort antal transaktioner: k\u00f8b, udbetalinger, operationer med brugernes konti, for hvilke vi opbevarer mange logs, og vi importerer og eksporterer ogs\u00e5 disse data til eksterne systemer. <\/p>\n<p>Der er ogs\u00e5 omvendte processer, hvor vi modtager data fra kunden og sender dem til brugerne. Derudover findes der ogs\u00e5 processer til h\u00e5ndtering af betalinger og bonusprogrammer.<\/p>\n<h2>Kort baggrunds historie<\/h2>\n<p>\nOprindeligt brugte vi PostgreSQL som det eneste datalager. Dets standardfortrin som DBMS: tilstedev\u00e6relsen af transaktioner, et avanceret datav\u00e6lgingssprog, et bredt v\u00e6rkt\u00f8jss\u00e6t til integration; i kombination med god ydeevne tilfredsstillede det vores behov i lang tid. <\/p>\n<p>Vi opbevarede alle data i Postgres: fra transaktioner til nyheder. Men antallet af brugere voksede, og det samme gjorde antallet af foresp\u00f8rgsler.<\/p>\n<p><i>Til sammenligning var det \u00e5rlige antal sessioner i 2017 kun p\u00e5 desktopwebstedet - 131 millioner. I 2018 - 125 millioner. 2019 igen 130 millioner. Tilf\u00f8j yderligere 100-200 millioner fra mobilversionen af webstedet og mobilapplikationen, og du f\u00e5r et kolossalt antal foresp\u00f8rgsler. <\/i><\/p>\n<p>Med v\u00e6ksten af projektet kunne Postgres ikke h\u00e5ndtere belastningen, vi kunne ikke f\u00f8lge med - der kom et stort antal forskellige foresp\u00f8rgsler, for hvilke vi ikke kunne oprette tilstr\u00e6kkeligt med indekser. <\/p>\n<p>Vi inds\u00e5, at der var behov for andre datalagre, der kunne im\u00f8dekomme vores behov og aflaste PostgreSQL. Vi overvejede som muligheder Elasticsearch og MongoDB. Den sidstn\u00e6vnte tabte p\u00e5 f\u00f8lgende punkter:<\/p>\n<ol>\n<li>Langsom indekseringshastighed med stigende m\u00e6ngde data i indeksene. Hos Elastic afh\u00e6nger hastigheden ikke af datam\u00e6ngden.<\/li>\n<li>Ingen fuldtekst s\u00f8gning<\/li>\n<\/ol>\n<p>\nS\u00e5 vi valgte Elastic til os selv og forberedte os p\u00e5 overgangen. <\/p>\n<h2>Overgang til Elastic<\/h2>\n<p>\n1. Vi begyndte overgangen med s\u00f8getjenesten for salgssteder. Vores kunde har i alt omkring 70.000 salgssteder, og der kr\u00e6ves flere typer s\u00f8gning p\u00e5 hjemmesiden og i appen:<\/p>\n<ul>\n<li>Teksts\u00f8gning efter navn p\u00e5 by<\/li>\n<li>Geos\u00f8gning inden for en bestemt radius fra et punkt. For eksempel, hvis brugeren \u00f8nsker at se, hvilke salgssteder der ligger t\u00e6ttest p\u00e5 hans hjem.<\/li>\n<li>S\u00f8gning inden for et specificeret kvadrat \u2013 brugeren tegner et kvadrat p\u00e5 kortet, og han f\u00e5r vist alle punkter inden for denne radius. <\/li>\n<li>S\u00f8gning efter yderligere filtre. Salgsstederne adskiller sig fra hinanden efter sortiment. <\/li>\n<\/ul>\n<p>\nN\u00e5r det kommer til organisationen, s\u00e5 har vi i Postgres kilden til data b\u00e5de til kort og nyheder, mens der i Elastic laves snapshots fra de originale data. Det er fordi, at Postgres oprindeligt ikke kunne h\u00e5ndtere s\u00f8gning p\u00e5 alle kriterier. Der var ikke blot mange indekser, de kunne ogs\u00e5 krydse hinanden, s\u00e5 planl\u00e6ggeren i Postgres blev forvirret og vidste ikke, hvilken indeks han skulle bruge. <\/p>\n<p>2. N\u00e6ste afdeling var nyhedssektionen. Hjemmesiden f\u00e5r hver dag nye publikationer, s\u00e5 brugeren ikke g\u00e5r tabt i informationsstr\u00f8mmen, skal dataene sorteres f\u00f8r udlevering. Derfor er der brug for s\u00f8gning: p\u00e5 hjemmesiden kan man s\u00f8ge ved tekstm\u00e6ssig overensstemmelse, og samtidig kunne tilf\u00f8je yderligere filtre, da de ogs\u00e5 er bygget via Elastic. <\/p>\n<p>3. Derefter flyttede vi behandlingen af transaktioner. Brugerne kan k\u00f8be bestemte varer p\u00e5 hjemmesiden og deltage i lodtr\u00e6kninger om pr\u00e6mier. Efter s\u00e5danne k\u00f8b behandler vi en stor m\u00e6ngde data, is\u00e6r i weekender og p\u00e5 helligdage. Til sammenligning, hvis antallet af k\u00f8b p\u00e5 almindelige dage ligger p\u00e5 omkring 1,5-2 millioner, kan tallet p\u00e5 helligdage n\u00e5 op til 53 millioner.<\/p>\n<p>Samtidig skal dataene behandles p\u00e5 minimal tid \u2014 brugerne kan ikke lide at vente flere dage p\u00e5 resultaterne. Gennem Postgres kan man ikke opn\u00e5 s\u00e5danne tider \u2014 vi fik ofte l\u00e5sninger, og mens vi behandlede alle anmodninger, kunne brugerne ikke kontrollere, om de havde vundet pr\u00e6mier eller ej. Det er ikke s\u00e6rlig behageligt for forretningen, s\u00e5 vi flyttede behandlingen til Elasticsearch.<\/p>\n<h2>Frekvens<\/h2>\n<p>\nOpdateringer er i \u00f8jeblikket sat op til at ske baseret p\u00e5 f\u00f8lgende betingelser:<\/p>\n<ol>\n<li>Salgssteder. S\u00e5 snart vi modtager data fra en ekstern kilde, starter vi straks opdateringen. <\/li>\n<li>Nyheder. N\u00e5r der redigeres en nyhed p\u00e5 siden, sendes den automatisk til Elastic.<\/li>\n<\/ol>\n<p>\nHer er det v\u00e6rd at n\u00e6vne fordelene ved Elastic. I Postgres skal man vente p\u00e5, at systemet behandler alle poster, n\u00e5r en foresp\u00f8rgsel sendes. I Elastic kan man sende 10.000 poster og straks begynde at arbejde uden at vente p\u00e5, at posterne distribueres til alle Shards. Naturligvis kan en eller anden Shard eller Replica muligvis ikke se dataene med det samme, men snart vil alt v\u00e6re tilg\u00e6ngeligt.<\/p>\n<h2>Integrationsmetoder<\/h2>\n<p>\nDer er 2 m\u00e5der at integrere med Elastic:<\/p>\n<ol>\n<li>Gennem den native klient via TCP. Den native driver er gradvist ved at udd\u00f8: den f\u00e5r ikke l\u00e6ngere st\u00f8tte, og dens syntaks er meget uh\u00e5ndterlig. Derfor bruger vi den n\u00e6sten ikke og str\u00e6ber efter helt at undg\u00e5 den.<\/li>\n<li>Gennem HTTP-gr\u00e6nsefladen, hvor man kan bruge b\u00e5de JSON-foresp\u00f8rgsler og Lucene-syntaks. Sidstn\u00e6vnte er en tekstmotor, der bruger Elastic. P\u00e5 denne m\u00e5de f\u00e5r vi Batch-mulighed gennem JSON-foresp\u00f8rgsler via HTTP. Det er denne metode, vi str\u00e6ber efter at bruge.<\/li>\n<\/ol>\n<p>\nTakket v\u00e6re HTTP-gr\u00e6nsefladen kan vi bruge biblioteker, der tilbyder asynkron udf\u00f8relse af HTTP-klienten. Vi kan udnytte Batch og den asynkrone API, hvilket i sidste ende giver h\u00f8j ydeevne, som har hjulpet meget under store kampagner (mere om dette nedenfor)<\/p>\n<p>Nogle tal til sammenligning: <\/p>\n<ul>\n<li>Gemmes brugere, der modtog pr\u00e6mier i Postgres, i 20 tr\u00e5de uden gruppere: 460713 poster p\u00e5 42 sekunder<\/li>\n<li>Elastic + reaktiv klient p\u00e5 10 tr\u00e5de + batch med 1000 elementer: 596749 poster p\u00e5 11 sekunder<\/li>\n<li>Elastic + reaktiv klient p\u00e5 10 tr\u00e5de + batch med 1000 elementer: <b>23801684 poster p\u00e5 4 minutter<\/b><\/li>\n<\/ul>\n<p>\nVi har nu skrevet en HTTP-foresp\u00f8rgselsmanager, der opbygger JSON, hvad enten det er Batch\/ikke Batch, og sender det gennem enhver HTTP-klient uanset bibliotek. Det er ogs\u00e5 muligt at v\u00e6lge synkront eller asynkront at sende foresp\u00f8rgsler.<\/p>\n<p>I nogle integrationer bruger vi stadig den officielle transportklient, men det er kun et sp\u00f8rgsm\u00e5l om den n\u00e6rmeste refaktorering. Desuden bruges en egen klient bygget p\u00e5 Spring WebClient til behandlingen.<\/p>\n<p><img decoding=\"async\" alt=\"Optimering af belastningen p\u00e5 Highload-projekter ved hj\u00e6lp af ElasticSearch\" src=\"\/wp-content\/uploads\/2020\/05\/112bf3261c93ce585d8559b420e79f64.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Stor kampagne<\/h2>\n<p>\nEn gang om \u00e5ret afholdes der en stor kampagne for brugerne - det er den s\u00e5kaldte Highload, da vi i denne periode arbejder med titusindvis af brugere samtidigt.<\/p>\n<p>Normalt forekommer belastningstop i helligdage, men denne kampagne er p\u00e5 en helt anden niveau. I forrige \u00e5r solgte vi 27.580.890 enheder p\u00e5 kampagnedagen. Dataene blev behandlet i mere end en halv time, hvilket for\u00e5rsagede ubehag for brugerne. Brugerne modtog pr\u00e6mier for deres deltagelse, men det blev klart, at processen skulle fremskyndes. <\/p>\n<p>I begyndelsen af 2019 besluttede vi, at vi havde brug for ElasticSearch. Et helt \u00e5r arbejdede vi med at organisere behandlingen af de indkomne data i Elastic og deres levering til API'en i mobilapplikationen og p\u00e5 hjemmesiden. Resultatet var, at vi \u00e5ret efter under kampagnen behandlede <b>15.131.783 poster p\u00e5 6 minutter. <\/b><\/p>\n<p>Da vi har mange, der \u00f8nsker at k\u00f8be produkter og deltage i pr\u00e6mietrekningerne i kampagnerne, er dette en midlertidig foranstaltning. Lige nu sender vi aktuel information til Elastic, men i fremtiden planl\u00e6gger vi at flytte arkivinformation fra de tidligere m\u00e5neder til Postgres som permanent opbevaring. For ikke at tilstoppe Elastic-indekset, som ogs\u00e5 har sine begr\u00e6nsninger.<\/p>\n<h2>Konklusioner<\/h2>\n<p>\nI \u00f8jeblikket har vi overf\u00f8rt alle de tjenester, vi \u00f8nskede, til Elastic, og vi har taget en pause her. Lige nu bygger vi et indeks i Elastic oven p\u00e5 det prim\u00e6re vedholdende lagringssystem i Postgres, som h\u00e5ndterer belastningen fra brugerne.<\/p>\n<p>I fremtiden planl\u00e6gger vi at overf\u00f8re tjenester, hvis vi forst\u00e5r, at foresp\u00f8rgslen p\u00e5 data bliver for mangfoldig og s\u00f8ges p\u00e5 et ubegribelig antal kolonner. Dette er allerede ikke en opgave for Postgres.<\/p>\n<p>Hvis vi f\u00e5r brug for fuldteksts\u00f8gning i funktionaliteten, eller hvis vi f\u00e5r mange forskellige s\u00f8gekriterier, s\u00e5 ved vi allerede, at det skal overf\u00f8res til Elastic.<\/p>\n<h2>\u2318\u2318\u2318<\/h2>\n<p>\nTak fordi du l\u00e6ste med! Hvis din virksomhed ogs\u00e5 bruger ElasticSearch og har egne implementeringscases, s\u00e5 fort\u00e6l os om dem. Det ville v\u00e6re interessant at h\u00f8re, hvordan andre g\u00f8r det \ud83d\ude42<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/503214\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0430\u043a\u0441\u0438\u043c \u0412\u0430\u0441\u0438\u043b\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u043e\u043c \u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 FINCH. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e ElasticSearch, \u043c\u044b \u0441\u043c\u043e\u0433\u043b\u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c 15 \u043c\u043b\u043d \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0437\u0430 6 \u043c\u0438\u043d\u0443\u0442 \u0438 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0435\u0436\u0435\u0434\u043d\u0435\u0432\u043d\u044b\u0435 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043d\u0430 \u0441\u0430\u0439\u0442\u0435 \u043e\u0434\u043d\u043e\u0433\u043e \u0438\u0437 \u043d\u0430\u0448\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432. \u041a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u043f\u0440\u0438\u0434\u0451\u0442\u0441\u044f \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c \u0431\u0435\u0437 \u0438\u043c\u0451\u043d, \u0442\u0430\u043a \u043a\u0430\u043a \u0443 \u043d\u0430\u0441 NDA, \u043d\u0430\u0434\u0435\u0435\u043c\u0441\u044f, \u0447\u0442\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82735,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82734","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0430\u043a\u0441\u0438\u043c \u0412\u0430\u0441\u0438\u043b\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u043e\u043c \u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 FINCH.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043d\u0430 Highload-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e ElasticSearch | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0430\u043a\u0441\u0438\u043c \u0412\u0430\u0441\u0438\u043b\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u043e\u043c \u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 FINCH.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-24T11:42:22+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-24T11:42:22+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Optimering af belastningen p\u00e5 Highload-projektet med ElasticSearch | ProHoster","description":"Hej, Habr! Mit navn er Maksim Vasiliev, jeg arbejder som analytiker og projektleder hos FINCH.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043d\u0430 Highload-\u043f\u0440\u043e\u0435\u043a\u0442\u0435 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e ElasticSearch | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0430\u043a\u0441\u0438\u043c \u0412\u0430\u0441\u0438\u043b\u044c\u0435\u0432, \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u043e\u043c \u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 FINCH.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-24T11:42:22+00:00","article:modified_time":"2020-05-24T11:42:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:32:25","updated":"2022-09-28 21:13:07","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=82734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/82734\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/82735"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=82734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=82734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=82734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}