Seni bina dalam memori untuk perkhidmatan web: asas dan prinsip teknologi

Dalam Memori ialah satu set konsep untuk menyimpan data apabila ia disimpan dalam RAM aplikasi, dan cakera digunakan untuk sandaran. Dalam pendekatan klasik, data disimpan pada cakera dan memori disimpan dalam cache. Contohnya, aplikasi web dengan bahagian belakang untuk memproses data memintanya menjadi storan: ia menerimanya, mengubahnya dan banyak data dipindahkan melalui rangkaian. Dalam Memori Dalam, pengiraan dihantar ke data - ke storan, di mana ia diproses dan rangkaian kurang dimuatkan.

Terima kasih kepada seni binanya, In-Memory mempercepatkan capaian data beberapa kali, malah kadangkala mengikut urutan magnitud, lebih pantas. Sebagai contoh, penganalisis bank ingin melihat dalam aplikasi analisis laporan mengenai pinjaman yang dikeluarkan dalam dinamik mengikut hari untuk tahun lepas. Proses ini akan mengambil masa beberapa minit pada DBMS klasik, tetapi dengan In-Memory ia akan muncul hampir serta-merta. Ini kerana pendekatan ini membolehkan anda menyimpan lebih banyak maklumat dan ia disimpan dalam RAM "di tangan". Aplikasi tidak perlu meminta data dari cakera keras, ketersediaannya terhad oleh rangkaian dan kelajuan cakera.

Apakah kemungkinan lain yang tersedia dengan In-Memory dan apakah jenis pendekatan ini? Vladimir Pligin - jurutera di GridGain. Bahan semakan ini berguna kepada pembangun bahagian belakang aplikasi web yang belum bekerja dengan In-Memory dan ingin mencuba, atau berminat dengan aliran moden dalam pembangunan perisian dan reka bentuk seni bina.

Nota. Artikel itu berdasarkan transkrip laporan Vladimir di #GetIT Conf. Sebelum pengenalan pengasingan diri, kami kerap mengadakan pertemuan dan persidangan untuk pembangun di Moscow dan St. Petersburg: kami membincangkan arah aliran, isu pembangunan semasa, masalah dan penyelesaiannya. Tidak mustahil untuk mengadakan persidangan sekarang, tetapi sudah tiba masanya untuk berkongsi bahan berguna dari yang terdahulu.

Siapa yang menggunakan In-Memory dan bagaimana

Dalam Memori paling kerap digunakan di mana interaksi pengguna pantas atau pemprosesan sejumlah besar data diperlukan.

• Bank gunakan Dalam Memori, sebagai contoh, untuk mengurangkan kelewatan apabila pelanggan menggunakan aplikasi atau menganalisis pelanggan sebelum mengeluarkan pinjaman.
• Fintech menggunakan In-Memory untuk meningkatkan prestasi perkhidmatan dan aplikasi untuk bank yang menyumber luar pemprosesan dan analisis data. 
• Syarikat insurans: untuk mengira risiko, contohnya, dengan menganalisis data pelanggan selama beberapa tahun.
• syarikat logistik. Mereka memproses banyak data, contohnya, untuk mengira laluan optimum untuk pengangkutan barang dan penumpang dengan beribu-ribu parameter, dan menjejaki status penghantaran.
• Runcit. Penyelesaian Dalam Memori membantu melayani pelanggan dengan lebih pantas dan memproses jumlah maklumat yang besar: penghantaran, invois, urus niaga, kehadiran beribu-ribu barang di gudang dan menyediakan laporan analisis.
• В IOT Dalam Memori menggantikan pangkalan data tradisional.
• Farmaseutikal syarikat menggunakan In-Memory, sebagai contoh, untuk menyusun gabungan komposisi ubat. 

Saya akan memberitahu anda beberapa contoh cara pelanggan kami menggunakan penyelesaian Dalam Memori dan cara anda boleh melaksanakannya sendiri.

Dalam Memori sebagai storan utama

Salah seorang pelanggan kami ialah pembekal besar peralatan saintifik perubatan dari Amerika Syarikat. Mereka menggunakan penyelesaian Dalam Memori sebagai storan data utama mereka. Semua data disimpan pada cakera, dan subset data yang digunakan secara aktif disimpan dalam RAM. Kaedah capaian storan adalah standard - GDBC (Generic Database Connector) dan bahasa pertanyaan SQL.

Secara kolektif ini dipanggil Pangkalan Data Dalam Memori (IMDB) atau Storan Berpusatkan Memori. Kelas penyelesaian ini mempunyai banyak nama, ini bukan satu-satunya. 

Ciri-ciri IMDB:

• Data yang disimpan dalam Memori Dalam dan diakses melalui SQL adalah sama seperti dalam pendekatan lain. Mereka disegerakkan, cuma cara penyampaian, cara menanganinya berbeza. Transaksionaliti berfungsi antara data.

• IMDB lebih pantas daripada pangkalan data hubungan kerana ia lebih pantas untuk mendapatkan maklumat daripada RAM berbanding cakera. 
• Algoritma pengoptimuman dalaman mempunyai lebih sedikit arahan.
• IMDB sesuai untuk mengurus data, peristiwa dan transaksi dalam aplikasi.

IMDB sebahagiannya menyokong ACID: Atomicity, Consistency, dan Pengasingan. Tetapi mereka tidak menyokong "ketahanan" - apabila kuasa dimatikan, semua data hilang. Untuk menyelesaikan masalah, anda boleh menggunakan syot kilat - "snapshot" pangkalan data, serupa dengan sandaran pangkalan data pada cakera keras, atau merekodkan transaksi (log) untuk memulihkan data selepas but semula.

Untuk mencipta aplikasi tahan kesalahan

Mari bayangkan seni bina klasik aplikasi web yang tahan terhadap kesalahan. Ia berfungsi seperti ini: semua permintaan diedarkan oleh pengimbang web antara pelayan. Sistem ini stabil kerana pelayan menduplikasi antara satu sama lain dan membuat sandaran sekiranya berlaku insiden.

Pengimbang mengarahkan semua permintaan dari satu sesi dengan ketat kepada satu pelayan. Ini ialah mekanisme sesi kayu: setiap sesi dikaitkan dengan pelayan di mana ia disimpan dan diproses secara setempat. 

Apa yang berlaku apabila salah satu pelayan gagal?

Perkhidmatan tidak akan terjejas kerana seni bina diduakan. Tetapi kita akan kehilangan subset sesi pelayan yang mati. Dan pada masa yang sama, pengguna yang terikat dengan sesi ini. Sebagai contoh, pelanggan membuat pesanan dan tiba-tiba membuangnya keluar dari pejabat. Dia akan berasa tidak gembira apabila dia log masuk semula dan mendapati segala-galanya perlu dilakukan semula.

Aplikasi web diperlukan untuk menyokong sejumlah besar pengguna dan tidak melambatkan supaya mereka boleh bekerja dengan selesa. Tetapi jika ia ditolak, dengan setiap permintaan berikutnya masa yang diperlukan untuk berkomunikasi dengan stor sesi akan meningkat. Ini meningkatkan kependaman purata untuk pengguna lain. Tetapi mereka tidak mahu menunggu lebih lama daripada biasa.

Masalah ini boleh diselesaikan seperti pelanggan kami yang lain, penyedia PASS yang besar dari USA. Ia menggunakan In-Memory untuk mengelompokkan sesi web. Untuk melakukan ini, ia menyimpannya bukan secara tempatan, tetapi secara berpusat - dalam gugusan Dalam Memori. Dalam kes ini, sesi tersedia dengan lebih pantas kerana ia sudah berada dalam RAM.

Apabila pelayan ranap, pengimbang menghantar permintaan daripada pelayan ranap ke pelayan lain, seperti dalam seni bina klasik. Tetapi terdapat perbezaan penting: sesi disimpan dalam kelompok Dalam Memori dan pelayan mempunyai akses kepada sesi pelayan yang jatuh.

Seni bina ini meningkatkan toleransi kesalahan keseluruhan sistem. Selain itu, adalah mungkin untuk meninggalkan mekanisme sesi kayu sama sekali.

Pemprosesan Analisis Transaksi Hibrid (HTAP)

Biasanya, sistem transaksi dan analitik disimpan berasingan. Apabila mereka berpisah, asas utama berada di bawah beban. Untuk pemprosesan analitikal, data disalin ke replika supaya pemprosesan analitikal tidak mengganggu proses transaksi. Tetapi penyalinan berlaku dengan lag-tidak mungkin untuk meniru tanpa lag. Jika kita melakukan ini secara serentak, ia juga akan memperlahankan pangkalan utama dan kita tidak akan mendapat sebarang kemenangan.

Dalam HTAP, semuanya berfungsi secara berbeza - stor data yang sama digunakan untuk beban transaksi daripada aplikasi dan untuk pertanyaan analisis yang boleh mengambil masa yang lama untuk diselesaikan. Apabila data berada dalam RAM, pertanyaan analisis dilaksanakan dengan lebih pantas, dan pelayan dengan pangkalan data kurang dimuatkan (secara purata).

Pendekatan hibrid memecahkan dinding antara pemprosesan transaksi dan analisis. Jika kami melakukan analitis pada storan yang sama, maka pertanyaan analitikal dilancarkan pada data daripada RAM. Mereka jauh lebih tepat, lebih boleh ditafsir dan mencukupi.

Penyepaduan penyelesaian Dalam Memori

Cara (agak) mudah - membangunkan segala-galanya dari awal. Kami menyimpan data pada cakera dan menyimpan data panas dalam ingatan. Ini membantu mengekalkan but semula atau gangguan pelayan.

Terdapat dua senario utama di tempat kerja di sini apabila data disimpan pada cakera. Pada mulanya, kami mahu bertahan daripada ranap sistem atau but semula biasa kluster atau bahagian - kami mahu menggunakannya sebagai pangkalan data mudah. Dalam senario kedua, apabila terdapat terlalu banyak data, sebahagian daripadanya berada dalam ingatan.

Jika tidak mungkin untuk membina segala-galanya dari awal, adalah mungkin untuk menyepadukan In-Memory ke dalam yang sudah seni bina sedia ada. Tetapi tidak semua penyelesaian Dalam Memori sesuai untuk ini. Terdapat tiga syarat wajib. Penyelesaian Dalam Memori mesti menyokong:

• cara standard untuk menyambung ke pangkalan data yang akan terletak di bawahnya (contohnya, MySQL);
• bahasa pertanyaan standard, supaya tidak menulis semula dan mengubah logik interaksi dengan storan;
• transaksional - memelihara semantik interaksi.

Jika ketiga-tiga syarat dipenuhi, maka penyepaduan adalah mungkin. Kami meletakkan Grid Data Dalam Memori antara aplikasi dan pangkalan data. Sekarang permintaan tulis akan diserahkan kepada pangkalan data asas, dan permintaan baca akan diserahkan kepada pangkalan data asas jika data tiada dalam cache.

Jika akses pantas kepada data dan pemprosesannya penting kepada anda, contohnya, untuk analitis perniagaan, anda boleh memikirkan tentang melaksanakan Dalam Memori. Dan untuk pelaksanaan, anda boleh menggunakan kedua-dua kaedah semasa mereka bentuk seni bina baharu.

Sumber: www.habr.com