{"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\/fr\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","title":{"rendered":"Optimisation de la charge sur un projet Highload avec ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Bonjour, Habr ! Je m'appelle Maxim Vassiliev, je travaille comme analyste et chef de projet chez FINCH. Aujourd'hui, je voudrais expliquer comment, gr\u00e2ce \u00e0 ElasticSearch, nous avons pu traiter 15 millions de requ\u00eates en 6 minutes et optimiser les charges quotidiennes sur le site de l'un de nos clients. Malheureusement, nous devrons nous passer de noms, car nous avons un NDA, mais nous esp\u00e9rons que le contenu de l'article ne souffrira pas de cela. Allons-y.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Comment le projet est structur\u00e9<\/h2>\n<p>\nDans notre backend, nous cr\u00e9ons des services qui assurent le bon fonctionnement des sites et de l'application mobile de notre client. La structure g\u00e9n\u00e9rale peut \u00eatre vue sur le sch\u00e9ma :<\/p>\n<p><img decoding=\"async\" alt=\"Optimisation de la charge sur un projet Highload avec ElasticSearch\" src=\"\/wp-content\/uploads\/2020\/05\/7bda10a9965163c2b175b501f50bc342.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDans le cadre de notre travail, nous traitons un grand nombre de transactions : achats, paiements, op\u00e9rations sur les soldes des utilisateurs, pour lesquelles nous stockons de nombreux logs, et nous importons \u00e9galement et exportons ces donn\u00e9es vers des syst\u00e8mes externes. <\/p>\n<p>Des processus inverses se d\u00e9roulent \u00e9galement, lorsque nous recevons des donn\u00e9es du client et les transmettons aux utilisateurs. En outre, il existe des processus relatifs aux paiements et aux programmes de bonus.<\/p>\n<h2>Une br\u00e8ve histoire<\/h2>\n<p>\nAu d\u00e9part, nous utilisions PostgreSQL comme unique stockage de donn\u00e9es. Ses avantages standards pour les SGBD : la pr\u00e9sence de transactions, un langage de requ\u00eate d\u00e9velopp\u00e9, un large \u00e9ventail d'outils pour l'int\u00e9gration ; associ\u00e9s \u00e0 une bonne performance, ils satisfaisaient nos besoins pendant assez longtemps. <\/p>\n<p>Nous stockions dans Postgres absolument toutes les donn\u00e9es : des transactions aux actualit\u00e9s. Mais le nombre d'utilisateurs augmentait, et avec lui, le nombre de requ\u00eates.<\/p>\n<p><i>Pour donner une id\u00e9e, le nombre annuel de sessions en 2017 sur le site desktop \u00e9tait de 131 millions. En 2018, il est tomb\u00e9 \u00e0 125 millions. En 2019, il a de nouveau atteint 130 millions. Ajoutez-y encore 100 \u00e0 200 millions de la version mobile du site et de l'application mobile, et vous obtiendrez un nombre colossal de requ\u00eates. <\/i><\/p>\n<p>Avec la croissance du projet, Postgres a cess\u00e9 de g\u00e9rer la charge, nous n'arrivions plus \u00e0 suivre \u2014 un grand nombre de requ\u00eates vari\u00e9es sont apparues, pour lesquelles nous n'avons pas pu cr\u00e9er un nombre suffisant d'index. <\/p>\n<p>Nous comprenions qu'il \u00e9tait n\u00e9cessaire d'avoir d'autres syst\u00e8mes de stockage qui r\u00e9pondraient \u00e0 nos besoins et all\u00e9geraient la charge sur PostgreSQL. Nous avons envisag\u00e9 Elasticsearch et MongoDB comme options possibles. La derni\u00e8re a \u00e9chou\u00e9 sur les points suivants :<\/p>\n<ol>\n<li>Une vitesse d'indexation lente avec l'augmentation du volume de donn\u00e9es dans les index. Avec Elastic, la vitesse n'est pas affect\u00e9e par le volume de donn\u00e9es.<\/li>\n<li>Pas de recherche en texte int\u00e9gral<\/li>\n<\/ol>\n<p>\nC'est ainsi que nous avons choisi Elastic et nous nous sommes pr\u00e9par\u00e9s \u00e0 la migration. <\/p>\n<h2>Migration vers Elastic<\/h2>\n<p>\n1. Nous avons commenc\u00e9 la migration avec le service de recherche de points de vente. Notre client a environ 70 000 points de vente au total, et il n\u00e9cessite plusieurs types de recherches sur le site et dans l'application :<\/p>\n<ul>\n<li>Recherche textuelle par nom de localit\u00e9<\/li>\n<li>Recherche g\u00e9ographique dans un rayon donn\u00e9 \u00e0 partir d'un point. Par exemple, si l'utilisateur veut voir quels points de vente sont les plus proches de chez lui.<\/li>\n<li>Recherche par un carr\u00e9 d\u00e9fini \u2013 l'utilisateur trace un carr\u00e9 sur la carte et tous les points dans ce rayon lui sont montr\u00e9s. <\/li>\n<li>Recherche par filtres suppl\u00e9mentaires. Les points de vente diff\u00e8rent les uns des autres par leur assortiment. <\/li>\n<\/ul>\n<p>\nEn ce qui concerne l'organisation, dans Postgres, nous avons une source de donn\u00e9es tant pour la carte que pour les nouvelles, et dans Elastic, des instantan\u00e9s des donn\u00e9es originales sont cr\u00e9\u00e9s. Le fait est qu'\u00e0 l'origine, Postgres ne parvenait pas \u00e0 effectuer des recherches selon tous les crit\u00e8res. Non seulement il y avait de nombreux index, mais ils pouvaient \u00e9galement se chevaucher, ce qui perdait le planificateur de Postgres et l'emp\u00eachait de comprendre quel index utiliser. <\/p>\n<p>2. Ensuite, c'\u00e9tait au tour de la section des nouvelles. Chaque jour, de nouvelles publications apparaissent sur le site, et pour que l'utilisateur ne se perde pas dans le flux d'informations, les donn\u00e9es doivent \u00eatre tri\u00e9es avant d'\u00eatre affich\u00e9es. C'est \u00e9galement le but de la recherche: sur le site, il est possible de rechercher par correspondance textuelle, tout en branchant des filtres suppl\u00e9mentaires, puisqu'ils sont aussi r\u00e9alis\u00e9s via Elastic. <\/p>\n<p>3. Ensuite, nous avons transf\u00e9r\u00e9 le traitement des transactions. Les utilisateurs peuvent acheter un certain produit sur le site et participer \u00e0 des tirages au sort. Apr\u00e8s ces achats, nous traitons un grand volume de donn\u00e9es, surtout durant les week-ends et les jours f\u00e9ri\u00e9s. \u00c0 titre de comparaison, en semaine, le nombre d'achats est d'environ 1,5 \u00e0 2 millions, alors qu'en p\u00e9riode de f\u00eates, ce chiffre peut atteindre 53 millions.<\/p>\n<p>De plus, les donn\u00e9es doivent \u00eatre trait\u00e9es dans les plus brefs d\u00e9lais \u2014 les utilisateurs n'aiment pas attendre plusieurs jours pour conna\u00eetre les r\u00e9sultats. Avec Postgres, on ne peut pas atteindre de tels d\u00e9lais \u2014 nous subissions souvent des blocages, et pendant que nous traitions toutes les requ\u00eates, les utilisateurs ne pouvaient pas v\u00e9rifier s'ils avaient gagn\u00e9 des prix ou non. Ce n'est pas tr\u00e8s agr\u00e9able pour les affaires, c'est pourquoi nous avons transf\u00e9r\u00e9 le traitement dans Elasticsearch.<\/p>\n<h2>Fr\u00e9quence<\/h2>\n<p>\nLes mises \u00e0 jour sont actuellement configur\u00e9es sur une base d'\u00e9v\u00e9nements, selon les conditions suivantes :<\/p>\n<ol>\n<li>Points de vente. D\u00e8s que nous recevons des donn\u00e9es d'une source externe, nous lan\u00e7ons imm\u00e9diatement la mise \u00e0 jour. <\/li>\n<li>Actualit\u00e9s. D\u00e8s qu'une actualit\u00e9 est modifi\u00e9e sur le site, elle est automatiquement envoy\u00e9e \u00e0 Elastic.<\/li>\n<\/ol>\n<p>\nIl convient encore une fois de mentionner les avantages d'Elastic. Dans Postgres, lors de l'envoi d'une requ\u00eate, il faut attendre qu'elle traite toutes les entr\u00e9es. Avec Elastic, il est possible d'envoyer 10 000 enregistrements et de commencer \u00e0 travailler imm\u00e9diatement, sans attendre que les donn\u00e9es se r\u00e9partissent sur tous les Shards. Bien s\u00fbr, un Shard ou une R\u00e9plica peuvent ne pas voir les donn\u00e9es imm\u00e9diatement, mais bient\u00f4t tout sera accessible.<\/p>\n<h2>M\u00e9thodes d'int\u00e9gration<\/h2>\n<p>\nIl existe 2 m\u00e9thodes d'int\u00e9gration avec Elastic :<\/p>\n<ol>\n<li>Via le client natif par TCP. Le pilote natif est progressivement abandonn\u00e9 : il n'est plus soutenu et a une syntaxe tr\u00e8s peu pratique. C'est pourquoi nous l'utilisons pratiquement plus et essayons de nous en d\u00e9barrasser totalement.<\/li>\n<li>Via l'interface HTTP, o\u00f9 l'on peut utiliser \u00e0 la fois des requ\u00eates JSON et la syntaxe Lucene. Ce dernier est le moteur texte utilis\u00e9 par Elastic. Dans cette option, nous avons la possibilit\u00e9 de Batch via des requ\u00eates JSON sur HTTP. C'est cette option que nous essayons d'utiliser.<\/li>\n<\/ol>\n<p>\nGr\u00e2ce \u00e0 l'interface HTTP, nous pouvons utiliser des biblioth\u00e8ques qui fournissent une impl\u00e9mentation asynchrone du client HTTP. Nous pouvons tirer parti de Batch et de l'API asynchrone, ce qui, en fin de compte, donne de hautes performances, qui ont \u00e9t\u00e9 tr\u00e8s utiles lors des grandes op\u00e9rations (\u00e0 ce sujet ci-dessous)<\/p>\n<p>Quelques chiffres pour la comparaison : <\/p>\n<ul>\n<li>Sauvegarde des utilisateurs ayant re\u00e7u des prix dans Postgres en 20 threads sans regroupements : 460 713 enregistrements en 42 secondes<\/li>\n<li>Elastic + client r\u00e9actif sur 10 threads + batch de 1000 \u00e9l\u00e9ments : 596 749 enregistrements en 11 secondes<\/li>\n<li>Elastic + client r\u00e9actif sur 10 threads + batch de 1000 \u00e9l\u00e9ments : <b>23 801 684 enregistrements en 4 minutes<\/b><\/li>\n<\/ul>\n<p>\nNous avons maintenant \u00e9crit un gestionnaire de requ\u00eates HTTP qui construit JSON, en tant que Batch\/non Batch, et envoie via n'importe quel client HTTP, ind\u00e9pendamment de la biblioth\u00e8que. Il est \u00e9galement possible de choisir d'envoyer des requ\u00eates de mani\u00e8re synchrone ou asynchrone.<\/p>\n<p>Dans certaines int\u00e9grations, nous utilisons encore le client de transport officiel, mais c'est juste une question de refactorisation prochaine. Pour le traitement, un client propre, construit sur la base de Spring WebClient, est utilis\u00e9.<\/p>\n<p><img decoding=\"async\" alt=\"Optimisation de la charge sur un projet Highload avec ElasticSearch\" src=\"\/wp-content\/uploads\/2020\/05\/112bf3261c93ce585d8559b420e79f64.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Grande op\u00e9ration<\/h2>\n<p>\nUne grande promotion a lieu une fois par an pour les utilisateurs - c'est ce fameux Highload, car \u00e0 ce moment l\u00e0, nous traitons des dizaines de millions d'utilisateurs simultan\u00e9ment.<\/p>\n<p>Les pics de charge se produisent g\u00e9n\u00e9ralement pendant les jours f\u00e9ri\u00e9s, mais cette promotion est d'un tout autre niveau. L'ann\u00e9e pr\u00e9c\u00e9dente, le jour de la promotion, nous avons vendu 27 580 890 unit\u00e9s. Les donn\u00e9es ont \u00e9t\u00e9 trait\u00e9es pendant plus d'une demi-heure, ce qui a caus\u00e9 des d\u00e9sagr\u00e9ments aux utilisateurs. Les utilisateurs ont re\u00e7u des prix pour leur participation, mais il est devenu \u00e9vident que le processus devait \u00eatre acc\u00e9l\u00e9r\u00e9. <\/p>\n<p>D\u00e9but 2019, nous avons d\u00e9cid\u00e9 qu'ElasticSearch \u00e9tait n\u00e9cessaire. Pendant toute une ann\u00e9e, nous avons organis\u00e9 le traitement des donn\u00e9es re\u00e7ues dans Elastic et leur fourniture via l'API de l'application mobile et du site. En cons\u00e9quence, l'ann\u00e9e suivante, pendant la promotion, nous avons trait\u00e9 <b>15 131 783 enregistrements en 6 minutes. <\/b><\/p>\n<p>\u00c9tant donn\u00e9 qu'il y a beaucoup de personnes d\u00e9sireuses d'acheter des produits et de participer \u00e0 des tirages pendant les promotions, c'est une mesure temporaire. Actuellement, nous envoyons les informations actuelles vers Elastic, mais \u00e0 l'avenir, nous pr\u00e9voyons de transf\u00e9rer des informations archiv\u00e9es des mois pr\u00e9c\u00e9dents vers Postgres, comme un stockage permanent. Cela nous permet d'\u00e9viter de surcharger l'index Elastic, qui a aussi ses limites.<\/p>\n<h2>Conclusion \/ R\u00e9sum\u00e9<\/h2>\n<p>\n\u00c0 l'heure actuelle, nous avons transf\u00e9r\u00e9 vers Elastic tous les services que nous voulions et nous avons mis cela en pause pour le moment. Maintenant, nous construisons un index dans Elastic au-dessus du stockage persistant principal dans Postgres, qui prend en charge la charge utilisateur.<\/p>\n<p>\u00c0 l'avenir, nous pr\u00e9voyons de transf\u00e9rer des services si nous r\u00e9alisons que les demandes de donn\u00e9es deviennent trop vari\u00e9es et que la recherche s'effectue sur un nombre illimit\u00e9 de colonnes. Cela devient d\u00e9j\u00e0 une t\u00e2che pour Postgres.<\/p>\n<p>Si nous avons besoin de recherche en texte int\u00e9gral dans les fonctionnalit\u00e9s ou si de nombreux crit\u00e8res de recherche vari\u00e9s apparaissent, nous savons d\u00e9j\u00e0 que cela devra \u00eatre transf\u00e9r\u00e9 vers Elastic.<\/p>\n<h2>\u2318\u2318\u2318<\/h2>\n<p>\nMerci d'avoir lu. Si votre entreprise utilise \u00e9galement ElasticSearch et a ses propres cas d'impl\u00e9mentation, n'h\u00e9sitez pas \u00e0 en parler. Ce sera int\u00e9ressant de savoir comment d'autres font \ud83d\ude42<br \/>\n<br \/>Source : <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.2 - 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\/fr\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47Optimisation de la charge sur un projet Highload avec ElasticSearch | ProHoster","description":"Bonjour, Habr ! Je m'appelle Maxim Vassiliev, je suis analyste et chef de projets chez FINCH.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/82734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=82734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/82734\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/82735"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=82734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=82734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=82734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}