In-Memory adalah sekumpulan konsep untuk menyimpan data ketika disimpan dalam RAM aplikasi, dan disk digunakan untuk cadangan. Dalam pendekatan klasik, data disimpan pada disk dan memori disimpan dalam cache. Misalnya, aplikasi web dengan backend untuk memproses data memintanya ke dalam penyimpanan: ia menerimanya, mengubahnya, dan banyak data ditransfer melalui jaringan. Di In-Memory, penghitungan dikirim ke data - ke penyimpanan, tempat penghitungan tersebut diproses dan jaringan lebih sedikit dimuat.
Kemungkinan lain apa yang tersedia dengan In-Memory dan pendekatan seperti apa yang dilakukan? Vladimir Pligin - insinyur di GridGain. Materi ulasan ini akan berguna bagi pengembang backend aplikasi web yang belum pernah bekerja dengan In-Memory dan ingin mencoba, atau tertarik dengan tren modern dalam pengembangan perangkat lunak dan desain arsitektur.
Catatan. Artikel ini didasarkan pada transkrip laporan Vladimir di #GetIT Conf. Sebelum penerapan isolasi mandiri, kami secara rutin mengadakan pertemuan dan konferensi untuk pengembang di Moskow dan Sankt Peterburg: kami membahas tren, masalah pembangunan terkini, masalah, dan solusinya. Saat ini tidak mungkin mengadakan konferensi, namun inilah waktunya untuk berbagi materi bermanfaat dari konferensi sebelumnya.
Siapa yang menggunakan In-Memory dan bagaimana caranya
In-Memory paling sering digunakan ketika interaksi pengguna yang cepat atau pemrosesan data dalam jumlah besar diperlukan.
- Bank gunakan In-Memory, misalnya untuk mengurangi penundaan saat klien menggunakan aplikasi atau untuk menganalisis klien sebelum mengeluarkan pinjaman.
- е menggunakan In-Memory untuk meningkatkan kinerja layanan dan aplikasi bagi bank yang melakukan outsourcing pemrosesan dan analisis data.
- Perusahaan asuransi: untuk menghitung risiko, misalnya dengan menganalisis data pelanggan selama beberapa tahun.
- Perusahaan logistik. Mereka mengolah banyak data, misalnya untuk menghitung rute optimal angkutan barang dan penumpang dengan ribuan parameter, serta melacak status pengiriman.
- Pengecer. Solusi In-Memory membantu melayani pelanggan lebih cepat dan memproses informasi dalam jumlah besar: pengiriman, faktur, transaksi, keberadaan ribuan barang di gudang, dan menyiapkan laporan analitis.
- В IOT In-Memory menggantikan database tradisional.
- Farmasi perusahaan menggunakan In-Memory, misalnya, untuk memilah kombinasi komposisi obat.
Saya akan memberi tahu Anda beberapa contoh bagaimana klien kami menggunakan solusi In-Memory dan bagaimana Anda dapat menerapkannya sendiri.
Dalam Memori sebagai penyimpanan utama
Salah satu klien kami adalah pemasok besar peralatan ilmiah medis dari Amerika. Mereka menggunakan solusi In-Memory sebagai penyimpanan data utama mereka. Semua data disimpan di disk, dan sebagian data yang digunakan secara aktif disimpan di RAM. Metode akses penyimpanannya standar - GDBC (Generic Database Connector) dan bahasa kueri SQL.
Secara kolektif ini disebut In-Memory Database (IMDB) atau Memory-Centric Storage. Kelas solusi ini mempunyai banyak nama, ini bukan satu-satunya.
Fitur IMDB:
- Data yang disimpan di In-Memory dan diakses melalui SQL sama dengan pendekatan lainnya. Semuanya sinkron, hanya cara penyajiannya saja, cara menyikapinya saja yang berbeda. Transaksionalitas bekerja antar data.
- IMDB lebih cepat dibandingkan database relasional karena lebih cepat mengambil informasi dari RAM dibandingkan dari disk.
- Algoritme pengoptimalan internal memiliki instruksi yang lebih sedikit.
- IMDB cocok untuk mengelola data, kejadian, dan transaksi dalam aplikasi.
IMDB mendukung sebagian ACID: Atomicity, Consistency, dan Isolation. Namun mereka tidak mendukung "daya tahan" - ketika listrik dimatikan, semua data akan hilang. Untuk mengatasi masalah ini, Anda dapat menggunakan snapshot - "snapshot" dari database, mirip dengan cadangan database pada hard drive, atau mencatat transaksi (log) untuk memulihkan data setelah reboot.
Untuk membuat aplikasi yang toleran terhadap kesalahan
Mari kita bayangkan arsitektur klasik dari aplikasi web yang toleran terhadap kesalahan. Cara kerjanya seperti ini: semua permintaan didistribusikan oleh penyeimbang web antar server. Sistem ini stabil karena server saling menduplikasi dan membuat cadangan jika terjadi insiden.
Penyeimbang mengarahkan semua permintaan dari satu sesi secara ketat ke satu server. Ini adalah mekanisme sesi tongkat: setiap sesi dikaitkan dengan server tempat sesi tersebut disimpan dan diproses secara lokal.
Apa yang terjadi jika salah satu server gagal?
Layanan tidak akan terpengaruh karena arsitekturnya diduplikasi. Namun kita akan kehilangan sebagian sesi server yang mati. Dan pada saat yang sama, para pengguna yang terikat dengan sesi ini. Misalnya, seorang klien memesan dan tiba-tiba mengusirnya dari kantor. Dia akan merasa tidak senang ketika dia masuk lagi dan menemukan bahwa semuanya harus dilakukan lagi.
Sebuah aplikasi web dituntut untuk dapat mendukung pengguna dalam jumlah besar dan tidak melambat agar dapat bekerja dengan nyaman. Namun jika ditolak, dengan setiap permintaan berikutnya, waktu yang diperlukan untuk berkomunikasi dengan penyimpanan sesi akan meningkat. Hal ini meningkatkan latensi rata-rata untuk pengguna lain. Namun mereka tidak mau menunggu lebih lama dari biasanya.
Masalah ini dapat diselesaikan seperti klien kami yang lain, penyedia PASS besar dari Amerika. Ia menggunakan In-Memory untuk mengelompokkan sesi web. Untuk melakukan ini, ia menyimpannya tidak secara lokal, tetapi secara terpusat - dalam cluster In-Memory. Dalam hal ini, sesi tersedia lebih cepat karena sudah ada dalam RAM.
Saat server mogok, penyeimbang mengirimkan permintaan dari server yang mogok ke server lain, seperti pada arsitektur klasik. Namun ada perbedaan penting: sesi disimpan dalam cluster In-Memory dan server memiliki akses ke sesi server yang rusak.
Arsitektur ini meningkatkan toleransi kesalahan seluruh sistem. Selain itu, mekanisme sesi stick dapat ditinggalkan sama sekali.
Pemrosesan Analitik Transaksional Hibrid (HTAP)
Biasanya, sistem transaksional dan analitis dipisahkan. Ketika mereka terpisah, pangkalan utama mendapat beban. Untuk pemrosesan analitis, data disalin ke replika sehingga pemrosesan analitis tidak mengganggu proses transaksional. Namun penyalinan terjadi dengan jeda—tidak mungkin untuk mereplikasi tanpa jeda. Jika kita melakukan ini secara serempak, itu juga akan memperlambat basis utama dan kita tidak akan mendapatkan kemenangan apa pun.
Di HTAP, semuanya bekerja secara berbeda - penyimpanan data yang sama digunakan untuk pemuatan transaksional dari aplikasi, dan untuk kueri analitis yang memerlukan waktu lama untuk diselesaikan. Ketika data berada dalam RAM, kueri analitis dieksekusi lebih cepat, dan server dengan database lebih sedikit dimuat (rata-rata).
Pendekatan hibrid meruntuhkan tembok antara pemrosesan transaksi dan analitik. Jika kami melakukan analitik pada penyimpanan yang sama, maka kueri analitis diluncurkan pada data dari RAM. Mereka jauh lebih akurat, lebih mudah ditafsirkan dan memadai.
Integrasi solusi Dalam Memori
Cara (yang relatif) sederhana - mengembangkan segalanya dari awal. Kami menyimpan data di disk dan menyimpan data panas di memori. Ini membantu bertahan dari reboot atau pemadaman server.
Ada dua skenario utama yang bekerja di sini ketika data disimpan di disk. Yang pertama, kami ingin selamat dari crash atau reboot rutin pada cluster atau bagiannya - kami ingin menggunakannya sebagai database sederhana. Dalam skenario kedua, ketika terdapat terlalu banyak data, sebagian darinya ada di memori.
Jika tidak memungkinkan untuk membangun semuanya dari awal, dimungkinkan untuk mengintegrasikan In-Memory ke dalam yang sudah ada arsitektur yang ada. Namun tidak semua solusi In-Memory cocok untuk ini. Ada tiga syarat wajib. Solusi In-Memory harus mendukung:
- cara standar untuk terhubung ke database yang akan ditempatkan di bawahnya (misalnya MySQL);
- bahasa kueri standar agar tidak menulis ulang dan mengubah logika interaksi dengan penyimpanan;
- transaksional - pertahankan semantik interaksi.
Jika ketiga syarat tersebut terpenuhi, maka integrasi dapat dilakukan. Kami menempatkan Grid Data Dalam Memori antara aplikasi dan database. Sekarang permintaan tulis akan didelegasikan ke database yang mendasarinya, dan permintaan baca akan didelegasikan ke database yang mendasarinya jika data tidak ada dalam cache.
Jika akses cepat ke data dan pemrosesannya penting bagi Anda, misalnya untuk analisis bisnis, Anda dapat mempertimbangkan untuk menerapkan In-Memory. Dan untuk implementasinya, Anda dapat menggunakan kedua metode tersebut saat merancang arsitektur baru.
Sumber: www.habr.com