{"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 Vasilyev, lavoro come analista e project manager in FINCH. Oggi vorrei raccontarvi come, grazie ad ElasticSearch, siamo riusciti a gestire 15 milioni di richieste in 6 minuti e ottimizzare i carichi quotidiani sul sito di un nostro cliente. Purtroppo, dobbiamo evitare di menzionare nomi specifici, poich\u00e9 abbiamo un NDA, ma speriamo che il contenuto dell'articolo non ne risenta. Iniziamo.
\n<\/a><\/noindex><\/p>\n

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

\nSul nostro backend creiamo servizi che garantiscono il funzionamento dei siti web e dell'app mobile del nostro cliente. La struttura generale \u00e8 visibile nello schema:<\/p>\n

\"Ottimizzazione
\n
\nDurante il nostro lavoro gestiamo un gran numero di transazioni: acquisti, pagamenti, operazioni sui saldi degli utenti, per le quali conserviamo molti log, oltre a importare ed esportare questi dati verso sistemi esterni. <\/p>\n

Ci sono anche processi inversi, in cui riceviamo dati dal cliente e li trasferiamo agli utenti. Inoltre, esistono processi legati ai pagamenti e ai programmi di fidelizzazione.<\/p>\n

Una breve introduzione<\/h2>\n

\nInizialmente, abbiamo utilizzato PostgreSQL come unico sistema di archiviazione dei dati. I suoi vantaggi standard come DBMS, inclusi le transazioni, un linguaggio di query avanzato e una vasta gamma di strumenti per l'integrazione, combinati con buone prestazioni, hanno soddisfatto le nostre esigenze per un periodo considerevole. <\/p>\n

Abbiamo memorizzato in Postgres tutti i dati: dalle transazioni alle notizie. Tuttavia, il numero di utenti cresceva, cos\u00ec come il numero delle richieste.<\/p>\n

Per dare un'idea, nel 2017 il numero annuale di sessioni sul sito desktop era di 131 milioni. Nel 2018 sono stati 125 milioni e nel 2019 di nuovo 130 milioni. Aggiungi altri 100-200 milioni dalla versione mobile del sito e dall'app mobile, e otterrai un'enorme quantit\u00e0 di richieste. <\/i><\/p>\n

Con la crescita del progetto, Postgres ha smesso di reggere il carico; non riuscivamo a stare al passo con l'aumento delle richieste, e c'era un gran numero di richieste varie per le quali non eravamo in grado di creare un numero sufficiente di indici. <\/p>\n

Abbiamo compreso la necessit\u00e0 di archivi dati alternativi che soddisfacessero le nostre esigenze e alleggerissero il carico su PostgreSQL. Tra le opzioni considerate c'erano Elasticsearch e MongoDB. Quest'ultmo presentava i seguenti svantaggi:<\/p>\n

    \n
  1. 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 a testo libero<\/li>\n<\/ol>\n

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

    Migrazione a Elastic<\/h2>\n

    \n1. Abbiamo iniziato il passaggio con il servizio di ricerca punti vendita. Il nostro cliente ha complessivamente circa 70.000 punti vendita, e sono necessari diversi tipi di ricerca sul sito e nell'app:<\/p>\n