Hey Habr! Jenengku Maxim Vasiliev, aku kerja minangka analis lan manajer proyek ing FINCH. Dina iki, aku arep menehi pitutur marang kowe carane, nggunakake ElasticSearch, kita bisa ngolah 15 yuta panjalukan ing 6 menit lan ngoptimalake beban saben dina ing situs salah sawijining klien. Sayange, kita kudu nindakake tanpa jeneng, amarga kita duwe NDA, muga-muga konten artikel kasebut ora bakal nandhang sangsara. Ayo budal.
Carane proyek bisa
Ing backend kita, kita nggawe layanan sing njamin kinerja situs web klien lan aplikasi seluler. Struktur umum bisa dideleng ing diagram:
Ing proses karya, kita proses akeh transaksi: tumbas, pembayaran, operasi karo saldo pangguna, kang kita nyimpen akèh log, uga ngimpor lan ngekspor data iki kanggo sistem external.
Ana uga pangolahan mbalikke nalika kita nampa data saka klien lan nransfer menyang pangguna. Kajaba iku, isih ana proses kanggo nggarap pembayaran lan program bonus.
Latar mburi singkat
Kaping pisanan, kita nggunakake PostgreSQL minangka mung nyimpen data. Kaluwihan standar kanggo DBMS: anane transaksi, basa sampling data sing dikembangake, macem-macem alat kanggo integrasi; digabungake karo kinerja apik marem kabutuhan kita kanggo dangu.
Kita nyimpen kabeh data ing Postgres: saka transaksi nganti warta. Nanging jumlah pangguna tansaya tambah, lan kanthi jumlah panjaluk.
Kanggo pangerten, jumlah sesi taunan ing 2017 mung ing situs desktop 131 yuta. Ing 2018 - 125 yuta. 2019 maneh 130 yuta. Tambah 100-200 yuta liyane saka versi seluler situs lan aplikasi seluler, lan sampeyan bakal njaluk nomer ageng panjalukan.
Kanthi tuwuhing proyek kasebut, Postgres mandheg ngatasi beban kasebut, kita ora duwe wektu - akeh macem-macem pitakon muncul, sing ora bisa nggawe indeks sing cukup.
Kita mangertos manawa ana kabutuhan kanggo nyimpen data liyane sing bakal nyedhiyakake kabutuhan lan ngilangi beban PostgreSQL. Elasticsearch lan MongoDB dianggep minangka pilihan sing bisa ditindakake. Sing terakhir kalah ing poin ing ngisor iki:
- Kacepetan indeksasi alon amarga jumlah data ing indeks mundhak. Kanthi Elastis, kacepetan ora gumantung saka jumlah data.
- Ora ana telusuran teks lengkap
Dadi kita milih Elastis kanggo awake dhewe lan disiapake kanggo transisi.
Transisi menyang Elastis
1. Kita miwiti transisi saka titik layanan panelusuran sale. Klien kita duwe udakara udakara 70 titik adol, lan iki mbutuhake sawetara jinis telusuran ing situs kasebut lan ing aplikasi kasebut:
- Panelusuran teks miturut jeneng kutha
- Geosearch ing radius tartamtu saka sawetara titik. Contone, yen pangguna pengin ndeleng titik dodolan sing paling cedhak karo omahe.
- Telusuri kanthi kothak sing diwenehake - pangguna nggambar kothak ing peta, lan kabeh titik ing radius iki dituduhake marang dheweke.
- Telusuri kanthi saringan tambahan. Titik dodolan beda-beda ing macem-macem
Yen kita ngomong babagan organisasi, banjur ing Postgres kita duwe sumber data kanggo peta lan warta, lan ing Elastic Snapshots dijupuk saka data asli. Kasunyatane yaiku wiwitane Postgres ora bisa ngrampungake telusuran kanthi kabeh kritΓ©ria. Ora mung ana akeh indeks, nanging uga bisa tumpang tindih, mula panjadwal Postgres ilang lan ora ngerti indeks sing digunakake.
2. Salajengipun perangan pawarta. Publikasi katon ing situs saben dina supaya pangguna ora ilang ing aliran informasi, data kudu diurutake sadurunge nerbitake. Iki minangka telusuran: sampeyan bisa nelusuri situs kanthi cocog teks, lan ing wektu sing padha nyambung saringan tambahan, amarga uga digawe liwat Elastis.
3. Banjur kita pindhah pangolahan transaksi. Pangguna bisa tuku produk tartamtu ing situs kasebut lan melu undian hadiah. Sawise tumbas kuwi, kita proses akeh data, utamanΓ© ing akhir minggu lan preian. Kanggo mbandhingake, yen ing dina biasa jumlah tumbas ana ing antarane 1,5-2 yuta, banjur ing preian angka kasebut bisa nganti 53 yuta.
Ing wektu sing padha, data kudu diproses ing wektu sing paling cendhak - pangguna ora seneng ngenteni asil nganti pirang-pirang dina. Ora ana cara kanggo nggayuh tenggat wektu kasebut liwat Postgres - kita asring nampa kunci, lan nalika kita ngolah kabeh panjaluk, pangguna ora bisa mriksa manawa dheweke nampa hadiah utawa ora. Iki ora nyenengake kanggo bisnis, mula proses kasebut dipindhah menyang Elasticsearch.
Periodicity
Saiki nganyari dikonfigurasi adhedhasar acara, miturut kahanan ing ngisor iki:
- Titik dodolan. Sanalika kita nampa data saka sumber eksternal, kita langsung miwiti nganyari.
- Kabar. Sanalika warta apa wae sing diowahi ing situs kasebut, kanthi otomatis dikirim menyang Elastic.
Ing kene maneh kudu disebutake kaluwihan Elastis. Ing Postgres, nalika ngirim panjalukan, sampeyan kudu ngenteni nganti proses kabeh cathetan kanthi jujur. Sampeyan bisa ngirim 10 cathetan menyang Elastic lan langsung kerja, tanpa ngenteni cathetan kasebut disebarake ing kabeh Shards. Mesthi, sawetara Shard utawa Replica bisa uga ora langsung ndeleng data kasebut, nanging kabeh bakal kasedhiya kanthi cepet.
Metode Integrasi
Ana 2 cara kanggo nggabungake karo Elastis:
- Liwat klien asli liwat TCP. Pembalap asli mboko sithik mati: ora didhukung maneh, duwe sintaks sing ora trep. Mulane, kita prakteke ora nggunakake lan nyoba kanggo rampung ninggalake.
- Liwat antarmuka HTTP sing bisa nggunakake panjalukan JSON lan sintaks Lucene. Sing pungkasan yaiku mesin teks sing nggunakake Elastis. Ing versi iki, kita entuk kemampuan kanggo Batch liwat panjalukan JSON liwat HTTP. Iki minangka pilihan sing kita coba gunakake.
Thanks kanggo antarmuka HTTP, kita bisa nggunakake perpustakaan sing nyedhiyakake implementasine ora sinkron saka klien HTTP. Kita bisa njupuk kauntungan saka Batch lan API asinkron, sing ngasilake kinerja dhuwur, sing mbantu akeh ing dina promosi gedhe (liyane ing ngisor iki)
Sawetara angka kanggo mbandhingake:
- Nyimpen pangguna hadiah Postgres ing 20 utas tanpa ngelompokake: 460713 cathetan ing 42 detik
- Klien elastis + reaktif kanggo 10 utas + kumpulan kanggo 1000 unsur: 596749 cathetan ing 11 detik
- Klien elastis + reaktif kanggo 10 utas + kumpulan kanggo 1000 unsur: 23801684 entri ing 4 menit
Saiki kita wis nulis manajer panjalukan HTTP sing mbangun JSON minangka Batch / ora Batch lan dikirim liwat klien HTTP apa wae, tanpa dipikirake perpustakaan. Sampeyan uga bisa milih ngirim panjalukan kanthi sinkron utawa ora sinkron.
Ing sawetara integrasi, kita isih nggunakake klien transportasi resmi, nanging iki mung masalah refactoring sabanjure. Ing kasus iki, klien khusus sing dibangun kanthi basis Spring WebClient digunakake kanggo diproses.
promosi gedhe
Setaun sepisan, proyek kasebut dadi promosi gedhe kanggo pangguna - iki minangka Highload sing padha, amarga ing wektu iki kita kerja bareng karo puluhan yuta pangguna ing wektu sing padha.
Biasane puncak beban kedadeyan nalika preian, nanging promosi iki ana ing tingkat sing beda. Taun sadurunge pungkasan, ing dina promosi, kita adol 27 unit barang. Data kasebut diproses luwih saka setengah jam, sing nyebabake rasa ora nyaman kanggo pangguna. Pangguna nampa hadiah kanggo partisipasi, nanging dadi cetha yen proses kasebut kudu dicepetake.
Ing awal 2019, kita mutusake yen kita butuh ElasticSearch. Kanggo setaun setaun, kita ngatur pangolahan data sing ditampa ing Elastic lan diterbitake ing api aplikasi seluler lan situs web. AkibatΓ©, taun sabanjurΓ© nalika kampanye, kita proses 15 entri ing 131 menit.
Amarga kita duwe akeh wong sing pengin tuku barang lan melu nggambar hadiah ing promosi, iki minangka langkah sementara. Saiki kita ngirim informasi paling anyar menyang Elastic, nanging ing mangsa ngarep kita arep nransfer informasi arsip kanggo sasi kepungkur menyang Postgres minangka panyimpenan permanen. Supaya ora clog indeks Elastis, kang uga duwe watesan.
Kesimpulan / Kesimpulan
Saiki, kita wis nransfer kabeh layanan sing dikarepake kanggo Elastis lan saiki wis ngaso. Saiki kita mbangun indeks ing Elastis ing ndhuwur panyimpenan terus-terusan utama ing Postgres, sing njupuk alih beban pangguna.
Ing mangsa ngarep, kita arep nransfer layanan yen kita ngerti manawa panjaluk data dadi maneka warna lan digoleki kanthi jumlah kolom sing ora ana watesan. Iki ora dadi tugas kanggo Postgres.
Yen kita butuh telusuran teks lengkap ing fungsionalitas utawa yen kita duwe akeh kritΓ©ria telusuran sing beda-beda, mula kita wis ngerti manawa iki kudu diterjemahake menyang Elastis.
βββ
Matur nuwun kanggo maca. Yen perusahaan sampeyan uga nggunakake ElasticSearch lan duwe kasus implementasine dhewe, banjur ngandhani. Iku bakal menarik kanggo ngerti carane wong liya π
Source: www.habr.com