Paginasi dengan Caching Progresif

Apa itu Cache? Caching adalah teknik menyimpan salinan data aplikasi yang sering digunakan dalam lapisan memori yang lebih kecil dan lebih cepat untuk meningkatkan waktu pengambilan data, throughput.

Apa itu Paginasi? Paginasi adalah proses memisahkan data menjadi set, Sama seperti halaman buku. Permintaan GET API untuk meminta informasi dari server melalui titik akhir API ke database besar dapat menghasilkan jutaan, jika bukan miliaran, hasil. Respons API yang mengirimkan ribuan entri sekaligus menguras sumber daya. Paging membantu menskalakan aplikasi kami, melayani lebih banyak pengguna, kueri yang efisien, dan menciptakan pengalaman konsumen yang baik.

Mari pertimbangkan sebuah skenario : Anda diberi tugas untuk mengembangkan layanan. Itu akan memiliki titik akhir yang melayani catatan dari tabel database yang berbeda. Untuk saat ini, anggap saja Anda memulai dengan titik akhir yang ditayangkan dari tabel produk dari database Anda. API mendukung beberapa parameter filter. Katakanlah PriceRange, Produsen, dll. Mengingat ada 5 juta+ produk di database Anda. Dan vendor Anda terus menambahkan lebih banyak produk ke database.

Pikiran Awal : Seseorang mungkin berpikir untuk membuat kueri database terhadap sumber daya API dan parameter filter dan menjalankannya dalam pushdown di database, membaca semua catatan yang difilter, menyimpannya di beberapa cache, dan melayani respons paginasi dari cache untuk permintaan selanjutnya.

Bayangkan jika hasil query mengembalikan 2 juta record. Apakah Anda akan meng-cache (2 juta — pageSize) record? Selain itu, waktu respons permintaan pertama akan sangat besar. Saat Anda memuat semua 2 juta catatan sekaligus terlepas dari ukuran halaman. Dan kapan harus membatalkan cache. Itu sudah menyimpan sejumlah besar data.

Pendekatan saya menggunakan caching progresif

Bob pergi membeli roti Naan dari restoran terdekat. Dia mengamati bahwa ada dua orang di dekat oven. Salah satunya membentuk lantai menjadi roti Naan. Satu lagi sesuai permintaan memasukkan roti berbentuk itu ke dalam Oven dan menyajikan pesanan. Dia mengamatinya orang di Oven menunggu beberapa detik jika ada pesanan lain dan bersandar sebaliknya.

Anda punya ini Benar? Kerjakan sesuai permintaan, jeda sebentar buang sebaliknya. Itulah tepatnya bagaimana saya memecahkan masalah ini. Sekarang mari kita petakan ini ke dalam skenario kita.

Cache Progresif :

Kunci cache kami adalah GUID. Itu akan digunakan di sini sebagai parameter kursor untuk paginasi kita. Nilainya adalah pembaca yang dijeda. Kita dapat menerapkan cache menggunakan cache LRU. Selain itu, pengatur waktu tambahan yang berdetak setelah setiap 8 detik (dapat dikonfigurasi pengguna) membuang pembaca yang paling jarang digunakan. Jadi kami tidak membiarkan koneksi database terbuka lama.

public interface ICache
{
  void Add(Guid Key,IReader reader);
  IReader Get(Guid Key);
  void DisposeUnwanted();
}

Permintaan Pertama

Example request: https://localhost:9261/Products?Price=100&Manufacturer=HP

//Converted Query for our example request.
SELECT * FROM products WHERE Price = 100 AND Manufacturer Like 'HP'

Langkah 3: Jeda pembaca, Hasilkan GUID, dan Cache.

Langkah 4: Tambahkan GUID yang Dihasilkan sebagai kursor Anda untuk halaman berikutnya di badan respons JSON Anda.

Permintaan Selanjutnya

Example request: https://localhost:9261/Products?Price=100&Manufacturer=HP&Cursor=GUID

Langkah 2: Lanjutkan pembaca dan baca catatan sampai hitungan batas Anda.

Langkah 3 & 4 : Sama seperti permintaan pertama.

Time Complexity : O(limit), Dimana batasannya adalah ukuran halaman respon.

Kelebihan :

1. Tidak memuat malas.
2. Penggunaan sumber daya yang efisien.
3. Waktu respons yang konstan.
4. Tidak ada kueri yang rumit. Yang perlu Anda pahami jika Anda menekan parameter kursor.

1. Tidak dapat membaca catatan sebelumnya. Tapi itu tidak mungkin menggunakan paginasi kursor menurut definisi.

Ya, hidup itu mudah, Jika Anda bisa mengkodekannya.

Model caching progresif ini dapat ditampung dengan sumber data lain seperti File, Dokumen. (Kami membutuhkan prosesor ekspresi terpisah untuk where klausa karena kami tidak dapat menekan file). Ini juga cocok secara efisien pada skema tabel database Anda yang berbeda tanpa terlalu memedulikan strukturnya.
Modelnya bekerja dengan sempurna untuk saya. Saya telah melihat orang-orang terjebak dalam situasi yang sama di Stack Overflow dan menggunakan pemuatan malas atau implementasi pihak ketiga dengan overhead tambahan sebagai solusi sederhana. Pendekatan yang dibagikan adalah milik saya sendiri. Jadi itu mungkin cocok dengan kasus penggunaan Anda. Silakan bagikan pendekatan Anda di komentar.

Dan jika Anda menyukai artikel ini, tekan tombol tepuk tangan di bawah . Itu sangat berarti bagi saya dan membantu orang lain melihat ceritanya.

~ Insinyur Perangkat Lunak Senior Sooraj Kumar
@ Perangkat Lunak Astera