Teknologi penyimpanan cache jarak jauh baru dari Microsoft Research, 'Garnet'
(github.com/microsoft)- Garnet adalah penyimpanan cache jarak jauh buatan Microsoft Research yang berbasis protokol wire RESP, sehingga klien Redis yang sudah ada dapat digunakan tanpa modifikasi
- Pada banyak koneksi klien dan batch kecil, throughput dan skalabilitas-nya lebih tinggi dibanding penyimpanan cache open source sekelas, dan saat Accelerated Networking diaktifkan pada Azure VM, latensi persentil 99,9 sering kali berada di bawah 300 mikrodetik
- Berbasis .NET modern, berjalan di Linux dan Windows, dapat membuat operasi kustom, stored procedure, dan modul dengan C#, serta mendukung skrip Lua
- Lapisan penyimpanan Tsavorite mendukung tiering memori, SSD, dan cloud storage, checkpoint non-blocking, pemulihan, operation log untuk durabilitas, transaksi multi-key, serta sharding, replikasi, dan migrasi key dinamis pada mode klaster
- Fitur baru Vector Sets Preview dan Range Index Preview telah ditambahkan, dan makalah Garnet dijadwalkan terbit di VLDB 2026
Penyimpanan cache jarak jauh yang ditawarkan Garnet
- Garnet adalah penyimpanan cache jarak jauh baru dari Microsoft Research
- Mengadopsi protokol wire RESP sebagai titik awal, sehingga klien Redis yang sudah ada di berbagai bahasa pemrograman dapat digunakan tanpa modifikasi
- Sebagai contoh, StackExchange.Redis untuk C# dapat digunakan
- Menawarkan throughput dan skalabilitas yang lebih baik dibanding penyimpanan cache open source sekelas pada banyak koneksi klien dan batch kecil, sehingga berpotensi menurunkan biaya untuk aplikasi dan layanan berskala besar
- Saat Accelerated Networking diaktifkan pada Azure VM umum, latensi klien persentil 99,9 sering tercatat di bawah 300 mikrodetik
- Dibangun di atas teknologi .NET modern, dengan tujuan arsitektur yang lintas platform, dapat diperluas, dan modern
- Dirancang agar pengembangan dan evolusi lebih mudah tanpa mengorbankan performa pada kasus umum
- Memanfaatkan ekosistem pustaka .NET untuk memperluas cakupan API dan menyisakan ruang untuk optimisasi
- Mencapai performa tingkat modern baik di Linux maupun Windows
- Jika membutuhkan layanan yang sepenuhnya dikelola, Azure Cosmos DB Garnet Cache menyediakan Garnet sebagai solusi caching enterprise dengan high availability, jaminan performa, dan tanpa pengelolaan infrastruktur
Fitur yang baru ditambahkan dan makalah
- Vector Sets Preview menyediakan pencarian approximate nearest neighbor
- Berbasis algoritme DiskANN dan mesin penyimpanan Tsavorite milik Garnet
- Pada hasil awal, Garnet menunjukkan keunggulan dalam QPS, latensi p99, dan recall
- Range Index Preview menyediakan indeks rentang dan kesetaraan sekunder di atas key Garnet
- Berbasis Bf-Tree
- Makalah Garnet dijadwalkan terbit di VLDB 2026
- Judul makalahnya adalah Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services
- Tersedia PDF
API dan model ekstensi
- Garnet mengimplementasikan berbagai API
- String mentah: get, set, kedaluwarsa key
- Operasi analitik: HyperLogLog, Bitmap
- Operasi objek: sorted set, list, dan lainnya
- Mendukung transaksi multi-key
- Transaksi RESP di sisi klien
- Stored procedure dan modul sisi server berbasis C#
- Pengguna dapat membuat operasi kustom baik untuk string mentah maupun tipe objek kustom
- Memanfaatkan kemudahan dan keamanan C# untuk menurunkan hambatan dalam pengembangan ekstensi kustom
- Juga mendukung skrip Lua
Lapisan jaringan, keamanan, dan penyimpanan
- Garnet menggunakan lapisan jaringan yang cepat dan dapat dipasang secara modular
- Memungkinkan perluasan di masa depan seperti pemanfaatan stack kernel bypass
- Untuk komunikasi aman, TLS didukung menggunakan pustaka SslStream milik .NET
- Menyediakan kontrol akses dasar
- Lapisan penyimpanannya, Tsavorite, dirancang untuk performa tinggi dan mencakup berbagai fitur basis data
- Skalabilitas thread
- Penyimpanan bertingkat yang mencakup memori, SSD, dan cloud storage
- Checkpoint non-blocking yang cepat
- Pemulihan
- Operation log untuk durabilitas
- Transaksi multi-key
- Pengelolaan dan penggunaan ulang memori yang lebih baik
Struktur desain
- Desain Garnet merombak ulang seluruh stack penyimpanan cache, mulai dari penerimaan paket jaringan hingga parsing dan pemrosesan operasi basis data, sampai interaksi dengan penyimpanan
- Lapisan jaringannya berbasis desain shared memory
- Pemrosesan TLS dan interaksi dengan penyimpanan dilakukan pada thread penyelesaian network IO
- Menghindari overhead perpindahan thread pada kasus umum
- Alih-alih memindahkan data ke shard server yang sesuai seperti pada desain jaringan tradisional berbasis shuffle, koherensi cache CPU membuat data dibawa ke sisi logika pemrosesan
- Desain penyimpanannya terdiri dari dua key-value store Tsavorite yang diikat oleh operation log terpadu
- main store dioptimalkan untuk operasi string mentah dan mengelola memori dengan hati-hati untuk menghindari garbage collection
- object store opsional dioptimalkan untuk objek kompleks dan tipe data kustom
- object store mencakup tipe seperti Sorted Set, Set, Hash, List, dan Geo
- Tipe data pada object store saat ini memanfaatkan ekosistem pustaka .NET dalam implementasinya
- Objek disimpan dalam bentuk yang efisien untuk pembaruan di heap memori, dan dalam bentuk terserialisasi di disk
- Untuk mempermudah pemeliharaan di masa depan, ada rencana meninjau penggunaan indeks dan log terpadu
- Pembeda Garnet adalah API penyimpanan Tsavorite yang berbentuk narrow waist
- Di atas API ini diimplementasikan permukaan API RESP yang besar, kaya, dan dapat diperluas
- Terdiri dari operasi baca, upsert, hapus, dan atomic read-modify-write
- Melalui callback asinkron, logika Garnet dapat diintervensikan di berbagai titik selama tiap operasi
- Memisahkan concern parsing dan pemrosesan kueri dari detail penyimpanan seperti konkurensi, tiering penyimpanan, dan checkpoint
- Untuk transaksi multi-key digunakan two-phase locking
Mode klaster dan batasan operasional
- Selain berjalan pada node tunggal, Garnet mendukung mode klaster
- Dapat membuat dan mengelola deployment dengan sharding dan replikasi
- Mendukung metode migrasi key yang efisien dan dinamis untuk rebalancing shard
- Pengguna dapat membuat dan mengelola klaster Garnet dengan perintah klaster Redis standar
- Node melakukan gossip untuk berbagi dan mengembangkan status klaster
- Desain mode klaster Garnet saat ini bersifat passive
- Tidak mengimplementasikan pemilihan leader
- Merespons perintah klaster yang diterbitkan oleh control plane yang disediakan pengguna
- Detail terkait ada di dokumentasi control plane
Dokumentasi dan lisensi
- Informasi dan dokumentasi lebih lanjut tersedia di situs dokumentasi Garnet
- Untuk memulai, lihat dokumen getting started
- Informasi rilis tersedia di bagian releases
- Proyek ini tersedia di bawah MIT License
1 komentar
Komentar Hacker News
Melihat grafik performa benchmark (https://microsoft.github.io/garnet/docs/benchmarking/results...), throughput GET lebih dari 10 kali lebih tinggi daripada Dragonfly.
Latensi 50% sedikit lebih tinggi daripada Dragonfly, tetapi persentil ke-99 sedikit lebih rendah.
Baik Garnet maupun Dragonfly memiliki throughput dan latensi yang jauh lebih baik daripada Redis, jadi tampaknya Redis membutuhkan optimasi performa yang cukup besar.
Saya tidak tahu apakah optimasi benar-benar diperlukan, dan di sini sudah ada 3 alternatif.
Namun Garnet mengesankan karena menjadi alternatif pertama yang mengungguli Redis baik pada konkurensi rendah maupun tinggi, dan saya ingin segera mencobanya.
Dragonfly ditulis dalam C++, Redis dalam C.
Lapisan penyimpanan Garnet, Tsavorite, bercabang dari FASTER yang open source, dan mencakup fitur database yang kuat seperti skalabilitas thread, penyimpanan berjenjang (memori, SSD, penyimpanan cloud), checkpoint cepat non-blocking, pemulihan, log operasi untuk durabilitas, transaksi multi-key, serta manajemen dan penggunaan ulang memori yang lebih baik.
https://www.microsoft.com/en-us/research/blog/introducing-ga...
Saat itu, untuk proyek proof of concept dengan kebutuhan performa tinggi yang sedang saya kerjakan, saya melihatnya cukup menjanjikan sebagai pustaka persistensi.
Sebagai catatan, kedua proyek ini tampaknya dipimpin oleh orang yang sama [1].
[1]: https://github.com/badrishc
Proyek-proyek yang dibuat langsung oleh Microsoft dan tim .NET, seolah-olah mereka meretas infrastruktur sendiri, cukup mengesankan.
Yarp adalah alat untuk reverse proxy/API gateway/apa pun lagi yang dibutuhkan, dan sekarang Garnet untuk cache memori.
Tampaknya kebutuhan internalnya sangat besar, dan mereka juga punya kemauan untuk membagikannya.
Akan bagus kalau hal seperti ini tertanam di Azure App Service.
Maksudnya, agar tidak harus memakai layanan jarak jauh hanya untuk caching.
Dulu di IIS, cukup umum menaruh penyimpanan session state di luar proses untuk aplikasi ASP.NET.
Tujuannya agar ketika proses web app di-restart, pengguna tidak kehilangan sesi dan harus login dari awal.
Tentu saja bisa juga menaruhnya di penyimpanan terpusat seperti SQL Server, tetapi itu membuat setiap permintaan halaman web menunggu session state dimuat sebelum diproses.
Session state biasanya dikunci dengan suatu cara, sehingga masalah performanya juga banyak.
Solusi umum saat ini adalah memakai Redis untuk cache dan session state, dan pada umumnya itu berjalan lumayan.
Throughput-nya tinggi, tetapi Redis adalah resource terpisah di Azure dan harganya tidak masuk akal.
Saya tidak ingin membayar harga setara Oracle DB untuk hal sesederhana ini, dan konfigurasi koneksinya juga cukup merepotkan.
Artikel ini menyebut waktu respons 300 mikrodetik, tetapi dalam desain zone-redundant itu tidak terlalu berarti karena semua load balancer Azure menggunakan pemilihan zona acak.
Web server di zona acak dipilih, lalu ia terhubung lagi ke cache server di zona acak.
Jika server itu tidak memiliki key tersebut, mungkin harus pergi lagi ke zona acak lain untuk mengambil data cache.
Trafik bolak-balik antar data center, menimbulkan latensi 1–3 ms dan membuatnya hingga 10 kali lebih lambat daripada angka yang diiklankan Garnet.
Skenario idealnya adalah sesuatu seperti reliable collections[1] milik Microsoft Service Fabric.
Ia berjalan lokal di setiap host node dan direplikasi ke dua node lain.
Web app selalu bisa membaca nilai cache dari host fisik yang sama.
Dalam beberapa kasus, latensi bisa turun hingga satu digit mikrodetik, dan layanan eksternal seoptimal apa pun akan ribuan kali lebih lambat jika memakai load balancing sederhana.
Yang saya inginkan bukan 30% lebih cepat daripada Redis, melainkan 3.000 kali lebih cepat.
[1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...
Layanan bisa dikonfigurasi agar selalu menuju layanan lokal, atau dengan topologi routing lain.
Sangat bagus untuk DNS atau cache aplikasi.
Ini adalah pengganti Redis dengan angka benchmark latensi dan throughput yang cukup mengesankan.
Saya penasaran seperti apa saat dioperasikan sungguhan di stack non-Azure.
Saya tidak melihat tanda dukungan xstream.
Garnet being multi-threaded, MSET is not atomic. For an atomic version of MSET, you would need to express it as a transaction (stored procedure).Bagian ini kurang saya pahami.
Kenapa tidak membungkusnya secara internal dengan transaksi agar perintahnya menjadi atomik?
Saya juga penasaran ada jebakan atomicity apa lagi.
MSETjuga akan terkena biaya performa, dan tidak ada cara untuk mematikan transaksi itu.Sebaliknya, jika tujuannya adalah menjadi drop-in replacement Redis, ini menjadi masalah karena Redis menjamin atomicity.
Setidaknya jika drop-in replacement adalah tujuan desainnya, sepertinya bisa ada opsi konfigurasi untuk memilih antara kompatibilitas dan performa.
Jelas mengesankan.
Microsoft Research kadang-kadang menghasilkan proyek luar biasa, dan sepertinya menyenangkan dibayar untuk melakukan riset dan pengembangan.
Saya berharap perusahaan besar lebih banyak mengerjakan proyek R&D yang bermanfaat bagi seluruh industri.
Kalau Hashicorp sedang dijual, semoga diakuisisi oleh perusahaan yang baik.
Ini kabar sangat baik bagi orang-orang yang perlu menjalankan server kompatibel Redis langsung di Microsoft Windows Server tanpa bergantung pada WSL2.
Dulu ada port Redis[1], tetapi sekarang sudah diarsipkan, pernah punya masalah penggunaan memori (setahu saya terutama karena memory-mapped file), dan tidak lagi didukung.
Fakta bahwa ini ditulis dalam C# juga cukup menarik bagi saya pribadi.
Karena C# adalah bahasa utama saya, saya ingin meluangkan waktu untuk menggali kodenya.
[1]: https://github.com/microsoftarchive/redis
Saya ingin melihat di mana ini dipakai di lingkungan produksi sungguhan.
Ada bagian yang mengatakan, “setelah ribuan unit test dan beberapa tahun menjalankan Garnet dalam deployment operasional bersama tim-tim 1st-party Microsoft, kami merasa sekarang waktunya untuk membukanya ke publik.”
https://microsoft.github.io/garnet/blog
Melihat komentar di sini, sepertinya sekarang tidak ada lagi yang memakai memcached.
Saya menginginkan cache LRU, tetapi ada beberapa opsi dan penjelasannya kurang baik, jadi saya tidak tahu kenapa item terus-menerus dikeluarkan.
Setelah beralih ke Redis, konfigurasinya mudah dan berjalan sesuai harapan.