{"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\/de\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","title":{"rendered":"Optimierung der Last auf Highload-Projekten mit ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr! Mein Name ist Maxim Vasiliev, ich arbeite als Analyst und Projektmanager bei FINCH. Heute m\u00f6chte ich erz\u00e4hlen, wie wir es mit Hilfe von ElasticSearch geschafft haben, 15 Millionen Anfragen in 6 Minuten zu verarbeiten und die t\u00e4glichen Lasten auf der Website eines unserer Kunden zu optimieren. Leider m\u00fcssen wir ohne Namen auskommen, da wir eine NDA haben. Wir hoffen, dass der Inhalt des Artikels darunter nicht leidet. Lass uns beginnen.
\n<\/a><\/noindex><\/p>\n

Wie das Projekt aufgebaut ist<\/h2>\n

\nIn unserem Backend erstellen wir Dienste, die die Funktionsf\u00e4higkeit der Websites und der mobilen Anwendungen unseres Kunden gew\u00e4hrleisten. Die allgemeine Struktur ist in der folgenden Grafik zu sehen:<\/p>\n

\"Optimierung
\n
\nIm Verlauf unserer Arbeit verarbeiten wir eine gro\u00dfe Anzahl von Transaktionen: K\u00e4ufen, Auszahlungen, Operationen mit Benutzerkonten, zu denen wir viele Protokolle speichern, sowie Daten in externe Systeme importieren und exportieren. <\/p>\n

Es gibt auch umgekehrte Prozesse, bei denen wir Daten vom Kunden erhalten und an die Benutzer \u00fcbermitteln. Dar\u00fcber hinaus gibt es Prozesse, die sich mit Zahlungen und Bonusprogrammen befassen.<\/p>\n

Kurze Vorgeschichte<\/h2>\n

\nUrspr\u00fcnglich nutzten wir PostgreSQL als prim\u00e4res Datenspeicher. Die Standardvorteile von DBMS: Transaktionen, eine ausgefeilte Abfragesprache und ein umfangreiches Integrationswerkzeug; in Verbindung mit einer soliden Leistung erf\u00fcllten sie unsere Anforderungen \u00fcber einen l\u00e4ngeren Zeitraum zufriedenstellend. <\/p>\n

Wir speicherten in Postgres alle Daten: von Transaktionen bis hin zu Nachrichten. Doch die Anzahl der Benutzer stieg, und damit auch die Menge der Anfragen.<\/p>\n

Zum Verst\u00e4ndnis: die j\u00e4hrliche Anzahl der Sitzungen im Jahr 2017 nur auf der Desktop-Website betrug 131 Millionen. Im Jahr 2018 waren es 125 Millionen. 2019 erneut 130 Millionen. F\u00fcgen Sie noch 100-200 Millionen von der mobilen Version der Website und der mobilen App hinzu, und Sie erhalten eine enorme Anzahl von Anfragen. <\/i><\/p>\n

Mit dem Wachstum des Projekts konnte Postgres die Last nicht mehr bew\u00e4ltigen, wir kamen nicht hinterher \u2014 es gab eine gro\u00dfe Vielfalt an Anfragen, f\u00fcr die wir nicht gen\u00fcgend Indizes erstellen konnten. <\/p>\n

Wir haben erkannt, dass es notwendig ist, andere Datenspeicher zu haben, die unseren Anforderungen entsprechen und die Belastung von PostgreSQL reduzieren. Als m\u00f6gliche Optionen haben wir Elasticsearch und MongoDB in Betracht gezogen. Letzteres fiel in den folgenden Punkten zur\u00fcck:<\/p>\n

    \n
  1. Langsame Indizierungsgeschwindigkeit mit zunehmendem Volumen der Indizes. Bei Elastic h\u00e4ngt die Geschwindigkeit nicht vom Datenvolumen ab.<\/li>\n
  2. Kein Volltextsuche.<\/li>\n<\/ol>\n

    \nSo haben wir uns f\u00fcr Elastic entschieden und die Vorbereitungen f\u00fcr den Wechsel getroffen. <\/p>\n

    Wechsel zu Elastic<\/h2>\n

    \n1. Wir haben den Wechsel mit dem Suchdienst f\u00fcr Verkaufsstellen begonnen. Unser Kunde hat insgesamt etwa 70.000 Verkaufsstellen, und es werden mehrere Suchtypen auf der Website und in der App ben\u00f6tigt:<\/p>\n