{"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\/it\/blog\/administrirovanie\/optimizacziya-nagruzki-na-highload-proekte-s-pomoshhyu-elasticsearch","title":{"rendered":"Ottimizzazione del carico su un progetto Highload con ElasticSearch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr! Mi chiamo Maxim Vasiliev, lavoro come analista e project manager in FINCH. Oggi vorrei raccontare come, utilizzando ElasticSearch, siamo riusciti a elaborare 15 milioni di richieste in 6 minuti e ottimizzare i carichi quotidiani sul sito di uno dei nostri clienti. Sfortunatamente, dovremo fare a meno dei nomi, poich\u00e9 abbiamo un NDA, speriamo che il contenuto dell'articolo non ne risenta. Let`s go.
\n<\/a><\/noindex><\/p>\n

Come \u00e8 strutturato il progetto<\/h2>\n

\nSul nostro backend creiamo servizi che garantiscono il funzionamento dei siti e dell'applicazione mobile del nostro cliente. La struttura generale pu\u00f2 essere vista nello schema:<\/p>\n

\"Ottimizzazione
\n
\nNel processo di lavoro elaboriamo un grande numero di transazioni: acquisti, pagamenti, operazioni con i saldi degli utenti, per i quali conserviamo molti log, oltre a importare ed esportare questi dati in sistemi esterni. <\/p>\n

Ci sono anche processi inversi, quando riceviamo dati dal cliente e li trasmettiamo agli utenti. Inoltre, esistono anche processi relativi ai pagamenti e ai programmi di premi.<\/p>\n

Breve introduzione<\/h2>\n

\nInizialmente utilizzavamo PostgreSQL come unica soluzione di archiviazione dei dati. I suoi standard vantaggi per DBMS: disponibilit\u00e0 di transazioni, un linguaggio di query avanzato, un'ampia gamma di strumenti per l'integrazione; insieme a buone prestazioni, soddisfacevano le nostre esigenze per un bel po' di tempo. <\/p>\n

Conservavamo in Postgres tutti i dati: dalle transazioni alle notizie. Ma il numero di utenti cresceva, e con esso anche il numero di richieste.<\/p>\n

Per capire, il numero annuale di sessioni nel 2017 solo sul sito desktop era di 131 milioni. Nel 2018 era di 125 milioni. Nel 2019 ancora 130 milioni. Aggiungi altro 100-200 milioni dalla versione mobile del sito e dall'app mobile, e otterrai un numero colossale di richieste. <\/i><\/p>\n

Con la crescita del progetto, Postgres ha smesso di far fronte al carico, eravamo in ritardo - \u00e8 emerso un gran numero di richieste diverse, per le quali non abbiamo potuto creare un numero sufficiente di indici. <\/p>\n

Abbiamo capito che c'era bisogno di altri sistemi di archiviazione dei dati, che soddisfacessero le nostre esigenze e riducessero il carico su PostgreSQL. Abbiamo considerato come opzioni Elasticsearch e MongoDB. Quest'ultimo perdeva su questi punti:<\/p>\n

    \n
  1. La velocit\u00e0 di indicizzazione lenta con l'aumento del volume dei dati negli indici. Con Elastic, la velocit\u00e0 non dipende dal volume dei dati.<\/li>\n
  2. Nessuna ricerca full-text<\/li>\n<\/ol>\n

    \nCos\u00ec abbiamo scelto Elastic e ci siamo preparati alla migrazione. <\/p>\n

    Migrazione a Elastic<\/h2>\n

    \n1. Abbiamo iniziato la migrazione dal servizio di ricerca dei punti vendita. Il nostro cliente ha un totale di circa 70.000 punti vendita e sono necessari diversi tipi di ricerca sul sito e nell'app:<\/p>\n