Microsoft Research की नई रिमोट cache store तकनीक ‘Garnet’

 (github.com/microsoft)
4 पॉइंट द्वारा GN⁺ 2024-03-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Garnet Microsoft Research द्वारा बनाया गया एक रिमोट cache store है, जो RESP wire protocol पर आधारित है और मौजूदा Redis clients को बिना बदलाव के इस्तेमाल करने देता है
  • बहुत अधिक client connections और छोटे batches में यह तुलनीय open source cache stores की तुलना में throughput और scalability में बेहतर है, और Azure VM पर Accelerated Networking चालू होने पर 99.9th percentile latency अक्सर 300 microseconds से कम रहती है
  • यह आधुनिक .NET पर आधारित है और Linux व Windows पर चलता है; C# में custom operations, stored procedures और modules बनाए जा सकते हैं, और Lua scripts भी supported हैं
  • storage layer Tsavorite memory, SSD और cloud storage tiering, non-blocking checkpoints, recovery, durability के लिए operation log, multi-key transactions, और cluster mode में sharding, replication व dynamic key migration को support करता है
  • नए features के रूप में Vector Sets Preview और Range Index Preview जोड़े गए हैं, और Garnet paper VLDB 2026 में प्रकाशित होने वाला है

Garnet द्वारा प्रदान किया जाने वाला रिमोट cache store

  • Garnet Microsoft Research का नया रिमोट cache store है
  • यह RESP wire protocol को शुरुआती आधार के रूप में अपनाता है, जिससे कई programming languages के मौजूदा Redis clients बिना बदलाव के इस्तेमाल किए जा सकते हैं
    • उदाहरण के लिए C# का StackExchange.Redis इस्तेमाल किया जा सकता है
  • बहुत अधिक client connections और छोटे batches में यह तुलनीय open source cache stores से बेहतर throughput और scalability देता है, जिससे बड़े पैमाने के apps और services की लागत घट सकती है
  • सामान्य Azure VM पर Accelerated Networking enabled होने पर 99.9th percentile client latency अक्सर 300 microseconds से कम दिखती है
  • यह आधुनिक .NET तकनीक पर आधारित है और इसका लक्ष्य cross-platform, extensible और modern architecture प्रदान करना है
    • इसे इस तरह design किया गया है कि सामान्य cases में performance से समझौता किए बिना development और evolution आसान रहे
    • .NET library ecosystem का उपयोग करके API surface बढ़ाता है और optimization की गुंजाइश छोड़ता है
    • Linux और Windows दोनों पर modern-level performance हासिल करता है
  • अगर fully managed service चाहिए, तो Azure Cosmos DB Garnet Cache Garnet को high availability, performance guarantees और infrastructure management के बिना enterprise caching solution के रूप में प्रदान करता है

हाल में जोड़े गए features और paper

  • Vector Sets Preview approximate nearest neighbor search प्रदान करता है
    • यह DiskANN algorithm और Garnet के Tsavorite storage engine पर आधारित है
    • शुरुआती results में Garnet ने QPS, p99 latency और recall में बेहतर परिणाम दिखाए हैं
  • Range Index Preview Garnet keys के ऊपर secondary range और equality indexes प्रदान करता है
    • यह Bf-Tree पर आधारित है
  • Garnet paper VLDB 2026 में प्रकाशित होने वाला है
    • paper का नाम Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services है
    • PDF उपलब्ध है

API और extension model

  • Garnet विभिन्न APIs implement करता है
    • raw strings: get, set, key expiration
    • analytics operations: HyperLogLog, Bitmap
    • object operations: sorted set, list आदि
  • यह multi-key transactions को support करता है
    • client-side RESP transactions
    • C# आधारित server-side stored procedures और modules
  • users raw strings और custom object types दोनों के लिए custom operations बना सकते हैं
    • C# की सुविधा और safety का उपयोग करके custom extensions develop करने की entry barrier कम करता है
  • Lua scripts भी supported हैं

network, security और storage layer

  • Garnet एक तेज और pluggable network layer का उपयोग करता है
    • इससे भविष्य में kernel bypass stack के उपयोग जैसे extensions संभव होते हैं
  • secure communication .NET की SslStream library का उपयोग करके TLS support करता है
  • basic access control प्रदान करता है
  • storage layer Tsavorite high performance के लिए design किया गया है और इसमें कई database features शामिल हैं
    • thread scalability
    • memory, SSD और cloud storage सहित tiered storage
    • तेज non-blocking checkpoints
    • recovery
    • durability के लिए operation log
    • multi-key transactions
    • बेहतर memory management और reuse

design architecture

  • Garnet का design network packet receive करने से लेकर database operations की parsing और processing, और storage interaction तक पूरे cache store stack को फिर से design करता है
  • network layer shared-memory design पर आधारित है
    • TLS processing और storage interaction network IO completion threads पर किए जाते हैं
    • सामान्य case में thread-switching overhead से बचता है
    • पारंपरिक shuffle-based network design की तरह data को server के उपयुक्त shard में ले जाने के बजाय, CPU cache coherence data को processing logic की ओर लाने देता है
  • storage design integrated operation log से जुड़े दो Tsavorite key-value stores से बना है
    • main store raw string operations के लिए optimized है और garbage collection से बचने के लिए memory को सावधानी से manage करता है
    • optional object store complex objects और custom data types के लिए optimized है
    • object store में Sorted Set, Set, Hash, List, Geo जैसे types शामिल हैं
    • मौजूदा implementation में object store के data types .NET library ecosystem का उपयोग करते हैं
    • objects memory heap में update-efficient form में और disk पर serialized form में store किए जाते हैं
  • भविष्य में maintenance आसान बनाने के लिए integrated index और log के उपयोग की समीक्षा करने की योजना है
  • Garnet की खासियत narrow waist जैसे रूप वाली Tsavorite storage API है
    • इसी API के ऊपर बड़ा, समृद्ध और extensible RESP API surface implement किया गया है
    • यह read, upsert, delete और atomic read-modify-write operations से बना है
    • asynchronous callbacks के जरिए हर operation के दौरान कई points पर Garnet logic को intervene कराया जा सकता है
    • यह parsing और query processing concerns को concurrency, storage tiering और checkpoints जैसे storage details से अलग करता है
  • multi-key transactions के लिए two-phase locking का उपयोग करता है

cluster mode और operational constraints

  • single-node execution के अलावा Garnet cluster mode support करता है
    • sharding और replication वाली deployments बनाई और manage की जा सकती हैं
    • shard rebalancing के लिए efficient और dynamic key migration method support करता है
  • users standard Redis cluster commands से Garnet cluster बना और manage कर सकते हैं
  • nodes gossip करते हैं ताकि cluster state share और evolve हो सके
  • Garnet का cluster mode design फिलहाल passive है
    • leader election implement नहीं करता
    • user-provided control plane द्वारा जारी किए गए cluster commands का जवाब देता है
    • संबंधित जानकारी control plane documentation में है

docs और license

  • अधिक विस्तृत जानकारी और documentation Garnet docs site पर देखी जा सकती है
  • शुरू करने के लिए getting started documentation देख सकते हैं
  • release notes releases section में हैं
  • project MIT License के तहत उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-20
Hacker News की राय

  • benchmark performance chart(https://microsoft.github.io/garnet/docs/benchmarking/results...) देखने पर GET throughput Dragonfly से 10 गुना से भी ज़्यादा है
    50% latency Dragonfly से थोड़ी ज़्यादा है, लेकिन 99th percentile थोड़ा कम है
    Garnet और Dragonfly दोनों में throughput और latency Redis से कहीं बेहतर हैं, इसलिए Redis में काफ़ी performance optimization की ज़रूरत लगती है

    • Redis single-threaded है, इसलिए सरल और प्रभावी है
      optimization सचमुच ज़रूरी है या नहीं, पता नहीं; और यहां पहले से 3 विकल्प मौजूद हैं
      हालांकि Garnet पहला ऐसा विकल्प है जो कम concurrency और ज़्यादा concurrency दोनों में Redis से आगे निकलता है, इसलिए यह प्रभावशाली है और इसे जल्द आज़माना चाहूंगा
    • सबसे हैरान करने वाली बात यह है कि यह project C# में develop किया गया है
      Dragonfly C++ में और Redis C में लिखा गया है
    • garbage-collected language C# में बना Garnet, Redis/Dragonfly को मात दे रहा है—यह हैरान करने वाला है

  • Garnet की storage layer Tsavorite open source FASTER से fork होकर निकली है, और इसमें thread scalability, tiered storage (memory, SSD, cloud storage), तेज़ non-blocking checkpoint, recovery, durability के लिए operation log, multi-key transactions, बेहतर memory management और reuse जैसी मज़बूत database capabilities शामिल हैं
    https://www.microsoft.com/en-us/research/blog/introducing-ga...

    • पहले FASTER implementation को follow किया था
      उस समय जिस proof-of-concept project पर काम कर रहा था, उसकी high-performance requirements के लिए इसे persistence library के रूप में काफ़ी promising माना था
      संदर्भ के लिए, दोनों projects को वही व्यक्ति lead कर रहा है, ऐसा लगता है [1]
      [1]: https://github.com/badrishc
    • Microsoft का बनाया एक और open source project है

  • Microsoft और .NET team के वे projects काफ़ी impressive हैं जिन्हें वे खुद infrastructure को hack करने की तरह बनाते हैं
    Yarp reverse proxy/API gateway/या जो भी चाहिए वह करने वाला tool है, और अब Garnet memory cache के लिए है
    लगता है internal demand बहुत ज़्यादा है, और उसे share करने की इच्छा भी है

  • Azure App Service में अगर ऐसा कुछ built-in हो तो अच्छा होगा
    ताकि caching के लिए ज़रूरी नहीं कि remote service ही इस्तेमाल करनी पड़े
    पहले IIS में ASP.NET apps के लिए out-of-process session state store रखना आम था
    वजह यह थी कि web app process restart होने पर users अपना session न खो दें और उन्हें शुरुआत से login न करना पड़े
    बेशक इसे SQL Server जैसे central store में भी रखा जा सकता है, लेकिन तब हर web page request को process होने से पहले session state load होने का इंतज़ार करना पड़ता है
    session state आम तौर पर किसी-न-किसी तरह locked रहती है, इसलिए performance issues भी बहुत होते हैं
    आजकल आम solution cache और session state के लिए Redis इस्तेमाल करना है, और कुल मिलाकर यह ठीक-ठाक काम करता है
    throughput ऊंचा है, लेकिन Redis Azure में अलग resource है और बेवजह बहुत महंगा है
    इतनी सरल चीज़ के लिए Oracle DB वाली कीमत नहीं देना चाहता, और connection configuration भी काफ़ी झंझट भरा है
    इस लेख में 300 microsecond response time की बात है, लेकिन zone-redundant design में इसका खास मतलब नहीं, क्योंकि सभी Azure load balancers arbitrary zone selection इस्तेमाल करते हैं
    किसी arbitrary zone का web server चुना जाता है, और फिर वह किसी arbitrary zone के cache server से connect करता है
    अगर उस server पर key नहीं है, तो cache data लेने के लिए उसे किसी और arbitrary zone में जाना पड़ सकता है
    traffic datacenters के बीच ping-pong करता है, जिससे 1–3ms latency आती है और यह Garnet के advertised numbers से अधिकतम 10 गुना धीमा हो जाता है
    ideal scenario Microsoft Service Fabric के reliable collections[1] जैसा कुछ है
    यह हर host node पर locally चलता है और दो अन्य nodes में replicate करता है
    web app हमेशा उसी physical host से cache value पढ़ सकता है
    कुछ cases में latency single-digit microseconds तक आ जाती है, और कोई भी बहुत अच्छी तरह optimized external service भी simple load-balanced तरीके में इससे हजारों गुना धीमी होती है
    Redis से 30% तेज़ नहीं, बल्कि 3,000 गुना तेज़ चाहिए
    [1] https://learn.microsoft.com/en-us/azure/service-fabric/servi...

    • इसी वजह से Cilium इस्तेमाल करने वाला Kubernetes अच्छा है
      service को हमेशा local service तक जाने के लिए, या दूसरी routing topology के लिए भी configure किया जा सकता है
      DNS या application cache के लिए बहुत अच्छा है

  • यह latency और throughput benchmark numbers के लिहाज़ से काफ़ी impressive Redis alternative है
    Azure के बाहर की stack में production में चलाने पर यह कैसा दिखेगा, यह जानने की उत्सुकता है

    • पता नहीं यह सच में drop-in replacement है या नहीं
      xstream support का कोई indication नहीं दिख रहा

  • 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).
    यह हिस्सा ठीक से समझ नहीं आया
    अंदर ही अंदर transaction में wrap करके command को atomic क्यों नहीं बनाते
    और कौन-कौन से atomicity traps हैं, यह भी जानना चाहूंगा

    • ऐसा करने पर उन सभी लोगों पर भी performance cost आएगी जिन्हें MSET की atomicity की ज़रूरत नहीं है, और उस transaction को बंद करने का तरीका नहीं रहेगा
      उल्टा, अगर लक्ष्य Redis का drop-in replacement बनना है, तो Redis atomicity guarantee करता है, इसलिए यह समस्या है
      कम-से-कम अगर drop-in replacement design goal है, तो compatibility और performance में से चुनने के लिए कोई config option रखा जा सकता है

  • निश्चित रूप से impressive है
    Microsoft Research कभी-कभी कमाल के projects निकालता है; research and development करते हुए पैसा मिलना मज़ेदार लगता होगा
    बड़ी कंपनियां industry को overall मदद करने वाले research-and-development type projects और ज़्यादा करें तो अच्छा होगा
    अगर Hashicorp बिकने के लिए available है, तो उम्मीद है कोई अच्छी company उसे acquire करे

  • Microsoft Windows Server पर WSL2 पर निर्भर हुए बिना Redis-compatible server सीधे चलाने वाले लोगों के लिए यह बहुत अच्छी खबर है
    पहले Redis port[1] था, लेकिन अब archived है, उसमें memory usage issues थे (जहां तक मुझे पता है, मुख्यतः memory-mapped files की वजह से), और अब support नहीं है
    C# में लिखा होना भी निजी तौर पर काफ़ी दिलचस्प है
    C# मेरी primary language है, इसलिए समय निकालकर code में गहराई से देखना चाहूंगा
    [1]: https://github.com/microsoftarchive/redis

  • यह actual production environment में कहां इस्तेमाल हो रहा है, देखना चाहूंगा
    इसमें यह हिस्सा है: “हजारों unit tests और Microsoft की 1st-party teams के साथ कई वर्षों तक Garnet को production deployments में चलाने के बाद, हमें लगा कि अब इसे public करने का समय है”
    https://microsoft.github.io/garnet/blog

  • यहां comments देखकर लगता है अब कोई भी memcached इस्तेमाल नहीं करता

    • आख़िरी बार शायद 2016 के आसपास इस्तेमाल किया था, और setup खास आसान नहीं था
      मुझे LRU cache चाहिए था, लेकिन options कई थे और explanation अच्छी नहीं थी, इसलिए समझ नहीं आ रहा था कि यह बार-बार items evict क्यों कर रहा है
      Redis पर switch किया तो setup आसान था और यह उम्मीद के मुताबिक काम करने लगा