Arsitéktur dina mémori pikeun jasa wéb: dasar sareng prinsip téknologi

In-Memory mangrupikeun sakumpulan konsép pikeun nyimpen data nalika disimpen dina RAM aplikasi sareng disk dianggo pikeun cadangan. Dina pendekatan klasik, data disimpen dina disk sareng mémori disimpen dina cache. Salaku conto, aplikasi wéb anu nganggo backend pikeun ngolah data nyuhunkeun kana panyimpenan: éta nampi, ngarobih, sareng seueur data ditransferkeun kana jaringan. Dina In-Memory, itungan dikirim ka data - ka panyimpenan, tempat diolah jeung beban dina jaringan.

Hatur nuhun kana arsitékturna, In-Memory nyepetkeun aksés data sababaraha kali, sareng sakapeung langkung gancang. Salaku conto, analis bank hoyong ningali dina aplikasi analitik laporan ngeunaan pinjaman anu dikaluarkeun dina dinamika sadinten pikeun taun ka tukang. Prosés ieu bakal butuh sababaraha menit dina DBMS klasik, tapi kalayan In-Memory éta bakal langsung muncul. Ieu kusabab pendekatan ngamungkinkeun anjeun pikeun cache langkung seueur inpormasi sareng disimpen dina RAM "di tangan". Aplikasina henteu kedah nyuhunkeun data tina hard drive, kasadiaan anu diwatesan ku jaringan sareng kacepetan disk.

Naon kamungkinan séjén anu sayogi sareng In-Memory sareng pendekatan naon ieu? Vladimir Pligin - insinyur di GridGain. Materi ulasan ieu bakal mangpaat pikeun pamekar backend aplikasi wéb anu teu acan damel sareng In-Memory sareng hoyong nyobian, atanapi museurkeun tren modéren dina pamekaran parangkat lunak sareng desain arsitéktur.

nyarios. Tulisan ieu dumasar kana transkrip laporan Vladimir di #GetIT Conf. Sateuacan ngenalkeun ngasingkeun diri, urang rutin ngayakeun rapat sareng konferensi pikeun pamekar di Moskow sareng St. Petersburg: urang ngabahas tren, masalah pangwangunan ayeuna, masalah sareng solusina. Henteu mungkin pikeun ngayakeun konperénsi ayeuna, tapi waktosna pikeun ngabagi bahan anu mangpaat tina anu kapungkur.

Saha anu ngagunakeun In-Memori sareng kumaha

In-Memory paling sering dianggo dimana interaksi pangguna gancang atanapi ngolah data anu ageung diperyogikeun.

• bank nganggo In-Memory, contona, pikeun ngirangan telat nalika klien nganggo aplikasi atanapi nganalisis klien sateuacan ngaluarkeun pinjaman.
• Fintech ngagunakeun In-Memory pikeun ngaronjatkeun kinerja jasa jeung aplikasi pikeun bank nu outsource ngolah data jeung analisis. 
• pausahaan asuransi: keur ngitung resiko, contona, ku analisa data nasabah leuwih sababaraha taun.
• pausahaan logistik. Aranjeunna ngolah seueur data, contona, pikeun ngitung rute optimal pikeun angkutan barang sareng panumpang kalayan rébuan parameter, sareng ngalacak status kiriman.
• Écéran. Solusi In-Memori ngabantosan ngalayanan para nasabah langkung gancang sareng ngolah inpormasi anu ageung: kiriman, invoice, transaksi, ayana rébuan barang di gudang, sareng nyiapkeun laporan analitik.
• В IoT In-Memory ngagantikeun basis data tradisional.
• Farmasi pausahaan make In-Memory, contona, pikeun nyortir ngaliwatan kombinasi komposisi ubar. 

Kuring bakal nyaritakeun sababaraha conto kumaha klien kami nganggo solusi In-Memory sareng kumaha anjeun tiasa nerapkeunana sorangan.

In-Memori salaku panyimpenan primér

Salah sahiji klien kami mangrupikeun supplier alat ilmiah médis ti AS. Aranjeunna nganggo solusi In-Memory salaku panyimpen data utama. Sadaya data disimpen dina disk, sareng sawaréh data anu aktip dianggo disimpen dina RAM. Métode aksés panyimpenan standar nyaéta GDBC (Generic Database Connector) sareng basa query SQL.

Sacara koléktif ieu disebut In-Memory Database (IMDB) atanapi Memory-Centric Storage. Kelas solusi ieu ngagaduhan seueur nami, sanés ngan ukur ieu. 

Keunggulan IMDB:

• Data anu disimpen dina In-Memory sareng diaksés ngalangkungan SQL sami sareng pendekatan anu sanés. Aranjeunna disingkronkeun, ngan cara presentasi, cara ngungkulan aranjeunna béda. Transactionality jalan antara data.

• IMDB leuwih gancang ti database relational sabab leuwih gancang pikeun meunangkeun informasi ti RAM ti disk. 
• Algoritma optimasi internal gaduh petunjuk anu langkung sakedik.
• IMDB cocog pikeun ngatur data, acara sareng transaksi dina aplikasi.

IMDB sawaréh ngadukung ACID: Atomicity, Konsistensi, sareng Isolasi. Tapi aranjeunna henteu ngadukung "daya tahan" - nalika kakuatan dipareuman, sadaya data leungit. Pikeun ngabéréskeun masalah, anjeun tiasa nganggo snapshot - "snapshot" tina pangkalan data, sami sareng cadangan database dina hard drive, atanapi ngarékam transaksi (log) pikeun mulangkeun data saatos reboot.

Pikeun nyieun aplikasi toleran kasalahan

Hayu urang bayangkeun arsitéktur klasik tina aplikasi wéb anu teu toleran. Gawéna sapertos kieu: sadaya pamundut disebarkeun ku pangimbang wéb antara server. Sistem ieu stabil sabab pangladén silih duplikat sareng nyadangkeun upami aya kajadian.

Balancer ngarahkeun sadaya pamundut ti hiji sési sacara ketat ka hiji server. Ieu mékanisme sési iteuk: unggal sési pakait sareng server dimana eta disimpen lokal sarta diprosés. 

Naon anu lumangsung nalika salah sahiji server gagal?

Ladenan moal kapangaruhan sabab arsitékturna diduplikasi. Tapi urang bakal leungit sawaréh tina sési server maot. Sareng dina waktos anu sami, pangguna anu kabeungkeut kana sési ieu. Contona, hiji klien nempatkeun pesenan sarta dumadakan throws anjeunna kaluar ti kantor. Anjeunna bakal bagja nalika anjeunna log in deui sareng mendakan yén sadayana kedah dilakukeun deui.

Aplikasi wéb diperyogikeun pikeun ngadukung sajumlah ageung pangguna sareng henteu ngalambatkeun supados aranjeunna tiasa dianggo kalayan nyaman. Tapi lamun ditolak, kalawan unggal pamundut saterusna waktu nu diperlukeun pikeun komunikasi sareng toko sési bakal nambahan. Ieu ngaronjatkeun latency rata pikeun pamaké séjén. Tapi aranjeunna henteu hoyong ngantosan langkung lami tibatan anu biasa.

Masalah ieu tiasa direngsekeun sapertos klien kami anu sanés, panyadia PASS ageung ti AS. Éta ngagunakeun In-Memory pikeun ngakelompokkeun sési wéb. Jang ngalampahkeun ieu, eta nyimpen aranjeunna henteu lokal, tapi centrally - dina klaster Dina-Memori. Dina hal ieu, sesi sadia leuwih gancang sabab geus aya dina RAM.

Nalika server ngadat, balancer ngirim requests ti server nabrak ka server séjén, sakumaha dina arsitektur klasik. Tapi aya bédana penting: sési disimpen dina klaster Dina-Memori sarta server boga aksés ka sesi tina server fallen.

Arsitéktur ieu ngaronjatkeun kasabaran sesar tina sakabéh sistem. Leuwih ti éta, kasebut nyaéta dimungkinkeun pikeun abandon mékanisme sési iteuk sakabehna.

Hybrid Transactional Analytical Processing (HTAP)

Ilaharna, sistem transactional sareng analitis disimpen misah. Nalika aranjeunna misahkeun, dasar utama asalna dina beban. Pikeun ngolah analitik, data disalin kana réplika supados pamrosésan analitik henteu ngaganggu prosés transaksional. Tapi nyalin lumangsung kalawan lag-teu mungkin pikeun ngayakeun réplikasi tanpa lag. Lamun urang ngalakukeun ieu synchronously, eta oge bakal ngalambatkeun turun dasar utama jeung urang moal meunang winnings wae.

Dina HTAP, sagalana jalan béda - nyimpen data sarua dipaké pikeun beban transactional tina aplikasi, sarta pikeun queries analitik nu bisa nyandak lila pikeun réngsé. Nalika data aya dina RAM, queries analitik dieksekusi gancang, sarta server kalawan database kirang dimuat (rata-rata).

Pendekatan hibrid ngarecah témbok antara pamrosésan transaksi sareng analitik. Upami urang ngalakukeun analitik dina panyimpenan anu sami, teras patarosan analitis diluncurkeun dina data tina RAM. Aranjeunna langkung akurat, langkung tiasa diinterpretasi sareng nyukupan.

Integrasi solusi Dina-Memori

Hiji cara (relatif) basajan - ngamekarkeun sagalana ti scratch. Urang nyimpen data dina disk jeung nyimpen data panas dina mémori. Ieu mantuan salamet reboots server atawa outages.

Aya dua skenario utama anu dianggo di dieu nalika data disimpen dina disk. Anu mimiti, urang hoyong salamet kacilakaan atanapi reboots biasa tina klaster atanapi bagian - urang hoyong nganggo éta salaku pangkalan data saderhana. Dina skenario kadua, lamun aya teuing data, sababaraha di antarana aya dina mémori.

Lamun teu mungkin pikeun ngawangun sagalana ti scratch, kasebut nyaéta dimungkinkeun pikeun ngahijikeun Dina-Memori kana hiji geus arsitéktur aya. Tapi henteu sadayana solusi In-Memory cocog pikeun ieu. Aya tilu syarat wajib. Solusi In-Memory kedah ngadukung:

• cara standar pikeun nyambung ka pangkalan data anu bakal aya di handapeunna (contona, MySQL);
• basa query baku, ku kituna teu nulis balik sarta ngarobah logika interaksi jeung gudang;
• transactional - ngawétkeun semantik interaksi.

Upami sadayana tilu syarat kacumponan, maka integrasi tiasa dilaksanakeun. Urang nempatkeun Grid Data Dina-Memori antara aplikasi sareng pangkalan data. Ayeuna nyerat pamundut bakal didelegasikeun ka pangkalan data dasar, sareng pamundut baca bakal didelegakeun ka pangkalan data dasar upami data henteu aya dina cache.

Upami aksés gancang kana data sareng pamrosésanna penting pikeun anjeun, contona, pikeun analytics bisnis, anjeun tiasa mikir ngeunaan ngalaksanakeun In-Memory. Sareng pikeun palaksanaan, anjeun tiasa nganggo duanana metode nalika ngarancang arsitéktur énggal.

sumber: www.habr.com