{"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\/nl\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","title":{"rendered":"Optimalisatie van de belasting op een Highload-project met behulp van ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr! Mijn naam is Maxim Vasilyev, ik werk als analist en projectmanager bij FINCH. Vandaag wil ik vertellen hoe we met ElasticSearch 15 miljoen verzoeken in 6 minuten hebben verwerkt en de dagelijkse belasting op de website van een van onze klanten hebben geoptimaliseerd. Helaas moeten we het zonder namen doen, omdat we een NDA hebben; we hopen dat de inhoud van het artikel daar niet onder zal lijden. Laten we beginnen.
\n<\/a><\/noindex><\/p>\n

Hoe het project is opgebouwd<\/h2>\n

\nOp onze backend cre\u00ebren we diensten die de werking van de websites en de mobiele applicatie van onze klant waarborgen. De algemene structuur is te zien op het schema:<\/p>\n

\"Optimalisatie
\n
\nTijdens ons werk verwerken we een groot aantal transacties: aankopen, uitbetalingen, operaties met de saldo's van gebruikers, waarvoor we veel logs opslaan, en we importeren en exporteren deze gegevens naar externe systemen. <\/p>\n

Er zijn ook omgekeerde processen, waarbij we gegevens van de klant ontvangen en deze aan de gebruikers doorgeven. Daarnaast zijn er nog processen voor betalingen en bonusprogramma's.<\/p>\n

Korte voorgeschiedenis<\/h2>\n

\nAanvankelijk gebruikten we PostgreSQL als enige gegevensopslag. De standaard voordelen van databases: aanwezigheid van transacties, een uitgebreide gegevensophaal-taal, een breed scala aan integratietools; in combinatie met goede prestaties voldeden lang aan onze behoeften. <\/p>\n

We slaagden in Postgres absoluut alle gegevens op: van transacties tot nieuws. Maar het aantal gebruikers groeide, en daarmee ook het aantal verzoeken.<\/p>\n

Ter verduidelijking, het jaarlijkse aantal sessies in 2017 alleen op de desktopwebsite was 131 miljoen. In 2018 waren dat 125 miljoen. 2019 had weer 130 miljoen. Voeg daar nog eens 100-200 miljoen aan toe van de mobiele versie van de site en de mobiele applicatie, en je krijgt een kolossaal aantal verzoeken. <\/i><\/p>\n

Met de groei van het project kon Postgres de belasting niet meer aan; we konden niet volgen \u2014 er kwamen veel verschillende verzoeken bij die we niet konden voorzien van voldoende indexen. <\/p>\n

We begrepen dat er behoefte was aan andere gegevensopslagsystemen die aan onze behoeften konden voldoen en de belasting van PostgreSQL konden verlichten. We overwegen Elasticsearch en MongoDB als mogelijke opties. De laatste had op de volgende punten tekortkomingen:<\/p>\n

    \n
  1. Langzame indexeringsnelheid met de groei van het datavolume in de indexen. Bij Elastic hangt de snelheid niet af van het datavolume.<\/li>\n
  2. Geen volledige tekstdoorzoekfunctie<\/li>\n<\/ol>\n

    \nZo hebben we voor onszelf Elastic gekozen en we zijn begonnen met de overstap. <\/p>\n

    Overstappen naar Elastic<\/h2>\n

    \n1. We zijn begonnen met de overstap van de zoekdienst voor verkooppunten. Onze klant heeft in totaal ongeveer 70.000 verkooppunten, en er zijn verschillende soorten zoekopdrachten nodig op de website en in de app:<\/p>\n