Muatkan pengoptimuman pada projek Highload dengan ElasticSearch

Hai Habr! Nama saya Maxim Vasiliev, saya bekerja sebagai penganalisis dan pengurus projek di FINCH. Hari ini saya ingin memberitahu anda bagaimana, menggunakan ElasticSearch, kami dapat memproses 15 juta permintaan dalam masa 6 minit dan mengoptimumkan beban harian di tapak salah seorang pelanggan kami. Malangnya, kami perlu melakukan tanpa nama, kerana kami mempunyai NDA, kami berharap kandungan artikel itu tidak akan mengalami perkara ini. Mari pergi.

Bagaimana projek itu berfungsi

Pada bahagian belakang kami, kami mencipta perkhidmatan yang memastikan prestasi tapak web dan aplikasi mudah alih pelanggan kami. Struktur umum boleh dilihat dalam rajah:

Dalam proses kerja, kami memproses sejumlah besar transaksi: pembelian, pembayaran, operasi dengan baki pengguna, yang mana kami menyimpan banyak log, serta mengimport dan mengeksport data ini ke sistem luaran.

Terdapat juga proses terbalik apabila kami menerima data daripada klien dan memindahkannya kepada pengguna. Di samping itu, masih terdapat proses untuk bekerja dengan pembayaran dan program bonus.

Latar belakang ringkas

Pada mulanya, kami menggunakan PostgreSQL sebagai satu-satunya stor data. Kelebihan standardnya untuk DBMS: kehadiran transaksi, bahasa pensampelan data yang dibangunkan, pelbagai alat untuk penyepaduan; digabungkan dengan prestasi yang baik memenuhi keperluan kami untuk masa yang agak lama.

Kami benar-benar menyimpan semua data dalam Postgres: daripada urus niaga kepada berita. Tetapi bilangan pengguna bertambah, dan dengan itu bilangan permintaan.

Untuk pemahaman, bilangan sesi tahunan pada 2017 sahaja di tapak desktop ialah 131 juta. Pada 2018 - 125 juta. 2019 sekali lagi 130 juta. Tambah lagi 100-200 juta daripada versi mudah alih tapak dan aplikasi mudah alih, dan anda akan mendapat sejumlah besar permintaan.

Dengan pertumbuhan projek, Postgres berhenti menangani beban, kami tidak mempunyai masa - sejumlah besar pelbagai pertanyaan muncul, yang mana kami tidak dapat membuat bilangan indeks yang mencukupi.

Kami memahami bahawa terdapat keperluan untuk stor data lain yang akan menyediakan keperluan kami dan mengurangkan beban PostgreSQL. Elasticsearch dan MongoDB dianggap sebagai pilihan yang mungkin. Yang terakhir kalah pada mata berikut:

1. Kelajuan pengindeksan perlahan apabila jumlah data dalam indeks bertambah. Dengan Elastik, kelajuan tidak bergantung pada jumlah data.
2. Tiada carian teks penuh

Jadi kami memilih Elastik untuk diri kami sendiri dan bersedia untuk peralihan.

Peralihan kepada Elastik

1. Kami memulakan peralihan daripada perkhidmatan carian tempat jualan. Pelanggan kami mempunyai sejumlah kira-kira 70 mata jualan, dan ini memerlukan beberapa jenis carian di tapak dan dalam aplikasi:

• Carian teks mengikut nama bandar
• Geosearch dalam radius tertentu dari satu titik. Contohnya, jika pengguna ingin melihat tempat jualan yang paling hampir dengan rumahnya.
• Cari mengikut petak tertentu - pengguna melukis petak pada peta, dan semua titik dalam jejari ini ditunjukkan kepadanya.
• Cari mengikut penapis tambahan. Tempat jualan berbeza antara satu sama lain dalam pelbagai

Jika kita bercakap tentang organisasi, maka dalam Postgres kita mempunyai sumber data untuk kedua-dua peta dan berita, dan dalam Syot Kilat Elastik diambil daripada data asal. Hakikatnya ialah pada mulanya Postgres tidak dapat menampung carian mengikut semua kriteria. Bukan sahaja terdapat banyak indeks, ia juga boleh bertindih, jadi penjadual Postgres tersesat dan tidak memahami indeks yang hendak digunakan.

2. Seterusnya adalah bahagian berita. Penerbitan muncul di laman web setiap hari supaya pengguna tidak tersesat dalam aliran maklumat, data mesti diisih sebelum dikeluarkan. Inilah tujuan carian: anda boleh mencari tapak mengikut padanan teks, dan pada masa yang sama menyambungkan penapis tambahan, kerana ia juga dibuat melalui Elastik.

3. Kemudian kami mengalihkan pemprosesan transaksi. Pengguna boleh membeli produk tertentu di tapak dan mengambil bahagian dalam cabutan hadiah. Selepas pembelian sedemikian, kami memproses sejumlah besar data, terutamanya pada hujung minggu dan hari cuti. Sebagai perbandingan, jika pada hari biasa bilangan pembelian adalah antara 1,5-2 juta, maka pada hari cuti angka itu boleh mencapai 53 juta.

Pada masa yang sama, data mesti diproses dalam masa yang sesingkat mungkin - pengguna tidak suka menunggu hasilnya selama beberapa hari. Tiada cara untuk mencapai tarikh akhir sedemikian melalui Postgres - kami sering menerima kunci, dan semasa kami memproses semua permintaan, pengguna tidak dapat menyemak sama ada mereka menerima hadiah atau tidak. Ini tidak begitu menyenangkan untuk perniagaan, jadi kami mengalihkan pemprosesan ke Elasticsearch.

Berkala

Kini kemas kini dikonfigurasikan berasaskan acara, mengikut syarat berikut:

1. Mata jualan. Sebaik sahaja kami menerima data daripada sumber luaran, kami segera memulakan kemas kini.
2. Berita. Sebaik sahaja sebarang berita disunting di tapak, ia dihantar secara automatik kepada Elastic.

Di sini sekali lagi adalah bernilai menyebut kelebihan Elastik. Dalam Postgres, apabila menghantar permintaan, anda perlu menunggu sehingga ia memproses semua rekod dengan jujur. Anda boleh menghantar 10 rekod ke Elastic dan mula bekerja serta-merta, tanpa menunggu rekod diedarkan ke semua Shard. Sudah tentu, sesetengah Shard atau Replica mungkin tidak melihat data serta-merta, tetapi semuanya akan tersedia tidak lama lagi.

Kaedah integrasi

Terdapat 2 cara untuk mengintegrasikan dengan Elastik:

1. Melalui klien asli melalui TCP. Pemacu asli secara beransur-ansur mati: ia tidak lagi disokong, ia mempunyai sintaks yang sangat menyusahkan. Oleh itu, kami secara praktikal tidak menggunakannya dan cuba meninggalkannya sepenuhnya.
2. Melalui antara muka HTTP yang boleh menggunakan kedua-dua permintaan JSON dan sintaks Lucene. Yang terakhir ialah enjin teks yang menggunakan Elastik. Dalam versi ini, kami mendapat keupayaan untuk Batch melalui permintaan JSON melalui HTTP. Ini adalah pilihan yang kami cuba gunakan.

Terima kasih kepada antara muka HTTP, kami boleh menggunakan perpustakaan yang menyediakan pelaksanaan tak segerak bagi klien HTTP. Kami boleh memanfaatkan Batch dan API tak segerak, yang menghasilkan prestasi tinggi, yang banyak membantu semasa promosi besar (lebih lanjut mengenai perkara di bawah)

Beberapa nombor untuk perbandingan:

• Menyimpan pengguna hadiah Postgres dalam 20 utas tanpa pengumpulan: 460713 rekod dalam 42 saat
• Pelanggan anjal + reaktif untuk 10 utas + kelompok untuk 1000 elemen: 596749 rekod dalam 11 saat
• Pelanggan elastik + reaktif untuk 10 utas + kelompok untuk 1000 elemen: 23801684 penyertaan dalam masa 4 minit

Kini kami telah menulis pengurus permintaan HTTP yang membina JSON sebagai Batch/bukan Batch dan menghantarnya melalui mana-mana klien HTTP, tanpa mengira perpustakaan. Anda juga boleh memilih untuk menghantar permintaan secara serentak atau tidak segerak.

Dalam sesetengah penyepaduan, kami masih menggunakan pelanggan pengangkutan rasmi, tetapi ini hanyalah soal pemfaktoran semula seterusnya. Dalam kes ini, pelanggan tersuai yang dibina berdasarkan Spring WebClient digunakan untuk pemprosesan.

promosi besar

Sekali setahun, projek ini menganjurkan promosi besar untuk pengguna - ini adalah Highload yang sama, kerana pada masa ini kami bekerja dengan berpuluh juta pengguna pada masa yang sama.

Biasanya puncak beban berlaku semasa cuti, tetapi promosi ini berada pada tahap yang berbeza sama sekali. Tahun sebelum lepas, pada hari promosi, kami menjual 27 unit barang. Data telah diproses selama lebih daripada setengah jam, yang menyebabkan ketidakselesaan bagi pengguna. Pengguna menerima hadiah untuk penyertaan, tetapi menjadi jelas bahawa proses itu perlu dipercepatkan.

Pada awal tahun 2019, kami memutuskan bahawa kami memerlukan ElasticSearch. Selama setahun penuh, kami menganjurkan pemprosesan data yang diterima dalam Elastic dan pengeluarannya dalam api aplikasi mudah alih dan tapak web. Hasilnya, tahun depan semasa kempen, kami memproses 15 penyertaan dalam masa 131 minit.

Memandangkan kami mempunyai ramai orang yang ingin membeli barangan dan mengambil bahagian dalam cabutan hadiah dalam promosi, ini adalah langkah sementara. Kini kami menghantar maklumat terkini kepada Elastic, tetapi pada masa hadapan kami merancang untuk memindahkan maklumat yang diarkibkan untuk beberapa bulan lalu kepada Postgres sebagai storan kekal. Agar tidak menyumbat indeks Elastik, yang juga mempunyai batasannya.

Kesimpulan/Kesimpulan

Pada masa ini, kami telah memindahkan semua perkhidmatan yang kami mahukan kepada Elastic dan telah menjeda perkara ini buat masa ini. Kini kami sedang membina indeks dalam Elastik di atas storan berterusan utama dalam Postgres, yang mengambil alih beban pengguna.

Pada masa hadapan, kami merancang untuk memindahkan perkhidmatan jika kami memahami bahawa permintaan data menjadi terlalu pelbagai dan dicari untuk bilangan lajur yang tidak terhad. Ini bukan lagi tugas untuk Postgres.

Jika kita memerlukan carian teks penuh dalam fungsi atau jika kita mempunyai banyak kriteria carian yang berbeza, maka kita sudah tahu bahawa ini perlu diterjemahkan ke dalam Elastik.

⌘⌘⌘

Terima kasih untuk membaca. Jika syarikat anda juga menggunakan ElasticSearch dan mempunyai kes pelaksanaannya sendiri, maka beritahu kami. Ia akan menjadi menarik untuk mengetahui bagaimana orang lain 🙂

Sumber: www.habr.com