{"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 Lasten auf einem Highload-Projekt mit Hilfe von ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, \u0425\u0430\u0431\u0440! Mein Name ist Maxim Vasiliev, ich arbeite als Analyst und Projektmanager bei FINCH. Heute m\u00f6chte ich Ihnen erz\u00e4hlen, wie wir mit Hilfe von ElasticSearch 15 Millionen Anfragen in 6 Minuten bearbeitet haben und die t\u00e4glichen Lasten auf der Website eines unserer Kunden optimieren konnten. Leider m\u00fcssen wir ohne Namen auskommen, da wir eine NDA haben; wir hoffen, dass der Inhalt des Artikels davon nicht leidet. Lass uns anfangen.
\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 Anwendung unseres Kunden sicherstellen. Die Gesamtstruktur ist im Diagramm zu sehen:<\/p>\n

\"Optimierung
\n
\nIm Laufe der Arbeit verarbeiten wir eine gro\u00dfe Anzahl von Transaktionen: K\u00e4ufe, Auszahlungen, Benutzerkontenaktionen, f\u00fcr die wir viele Protokolle speichern, und au\u00dferdem importieren und exportieren wir diese Daten in externe Systeme. <\/p>\n

Es gibt auch R\u00fcckprozesse, bei denen wir Daten vom Kunden erhalten und diese an die Benutzer weitergeben. Au\u00dferdem gibt es auch Prozesse f\u00fcr die Abwicklung von Zahlungen und Bonussystemen.<\/p>\n

Eine kurze Hintergrundgeschichte<\/h2>\n

\nUrspr\u00fcnglich haben wir PostgreSQL als einziges Datenspeicher verwendet. Seine Standardvorteile f\u00fcr Datenbanken: Transaktionen, ausgefeilte Abfragesprache, umfangreiche Integrationswerkzeuge; in Kombination mit guter Leistung haben sie unsere Bed\u00fcrfnisse lange Zeit erf\u00fcllt. <\/p>\n

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

Zur Veranschaulichung: Die j\u00e4hrliche Anzahl der Sitzungen im Jahr 2017 nur auf der Desktop-Website betr\u00e4gt 131 Millionen. 2018 waren es 125 Millionen. 2019 wieder 130 Millionen. Wenn man noch 100-200 Millionen von der mobilen Version der Website und der mobilen Anwendung hinzuf\u00fcgt, ergibt das eine kolossale Anzahl von Anfragen. <\/i><\/p>\n

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

Wir wussten, dass es notwendig war, andere Datenspeicher in Betracht zu ziehen, die unsere Bed\u00fcrfnisse abdecken und die Last von PostgreSQL nehmen w\u00fcrden. Elasticsearch und MongoDB wurden als m\u00f6gliche Varianten in Betracht gezogen. Letzteres weist in den folgenden Punkten Nachteile auf:<\/p>\n

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

    \nSo haben wir uns f\u00fcr Elastic entschieden und uns auf den Umstieg vorbereitet. <\/p>\n

    Umstieg auf Elastic<\/h2>\n

    \n1. Wir haben den Umstieg 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